Допустим, я занимаюсь разработкой платформы блогов, где пользователи могут зарегистрировать аккаунт, заплатить за подписку и создать свои собственные блоги. Платформа состоит из следующих микросервисов:
- account-service
- auth-service
- subscription-service
- blog-service
- api-gateway
Я думаю о реализации шаблона api-gw, где все микросервисы, кроме api-gw, будут развернуты в частной сети (где они смогут общаться друг с другом напрямую либо синхронно, либо асинхронно через посредник сообщений), и они будут общедоступны только через api-gw.
Будет два клиента / потребителя API:
- внешний интерфейс (для клиентов)
- cms (для администраторов)
Поэтому я хочу использовать отдельный шаблон api-gw-per-client, поэтому на самом деле будет два шлюза api, один для обычного внешнего интерфейса ( frontent-api-gw) и один для cms (cms-api-gw), но оба будут общаться с одними и теми же микросервисами.
Мой вопрос касается авторизации и того, где она должна проходить (или, скорее, что за / минусы для диф разные подходы). Давайте сосредоточимся на двух «конечных точках»:
- frontend-api-gw :: createBlog () => blog-service :: createBlog ()
Frontend api-gw предоставляет конечную точку для создания нового блога, и этот вызов API «перенаправляется» в конечную точку blog-service :: createBlog (). Допустим, что пользователь уже аутентифицирован (т.е. передается правильный JWT с идентификатором пользователя вместе с запросом к api-gw).
Необходимо выполнить авторизацию, чтобы определить, может ли пользователь с этим идентификатором создать новый блог. , Это можно сделать, позвонив в службу подписки, чтобы проверить, оплатил ли пользователь подписку. Основной вопрос заключается в том, должно ли это разрешение выполняться еще на стороне API-интерфейса (A) или на стороне службы блогов (B):
cms-api-gw / frontend-api-gw :: listBlogs () => blog-service :: listBlogs ()
Аналогичный случай - если будет передан userContext / JWT в любом формате каждому микросервису, и этот микросервис должен решить, что вернуть? Или отдельные микросервисы не должны знать о userContext (возможно, только для целей регистрации), полагаться на авторизацию API GW и просто получать некоторые параметры / аргументы?
Мои мысли:
В случае A логика c в каждом отдельном микросервисе более сложна из-за уровня авторизации. Может быть сложнее, где будет больше API gws, пользовательских ролей и т. Д. c. Однако API GW в этом случае проще, и он только перенаправляет запросы к микросервисам.
В случае B логика c в каждом отдельном микросервисе менее сложна, проста и понятна. Однако в API GW больше логики c, потому что она должна реализовывать авторизацию для всех платформ (по крайней мере, для той части, за которую отвечает этот API). Может быть, также может быть преимуществом иметь всю авторизацию в одном месте и не распространяться на микросервисы?
Также, в случае B, я думаю, что связь между отдельными микросервисами будет меньше.
Что вы, ребята, думаете из этих двух подходов / может быть, у вас есть другие "идеи"?