Настроить конечные точки API нижнего уровня в микросервисах - PullRequest
Новая
       94

Настроить конечные точки API нижнего уровня в микросервисах

0 голосов
/ 10 июля 2020

В мире микросервисов, каков рекомендуемый способ настройки конечной точки нисходящего API?

Например, если службе A необходимо вызвать конечную точку в службе B, у нас есть два варианта:

а. Сделайте имя хоста и номер порта API службы B настраиваемыми в службе A (service-b: 8080) и добавьте URI пути в свой код

или

b. Сделайте всю конечную точку настраиваемой в службе A (http://service-b: 8080 / somepath)

Хотя мне нравится идея сделать настраиваемую конечную точку, она оставляет много места для ошибок, потому что необходимо указать весь путь . Это также не подходит, когда необходимо вызвать несколько конечных точек из службы A в службу B, которые потенциально могут иметь разные пути, что требует от нас настройки нескольких конечных точек.

С другой стороны, вариант (a) кажется более масштабируемый по вышеупомянутым причинам.

Большинство результатов поиска в Интернете просто продемонстрировали, как служба может вызывать другую службу, и для демонстрации этого использует жестко запрограммированный URL. Было бы неплохо узнать, как сообщество делает это в реальных проектах.

PS: Мы используем Spring Webflux и выполняем развертывание на k8s.

1 Ответ

0 голосов
/ 10 июля 2020

В основном я видел, что команды используют вариант a, где serviceB «baseUrl» (который в основном https://serviceb-hostname: 8080) вводится как свойство среды (kubernetes configmap) в приложение во время развертывания.

Указанные c пути, указанные в API, c, настраиваются в yaml приложения или в самом классе "proxy config" как константы (например, ServiceBProxy. java - прокси-классы - это те, которые будут выполнять rest-вызовы зависимых служб. как сервис B).

Вот часть yaml приложения из одного из микросервисов (из одного из моих проектов): 

authorizationService:
  baseUri: ${authorizationServiceBaseUri}/api

tenantService:
  baseUri: ${tenantServiceBaseUri}/api/v1
  tenantsUri: ${tenantService.baseUri}/tenants

settingsService:
  baseUri: ${settingsServiceBaseUri}

iamService:
  fetchBatchSize: 500
  baseUri: ${iamServiceBaseUri}

Здесь значения iamServiceBaseUri, settingsServiceBaseUri, tenantServiceBaseUri, authorizationServiceBaseUri все внедряются во время развертывания. И каждый из них содержит clusterIP с портом.

...