Как определить URL шлюза API при разбиении монолита на микросервисы - PullRequest
Новая
       33

Как определить URL шлюза API при разбиении монолита на микросервисы

0 голосов
/ 04 июня 2018

Мы разбиваем монолитное приложение на микросервисы.Это будет постепенный процесс, это означает, что сначала мы начнем с 2-х микросервисов, позже мы разделим их на больше и так далее.

Монолай предоставляет REST API, который предоставляет методы для управления десятками различных объектов (например, пользователи, user_types, роли, role_types и т. Д.).Существует только один потребитель REST API, представленный монолитом, - приложение внешнего интерфейса Javascript.

В настоящее время мы изучаем две возможности настройки шлюза API (Zuul):

  1. URL-адреса будут содержать имя микросервиса, например, /api/dictionary будет обслуживать /api/dictionary/user_typesи /api/dictionary/role_types, тогда как /api/data будет служить /api/data/users и /api/data/roles.Это означает, что URL будут меняться со временем, когда мы создаем больше микросервисов.Каждый раз, когда мы делаем это, потребитель (внешний интерфейс) должен быть изменен.

  2. URL будут основаны на именах сущностей, например, /api/users, /api/user_types, /api/roles и /api/role_types.Недостатком является то, что конфигурация Zuul должна содержать явную конфигурацию для каждого отдельного объекта, управляемого системой.

Какой из приведенных выше подходов верен?

1 Ответ

0 голосов
/ 05 июня 2018

Мэнмей говорит правильно.Вы должны пойти с первым подходом для долгосрочной выгоды.Если вам все еще нужна альтернатива, вы можете объединить оба этих подхода, настроив свой API-шлюз таким образом, чтобы он направил ваш запрос

  • / api / users -> / api / data /пользователи
  • / api / user_types -> / api / dictionary / user_types
  • / api / role -> / api / data / role
  • / api / role_types -> /api / dictionary / role_types

При таком подходе вам не придется идти на компромисс с любыми проблемами, такими как обслуживание или изменения на стороне клиента.

...