Комментарии 8
Микросервис сердечек? О.о
А вам не кажется, что вы пошли по пути распределенного монолита вместо независимых (микро) сервисов?
И в догонку - не рассматривали вариант начать с отделения сервиса аутентификации? В этой предметной области есть куча готовых решений (а для вас это явно не кор бизнес) и управление токенами это точно отдельная задача.
Микросервис сердечек? О.о
Спасибо за комментарий. Пример самого сервиса действительно может показаться простым. В реальности кейса, который стал толчком к изменениям, другой (это инструмент для работы с партнерами). Я хотел избежать долгого погружения читателя в бизнес-логику сфокусировать с большей степени на самом решении, для чего сознательно изменил пример. К тому же оригинальной задачей было вынести сервис из монолитного приложения, что тоже смещает фокус.
Но после внедрения "решения на базе монолита" пошла волна независимых реализаций сервисов, который могли обслуживать клиентский трафик, при пользуясь результатом аутентификации. В этом плане решение в большей степени стало энейблером для запусков новых сервисов, нежели декомпозиции и выноса старых.
Спасибо, тогда понятно.
Статья в разделе «кейс», а уточнения что реальный сервис заменили примером нет. Поэтому создаются впечатление, что это реальный пример.
Благодарю. Внес правки в текст, чтобы не вводить читателя в заблуждение! Справедливости ради отмечу, что "избранное" (которое я упростил до "сердечек") - один из сервисов, использующих "стандарт": так же принимает X-AUTH-IDENTITYзаголовок.
Еще любопытный момент: с перспективы перевода самого монолита на "стандарт", он становится всего лишь одним из сервисов, пользующихся заголовками. Клиентская часть его логики абстрагируется от аутентификации, логически декомпозируя монолит на 2 части: для обслуживания аутентификации и для обслуживания бизнес-логики.
Ага, у меня недавно был похожий кейс и мы начали с выделения сервиса аутентификации, а монолит был первым его клиентом.
Было сильно сложнее, чем выделить просто абстрактный сервис, но не понадобилось делать какие-то временные схемы. Кроме компенсационной логики для поддержки старых рефреш токенов, которые были валидны 45 дней. Но она в любом случае была нужна и в общем-то была тривиальной.
Подскажите тулу в которой картинки рисовали. Это draw.io с какой-то темой?
Нарисовал в Миро, тема - стандартный цвет плюс прозрачность.
Еще коллеги порекомендовали интересный тулинг https://excalidraw.com/, но я пока не пробовал.
И в догонку - не рассматривали вариант начать с отделения сервиса аутентификации?
Масштаб изменений при выносе сервиса аутентификации сразу, на мой взгляд, значительно больше (исследование, прототип, реализация, внедрение). Нужен более обстоятельный поход и большее количество временных затрат. Поэтому пошли эволюционным способом, развивая, что есть:
распутали логику аутентификации в монолите
обособили ее, и отвязали сервисы (в том числе и сам монолит)
а дальше пошли по пути выделения сервиса аутентификации
Ретроспективно скажу, что такой подход себя оправдал и позволил выиграть время. Наступить при этом на множество граблей: предварительно завести клиентский трафик по API-гейтвей, систематизировать многогранную логику аутентификации и т.д. - что в любом случае пришлось бы делать.
В этом смысле предлагаемый вариант, это часть плана решения вопроса аутентификации, с большим фокусом на практический результат. Но все лишь часть.
Как мы реализовали аутентификацию трафика для MSA на базе монолита