Мы называем это API Gateway с. Но он не состоит из нескольких сервисов. Как мы называем эту часть в нашем решении? Прокси что ли? Любой хороший пример для тонких контроллеров и микросервисной архитектуры микро-услуги». Я предполагаю, что под этим «внешним / микро-сервисом» вы имеете в виду, что вы вызываете другой микро-сервис из вашего текущего обработчика микро-сервисов (Command and Query). Эти «внешние / микро-сервисы» являются частью вашей архитектуры и развернуты в одном кластере, а не в какой-то внешней системе, которая просто предоставляет доступную c API? Если это правильно, я постараюсь ответить на основании этого предположения.
API Gateway, вероятно, будет вводить в заблуждение в этом случае, поскольку понятие API Gateway отличается от того, что вы пытаетесь сделать здесь.
API Gateway по определению:
Цитата здесь :
API Gateway - это сервер, который это единственная точка входа в систему. Это похоже на шаблон Фасад из объектно-ориентированного дизайна. API Gateway инкапсулирует внутреннюю архитектуру системы и предоставляет API, адаптированный для каждого клиента. У него могут быть другие обязанности, такие как аутентификация, мониторинг, балансировка нагрузки, кэширование, формирование запросов и управление ими, а также обработка статических ответов.
То, что вы на самом деле пытаетесь сделать, - это вызывать из вашей команды или запроса Обработчик одной из ваших микросервисов A, другой микросервис B. Это внутренняя коммуникация микросервисов, которая не должна осуществляться через API Gateway, поскольку это будет подходом для внешних вызовов. Например, под «внешними вызовами» я подразумеваю внешние приложения API или публичные c API вызовы, которые пытаются вызвать ваши микро-сервисы. В этом случае вы должны использовать API Gateway s.
Лучшим именем для этого компонента будет что-то вроде «CrossMicroServiceGateway» или «InterMicroServiceGateway»; если вы хотите использовать его как полный CQRS способ, которым вы можете использовать его как прямой вызов другой команды или запроса, а затем использовать что-то вроде «QueryGate» или «CommandGate» или аналогичное.
Другие предложения:
WebApi
Обработчики запросов
Обработчики команд
Repository
API Gateway s (вот интерфейсы и реализация вызовов микросервиса)
Это звучит разумно, за исключением пункта API Gateway, который я описал выше. Конечно, мне трудно сказать, основываясь на ограниченной информации, которую я имею о вашем проекте. Чтобы дать вам более точное предложение, мне нужно знать, используете ли вы DDD или нет? Как вы используете CQRS и другую информацию?
Однако мы используем внешние микросервисы для получения данных, которые мы им вызываем, из обработчиков запросов. Все клиентские конструкции и вызовы HTTP будут в них абстрагированы. Ответ будет преобразован в модель представления и передан обратно в обработчик запросов.
Вы можете извлечь весь этот код / logi c, который обрабатывает межсервисную связь через HTTP или другие протоколы, обрабатывающие общие ответы и похожие на некоторую базовую библиотеку и включающие ее в каждый ваш микро-сервис в виде пакета. Таким образом, вы будете повторно использовать решение для всех ваших микро-услуг. Вы можете расширить это и добавить все основные доменные свойства c (такие как доступ к данным или базовые классы репозитория, обертки вокруг HTTP, настройка инфраструктуры модульного тестирования и т. П.) В эту или другие общие библиотеки. Таким образом, ваши микро-сервисы будут сосредоточены только на той части Домена, которую они должны делать.