#.net-core #microservices #asp.net-core-5.0
Вопрос:
У меня есть проект микрослужб .net core 5, у клиента есть модуль поиска, который будет запрашивать данные из многих объектов, эти объекты находятся во многих службах.
первый микросервис для продуктов. в этом микросервисе есть таблица product {productid, productname }.
второй микросервис для поставщиков. в этом микросервисе есть таблица учетной записи {идентификатор поставщика, имя поставщика}.
третий микросервис для покупки в этом микросервисе имеет таблицу покупки {название, идентификатор продукта(этот идентификатор взят из таблицы продуктов в первом микросервисе), идентификатор учетной записи (этот идентификатор взят из таблицы учетных записей во втором микросервисе)}.
Теперь : пользователь хочет выполнить поиск покупки, где название продукта, например, «одежда», и имя продавца, например, «x».;
кто я могу сделать этот запрос, бросьте шаблон микросервиса.
Ответ №1:
создание монолитной системы и размещение интерфейсов служб поверх каждой таблицы просто превратит вашу жизнь в ад, поскольку вы сами начнете реализовывать эту логику базы данных — как в этом вопросе, когда вы пытаетесь воссоздать соединения с базой данных.
Не говоря уже о том, что, похоже, ваше разделение на службы не подходит (или не нужно) для этого случая. учитывая, что покупки описывают произошедшие события (даже если они позже будут удалены), они могут фиксировать состояние продукта или поставщика. таким образом, вы можете дополнить данные в покупках, чтобы представить данные о продукте и поставщике, которые были правильными во время покупки. Это позволит изолировать запросы на покупку в службу закупок и даст дополнительное преимущество в сохранении истории, когда продукты/поставщики будут развиваться с течением времени.
Комментарии:
1. спасибо за ваш ответ, В моем случае это просто не модуль покупки, у меня сейчас полностью разрабатывается финансовая система, как я понимаю, шаблон микросервисов не подходит для систем такого типа, верно??
2. не обязательно, но упрощенный взлом сервисов не будет хорошо работать. Во многих микросервисах, даже если вы разделяете службы для минимизации зависимостей между службами, вам все равно нужна централизованная отчетность — обычно я делаю это, создавая диаграмму данных, которая получает данные от всех служб. freecontent.manning.com/wp-content/uploads/…
Ответ №2:
В этом случае вам необходимо создать как минимум 3 менеджера очередей в интеграции службы очередей сообщений для покупок, поставщиков и продуктов. И настройте очереди запросов и ответов.
Теперь эти запросы и ответы на данные могут быть в формате JSON или XML, как вам нравится.
Вам нужно создать прослушиватель, который будет отвечать за прослушивание очередей ответов, и вы можете создать что-то вроде потоковой передачи сигналов для непрерывного прослушивания.
Как только все интегрирование будет завершено, вы сможете напрямую ввести результат в свое клиентское приложение.