При большом количестве микросервисов в проекте приходится сталкиваться с тем, что в некоторых из них нужно дублировать один и тот же код (утилитные классы, настройки конфигураций и прочее), а обнаружив баг в одном месте, искать и исправлять его везде. При этом, если микросервисы поддерживаются разными разработчиками, то каждый будет исправлять баг по-своему и в дальнейшем будет сложнее привести всё к единообразию. Давайте на примере рассмотрим несколько подходов к переиспользованию кода в микросервисах.

Часто в микросервисной архитектуре возникают проблемы, связанные с обновлением версий библиотек или их подключением. Работая над каким-либо проектом в течение долгого времени можно столкнуться с тем, что разные микросервисы используют разные версии одной и той же библиотеки и ее обновление может затянуться из-за конфликтов. В данной статье я хотел бы описать один из способов решения этих проблем.

В эпоху микросервисов приходится все чаще и чаще писать интеграции для их взаимодействия как между собой, так и со сторонними системами. Кто-то создаёт отдельные библиотеки с интеграцией и переиспользует их в нескольких микросервисах, кто-то захламляет проект огромным количеством POJO классов, некоторые же создают один POJO класс с множеством вложенных классов. В этой статье я хотел бы поделиться подходом, используя который вы сможете спрятать большую часть кода, которая мешает чтению и пониманию проекта.

Для примера мы будем использовать интеграцию с API GitHub и привычные Spring аннотации для описания нашего feign клиента.