Шпаргалка по миграции монолита на микросервисы

В этой статье поговорим о подходах и вариации как можно мигрировать приложение на микросервисную архитектуру и в каких случаях игра стоит свеч

1. Введение

Монолитная архитектура

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

Преимущества монолитной архитектуры:

• Проще в разработке: все компоненты приложения находятся в одном месте, что упрощает отладку и тестирование.
• Не сложно: нет необходимости координировать взаимодействие между различными сервисами или модулями.
• Простота деплоя: приложение деплоится как единый инстанс, что облегчает деплой и мониторинг.
• Производительность: теоретически может работать быстрее чем сервисная или микросервисная архитектура, так как не нужно взаимодействовать с различными сервисами и базами данных.

Недостатки монолитной архитектуры:

• Масштабируемость: если вам нужно масштабировать определенную часть приложения, вы должны будете масштабировать все приложение.
• Change management: изменения в одной части приложения могут влиять на все приложение, что делает апдейты более рискованными.
• Затяжной деплой: из-за размера монолитных приложений, процессы деплоя и тестирования могут быть длительными.
• Препятствия для внедрения технологий: любые изменения в инфраструктуре или языке разработки влияют на  все приложение, что зачастую приводит к увеличению стоимости и временных затрат.
• Недостаточная гибкость: возможности монолитных приложений ограничены используемыми технологиями.

Микросервисная архитектура

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

Преимущества микросервисной архитектуры:

• Масштабируемость: Можно масштабировать только те сервисы, которые требуют больше ресурсов, вместо масштабирования всего приложения.
• Быстрый деплой: Так как каждый сервис меньше монолитного приложения, процессы развертывания и тестирования будут происходить быстрее.
• Независимость компонентов: Отказ одного сервиса не обязательно приводит к отказу всего приложения. Это улучшает устойчивость системы.
• Гибкость в выборе технологий: Каждый микросервис может быть написан на разных языках программирования, использовать разные технологии хранения данных и разные системы очередей сообщений, что определяется его специфическими требованиями.

Недостатки микросервисной архитектуры:

• Сложность управления: Управление множеством сервисов, которые взаимодействуют друг с другом, может быть сложным.
• Consistency: Разделение одной базы данных на множество сервисов может создать проблемы с консистентностью данных.
• Отсутствие стандартизации: Без общей платформы может возникнуть ситуация, в которой расширяется список языков, стандартов ведения логов и средств мониторинга.
• Требования к инфраструктуре: Микросервисы обычно требуют более сложной инфраструктуры для управления развертыванием, мониторингом и отказоустойчивостью сервисов.

2. Определение стратегии миграции

Когда следует переходить на микросервисы

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

Смотрите так же reference architecture, это поможет вам опредлелиться с подходом.

Когда не стоит переходить на микросервисы

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

1. Малый размер проекта: Микросервисы наиболее эффективны в масштабных приложениях, где сложность управления и разработки может быть снижена разделением функциональности на отдельные сервисы. Если у вас проект маленький или средний по размеру, миграция на микросервисы может привести к ненужной сложности и издержкам.
2. Недостаток ресурсов: Микросервисы требуют значительных затрат на сетап и поддержку. Если у вашей команды недостаточно ресурсов например: квалифицированных разработчиков, времени, денег, переход на микросервисы может оказаться идеей так себе.
3. Команда не готова: Микросервисная архитектура требует определенного набора навыков и знаний. Если ваша команда не готова к этому изменению в архитектуре или не имеет необходимых навыков, это может привести к проблемам в будущем.
4. Устойчивость текущей архитектуры: Если ваш текущий монолитный проект функционирует хорошо, стабилен и соответствует бизнес-требованиям, переход на микросервисы может быть ненужным и даже рискованным шагом.
5. Требуется быстрый старт: Если вам нужно быстро запустить проект и начать получать фидбек от пользователей, микросервисы могут замедлить этот процесс. Монолитные архитектуры обычно позволяют быстрее выйти на рынок.
6. Высокие требования к согласованности данных: Микросервисы обычно следуют паттерну базы данных на сервис, что может создавать сложности при согласовании данных между сервисами. Если ваш проект требует высокого уровня согласованности данных, микросервисы могут оказаться не подходящим решением.
7. Тесная связанность компонентов: Если функциональные компоненты вашего приложения тесно связаны и не могут быть легко изолированы, переход на микросервисы может потребовать значительной переработки кода и архитектуры.
8. Сложности отладки и мониторинга: Микросервисы могут затруднить дебаг и мониторинг, поскольку траблы могут быть распределены по многим сервисам и зависеть от взаимодействия между ними.

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

Оценка готовности бизнеса и технологического стека для миграции

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

Выбор подхода к миграции: "Большой взрыв" vs постепенный переход

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

3. Стратегии миграции на микросервисы

Стратегия "Большого взрыва"

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

Стратегия деления микросервисов по существующим границам модулей

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

Стратегия "базы данных на микросервис"

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

Стратегия "строительный блок"

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

4. Подход к разбиению монолита на микросервисы

Выше мы обсудили несколько стратегических направлений. В этой части обсудим наиболее взвешенный и структурированый подход к разбиению монолита на микросервисы в 6 шагах:

Определение логических компонентов

Существует три основных информационных компонента с данными, используемыми в системе:

1. data object
2. data action
3. use-cases

Миграция от монолитной системы к микросервисам обычно не затрагивает непосредственно UI. Таким образом, подходящие для миграции компоненты определяются тем, какие компоненты:

• используются наибольшим количеством пользователей
• используются наиболее часто
• имеют наименьшее количество зависимостей от других компонентов
• работают слишком медленно

Рефакторинг компонентов

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

Определение зависимостей компонентов

Теперь необходимо определить зависимости между компонентами монолита. Для этого можно использовать какой-то анализатор кода, или прочие тулы.

Определение групп компонентов

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

Перенос групп компонентов в макросервисы

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

Основная цель на этом этапе - перенести группы компонентов в отдельные проекты и задеплоить их по отдельности.

Миграция макросервисов к микросервисам

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

5. Паттерны миграции монолита на микросервисы

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

Strangler-Fig Pattern

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

Branch by Abstraction Pattern

Этот паттерн помогает улучшить Strangler-Fig Pattern подход. Так как в предыдущем варианте, как-то все равно нужно отлавливать вызовы с монолита к старому функционалу. Шаги которые выполняются в Branch by Abstraction:

• Построить абстракцию для заменяемой функциональности.
• Реализовать новую абстракцию в существующем модуле.

• Реализовать новую функциональность в новом сервисе. В течение некоторого времени эта реализация будет простаивать и не будет связана ни с каким функциональным флоу.

• Реализуем сервис провайдер или какой-то враппер для коммуникации с новосозданным сервисом

• Ваши сервисы теперь могут использовать сервис провайдер и вы можете отказатся от абстракции и удалить старую функциональность с монолита.

Decorating collaborator pattern

Этот шаблон вдохновлен классическим паттерном из GoF – декоратором. В данном случае, как и в паттерне strangler, мы должны ввести прокси. Мы будем пропускать вызовы через прокси к монолиту, и на основе ответа от монолита прокси будет вызывать наш вновь созданный микросервис.

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

Parallel Run Pattern

Паттерн strangler fig и паттерн branch by abstraction позволяют одновременно сосуществовать в проде старым и новым реализациям одной и той же функциональности. Обычно обе эти техники позволяют нам выполнять либо старую реализацию в монолите, либо новое решение на базе микросервисов. Чтобы снизить риск перехода на новую реализацию на основе сервисов, эти процедуры позволяют нам быстро переключиться обратно на предыдущую реализацию.

Parallel Run паттерн использует 2 реализации одновременно, но как единый источник истины старую реализацию, это позволяет тестить в автомате новую реализацию и к примеру создавать алерты если при каких-то вводных новый сервис выдает не тот же результат, что выдавал монолит.

6. Технические аспекты миграции

Изменение процесса разработки и внедрение DevOps

Переход к микросервисам требует изменения подхода к разработке и деплою приложения. Внедрение DevOps практик становится крайне важным, так как микросервисы часто обновляются и развертываются независимо друг от друга. Это может включать в себя использование CI/CD, автоматизированного тестирования и мониторинга. Так же рекомендуем посмотреть нашу статью Выбор стратегии деплоя микросервисов

Использование API Gateway

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

Управление данными и миграция базы данных

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

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

Согласованность данных: В монолитах обеспечение согласованности данных относительно просто, так как все данные находятся в одной базе данных. Но в микросервисах, где каждый сервис имеет свою базу данных, обеспечение согласованности становится более сложной задачей. Нужно внимательно рассмотреть, как обеспечить согласованность в таком распределенном контексте, возможно, с использованием таких техник, как BASE (Basically Available, Soft state, Eventual consistency) вместо ACID (Atomicity, Consistency, Isolation, Durability).

Миграция данных: Сам процесс миграции данных из монолитной базы данных в микросервисные базы данных может быть сложным. Это может включать в себя экспорт данных из старой базы данных, преобразование этих данных в формат, подходящий для новых баз данных, и импорт данных в новые базы данных. Все это должно быть тщательно спланировано и тестировано, чтобы минимизировать риск потери данных или прерывания бизнес-процессов. Хорошим подходом есть приминение Change Data Capture паттерна

Управление сессиями и аутентификацией

Аутентификация и управление сессиями становятся сложнее в микросервисной архитектуре, поскольку необходимо обеспечить безопасность и непрерывность пользовательской сессии при обращении к различным сервисам. Можно рассмотреть использование централизованного сервиса аутентификации или токенов на основе стандартов, таких как JSON Web Tokens (JWT), для обеспечения безопасности.

у необходимо обеспечить безопасность и непрерывность пользовательской сессии при обращении к различным сервисам. Можно рассмотреть использование централизованного сервиса аутентификации или токенов на основе стандартов, таких как JSON Web Tokens (JWT), для обеспечения безопасности.