Микросервисы. Очередное рассуждение

В последнее время активно исследую вопросы, связанные с микросервисной архитектурой. Наткнулся на статью-рассуждение Микросервисы и неизбежная боль?

Автор начинает с того, что сам термин "микросервис" неоднозначен и приводит разные определения. Я с ним согласен. Думаю, что чересчур много внимания уделяется микро. Мне же нравится обобщённое определение, что микросервисная архитектура – это стиль проектирования, который разбивает приложение на отдельные сервисы с разными функциями. И важно, что в нём ни слова о размере.

Далее по классике микросервисы сравниваются с service-oriented architecture (SOA) и монолитом. Тут нет ничего нового. Выделю отличия микросервисов от SOA:
– в SOA, как правило, сервис – это крупное монолитное приложение. Возможно, даже ставшее отдельным сервисом не по архитектурной задумке, а в силу исторических причин
– в SOA используется глобальная модель данных и общая БД
– в SOA для межсервисного взаимодействия используются умные и тяжеловесные протоколы вроде SOAP

Доходим наконец-то до боли, обозначенной в заголовке. Автор говорит о том, что часто видел:
– огромное количество разрозненных, отличающихся друг от друга репозиториев, созданных разными людьми
– большие усилия на поддержание обратной совместимости api, невозможность определить во всем зоопарке сервисов, кто это api использует и нужно ли оно вообще
– размывание технологического стека среди команд и сервисов, разные системы сборки и деплоя
– новые сервисы на каждый чих, дублирование кода

Что ж, у меня двоякое отношение к сказанному. Могу лишь сделать вывод, что любую архитектуру можно испортить. Ничего удивительного, микросервисы – не золотая пуля, они несут в себе набор проблем и ограничений. Важность перечисленных проблем в том, что о них нужно знать заранее, тщательно отслеживать и вовремя реагировать. Предупрежден – значит вооружён.

Возвращаясь к проблемам, для организации микросервисной архитектуры должны быть выстроены процессы и инженерная культура, созданы шаблонные сервисы, особое внимание должно уделяться CI/CD и observability.

Рассуждая о золотой середине, автор даёт, как мне кажется, вредные советы. Всё сводится к тому, что делаем условно монолитно, но, когда понадобится, легко сможем разбить на микросервисы. Предлагается использовать единый репозиторий с делением на директории посервисно, одну базу данных без связей между таблицами разных сервисов.

Не думаю, что это хорошая практика. Применение таких половинчатых мер незаметно приведет к появлению распределенного монолита, которому будут присущи проблемы как микросервисов так и монолита.

В конце банальный, но, кажется, работающий совет: перед принятием решения – думайте, приземляйте на свои реалии, не следуйте просто написанному в умных книгах. Помните о плюсах, которые предоставляет микросервисная архитектура, и думайте о том, чтобы не потеряться их, принимая то или иное решение. Хорошим примером может служить пост о том, как сложный паттерн Сага был адаптирован в более простую версию, исходя из требований конкретной задачи.

#skills