GG
а у тебя задача M2M
Size: a a a
2020 December 30
GG
если ты хочешь edge, а не сервис-сервис, то тебе api gateway нужен
T
Но в итоге сервису может прилететь запрос как от пользователя с jwt, так и от другого сервиса
T
Но в итоге сервису может прилететь запрос как от пользователя с jwt, так и от другого сервиса
И закладывать два механизма проверки?
GG
тут проблематика в том, что у тебя нужный функционал как бы находится на пересечении нескольких типов (классов) решений
T
И толком ничего не гуглится, да :)
T
Хотя наверняка задача типовая
T
И не я первый с ней сталкиваюсь
GG
И закладывать два механизма проверки?
один из вариантов :-/ у тебя все равно два типа учеток - пользовательские (из какого-то внешнего каталога) и сервисные (СПуЗы, ТУЗы или как их еще называют)
GG
я тебе сказал - service mesh or api gateway
GG
теоретически ты можешь каждый сервис снадбить сайдкаром от киклоаки и ходить в нее... но это какой-то адовый менеджмент
T
Т.е. по факту мы приводим где-то на третьей стороне все запросы к единому знаменателю, попутно разбираясь, от кого они там прилетели - от пользователя или от другого сервиса?
GG
предложение такое - почитай про указанные мной продукты и приходи с более конкретными запросами )
GG
Т.е. по факту мы приводим где-то на третьей стороне все запросы к единому знаменателю, попутно разбираясь, от кого они там прилетели - от пользователя или от другого сервиса?
один из вариантов )
T
Почитаю обязательно, да
T
Спасибо в любом случае :)
GG
ибо не факт, что ты хочешь трафик петлей заворачивать от сервиса через эту проксю (тот же API GATEWAY)
GG
это типа SPOF получается
T
ибо не факт, что ты хочешь трафик петлей заворачивать от сервиса через эту проксю (тот же API GATEWAY)
Угу