Озверин
Дата: 22.11.2018 15:23:06
Преамбула:
В общем случае , при выделении микросервисов в отдельную единицу, говорят о том, что 1 микросервис - 1 бизнес функция. Не стоит делить на функциональные слои(типа выделять в один микросервис DAO слой).
Кроме того, говорят, что если между двумя микросервисами есть много связей(один из них часто обращается к другому), то стоит думать о том, чтобы их объединить или рефакторить один из них таким образом, чтобы выделить часть функционала в другой микросервис(тесто связанный который).
Вопрос: если есть некий сторонний rest сервис с довольно сложным api, у которого меняются версии и все такое. Несколько микросервисов работают с этим сторонним rest сервисов. Если выделить в отдельный микросервис прослойку общения с этим сторонним сервисом, то мы нарушим оба пункта нашей прембулы, но получим единую точку поддержки при изменении версий api у стороннего сервиса. Кроме того, этот "слой общения с апи стороннего" сервиса рискует стать узким горлышком.
Были ли у вас схожие проблемы? Как решали? Просто выделяли его в отдельный джарник и использовали как библиотеку в микросервисах?
Дмитрий Мух
Дата: 23.11.2018 00:10:23
Озверин,
шаблон Gateway. Если нужен в разных местах, то в пакет, библиотеку.