Переход от монолита к микросервисам

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

Распространенной альтернативой предметно-ориентированной декомпозиции является волатильность. Декомпозиция на основе волатильности предусматривает выделение наиболее часто меняющихся частей системы в отдельные микросервисы. Этот метод может быть очень полезен, если ваша основная цель - скорость выхода продукта на рынок (TTM, time to market). Но если этот подход вынуждает вас выносить сервис за рамки организационных границ, скорость доставки продукта непременно начнет снижаться.

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

Прежде чем перейти к описанию шаблонов, я хочу дать дисклеймер. Микросервисы не должны быть самоцелью. Это не панацея. Зацикленность на микросервисах приводит к тому, что вы перестаете рассматривать альтернативные варианты решения поставленных задач. Иногда проще и разумнее использовать монолит. Например, масштабировать имеющийся монолит порой эффективнее через использование балансировщика нагрузки, нежели долгая последовательная декомпозиция на микросервисы. Поэтому, в первую очередь, определите стоящие перед вами цели. А затем подбирайте наиболее простые инструменты для их достижения.

Если вы осознанно подошли к разделению вашего монолита на микросервисы, стоит определиться с шагами. Что стоит выносить первым - код или базу данных? Рекомендуется детально изучить возможность выделения кода и базы данных, а затем определиться с приоритетностью. Наиболее распространенным первым шагом является вынесение кода с сохранением единой (с монолитом) базы данных. Как правило, если извлечь код не получается, можно остановить работы и избежать необходимости распутывать зависимости базы данных.

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

Шаблон "Душитель" (Strangler Fig Pattern) заключается в постепенном переводе функционала старой системы в новую. Осуществляется перехват вызовов к существующей монолитной системе и перенаправление на микросервис для новой функциональности. Оставшуюся функциональность обеспечивает монолит и соответствующие запросы направляются на него. Отличительной особенностью этого шаблона является то, что никаких изменений в монолит не вносится. Это преимущество можно использовать для параллельного исполнения вызовов на старом и новом коде с последующим сравнением результатов.

Шаблон переключаемых функций (feature toggle или feature switcher) - это механизм, используемый для включения, выключения, а также переключения между версиями функциональности. В нашем случае функциональность в монолите и микросервисе может быть разной и данный механизм позволяет переключаться между реализациями в зависимости от обстоятельств (например, через boolean флаг).

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

Подписывайтесь на мой телеграм-канал, чтобы не пропустить свежие публикации. И до скорых встреч!