Все зависит от точных требований вашего проекта.
API шлюза обычно используется, чтобы скрыть сложность микросервиса от внешних пользователей, которые обычно имеют 1 конечную точку для общения.
Также шлюз может управлять безопасностью и аутентифицировать пользователя (что на самом деле делают многие компании).
Теперь, когда вы проходите шлюз и ваш аутентифицированный запрос достигает клиента, обычно у вас уже есть идентификационная информация пользователя в запросе. (что было введено в запрос шлюзом).
Итак, вы знаете, что пользователь "Джон Смит" инициировал запрос.
И теперь, если вам нужно позвонить в другой микросервис, вы должны решить, (и снова ваше решение):
Нужна ли вам вообще аутентификация (возможно, внутренняя связь не должна быть защищена между микросервисами (
Если вы делаете аутентифицированный вызов из микросервиса A в микросервис B и поток был создан пользователем John Smith, который вызвал запрос к сервису A, вы должны решить, является ли семантика вызова:
- Пользователь «John Smith» связывается со службой B, или ...
- Служба A связывается со Службой B от имени пользователя John Smith. Это действительно важно для авторизации, если у вас есть какая-либо система разрешений.
В терминах технической реализации обычно вы можете добавить заголовок JWT к запросу с требуемым токеном. Если запрос уже прошел проверку подлинности, и вам необходимо сгенерировать личность пользователя, вы можете просто добавить пару заголовков в запрос.