Преамбула:
В общем случае , при выделении микросервисов в отдельную единицу, говорят о том, что 1 микросервис - 1 бизнес функция. Не стоит делить на функциональные слои(типа выделять в один микросервис DAO слой).
Кроме того, говорят, что если между двумя микросервисами есть много связей(один из них часто обращается к другому), то стоит думать о том, чтобы их объединить или рефакторить один из них таким образом, чтобы выделить часть функционала в другой микросервис(тесто связанный который).

Вопрос: если есть некий сторонний rest сервис с довольно сложным api, у которого меняются версии и все такое. Несколько микросервисов работают с этим сторонним rest сервисов. Если выделить в отдельный микросервис прослойку общения с этим сторонним сервисом, то мы нарушим оба пункта нашей прембулы, но получим единую точку поддержки при изменении версий api у стороннего сервиса. Кроме того, этот "слой общения с апи стороннего" сервиса рискует стать узким горлышком.

Были ли у вас схожие проблемы? Как решали? Просто выделяли его в отдельный джарник и использовали как библиотеку в микросервисах?