Монолиты и микросервисы — два основных подхода к созданию приложений. Некоторые считают их устаревшими и современными соответственно. Но это не совсем так. Выбор между ними — очень сложный вопрос, и у обоих есть свои плюсы и минусы. Большинству новых приложений не нужно быть микросервисами с самого начала. Быстрее, проще и дешевле начать как монолит и перейти на микросервисы позже, если вы найдете это выгодным. Со временем, поскольку монолитные приложения становятся все менее и менее удобными для обслуживания, некоторые команды решают, что единственный способ решить проблему — начать рефакторинг, разбивая свое приложение на микросервисы. Другие команды принимают это решение просто потому, что «микросервисы — это круто». Этот процесс занимает много времени и иногда влечет за собой еще большие накладные расходы на обслуживание. Прежде чем приступить к этому, крайне важно тщательно взвесить все «за» и «против» и убедиться, что вы достигли текущих пределов архитектуры монолита. И помните, сломать легче, чем построить. В этой статье мы не будем сравнивать монолиты с микросервисами. Вместо этого мы обсудим соображения, шаблоны и принципы, которые помогут вам: извлеките максимум пользы из вашего текущего монолита и подготовьте его к потенциальному взлому на микросервисы; обеспечить плавную миграцию от монолита к микросервисам; понять, что еще может измениться при миграции микросервисов. Модульный монолит Первое, что вам следует сделать, это посмотреть на структуру вашего проекта. Если у вас нет модулей, я настоятельно рекомендую вам рассмотреть их. Они не заставляют вас менять архитектуру на микросервисы (что хорошо, поскольку мы хотим избежать всего соответствующего обслуживания), но извлекают из них много преимуществ. В зависимости от инструмента автоматизации сборки вашего проекта (например, maven, gradle или другого) вы можете разделить свой проект на отдельные независимые модули. Некоторые модули могут быть общими для других, в то время как другие могут инкапсулировать определенные области домена или быть специфичными для функций, привнося независимую функциональность в ваше приложение. Это даст вам следующие преимущества: Разделенные части вашего приложения. Функции можно разрабатывать независимо, что сводит к минимуму конфликты. Намного проще принимать на работу новых людей, поскольку им не нужно глубоко погружаться в весь проект; вместо этого они могут начать с отдельных частей. Улучшенное тестирование, так как теперь вы можете тестировать каждый модуль отдельно. Если вам в конечном итоге придется перейти на микросервисы, у вас есть для этого очень веская основа. Как видите, модульный монолит — это способ получить лучшее из обоих миров. Это похоже на запуск независимых микросервисов внутри одного монолита, но при этом избегается сопутствующая нагрузка микросервисов. Одно из ограничений, которое у вас может быть, — это невозможность масштабировать различные модули независимо. У вас будет столько экземпляров монолита, сколько потребуется наиболее загруженному модулю, что может привести к чрезмерному потреблению ресурсов. Другим недостатком являются ограничения использования различных технологий. Например, вы не можете смешивать Java, Golang и Python в модульном монолите, поэтому вы вынуждены придерживаться одной технологии (что, как правило, не является проблемой). Узор «Странглер Фиг» Подумайте о шаблоне Strangler Fig. Он получил свое название от дерева, которое обвивается вокруг и в конечном итоге заменяет своего хозяина. Аналогично, шаблон предлагает вам заменить части устаревшего приложения новыми службами одну за другой, модернизируя старую систему, не вызывая существенных сбоев. Вместо того, чтобы пытаться провести рискованный, всеобъемлющий капитальный ремонт, вы обновляете систему по частям. Этот метод полезен при работе с большими, сложными монолитами, которые слишком громоздки, чтобы заменить их одним усилием. Приняв шаблон Strangler Fig, команды могут постепенно отказываться от старой системы, одновременно способствуя росту новой, минимизируя риски и обеспечивая непрерывную поставку ценности. Чтобы реализовать шаблон Strangler Fig, вам необходимо выполнить три шага: Здесь вы определяете, какую часть извлечь из монолита и реализовать ее как отдельный микросервис. Перепишите эту часть с использованием современных технологий и устраните проблемы предыдущей реализации. Воспользуйтесь шансом сделать это лучше. Transform. Когда новый микросервис готов к производству, вы запускаете его в своей инфраструктуре, сохраняя устаревшую реализацию. Вы распределяете трафик в некоторой пропорции, постепенно перемещая все больше трафика в новую реализацию, но у вас всегда есть предыдущая версия в качестве отката. Сосуществование. Через некоторое время, когда вы убедитесь, что ваш новый микросервис достаточно надежен, переместите весь трафик в новый микросервис и удалите устаревший. Устранить. Выполняя эти три шага, вы постепенно разобьете монолит на микросервисы. Основные преимущества использования узора Strangler Fig: Вместо того, чтобы ломаться и начинать своевременный, подавляющий и рискованный полный капитальный ремонт системы, шаблон позволяет вам переходить шаг за шагом. Вы можете медленно обновлять свою систему и синхронизировать эту трансформацию с планами разработки функций. Например, вы можете найти часть монолита, на которую серьезно повлияет разработка некоторых функций, и выбрать ее в качестве кандидата на миграцию микросервисов. Постепенная миграция. Это преимущество вытекает из предыдущего утверждения. Процесс модернизации не мешает вашей команде непрерывно поставлять новые функции. Пока одна команда разрабатывает новые функции, другая рефакторит независимые модули. Непрерывная поставка. Шаблон Strangler Fig помогает команде сосредоточиться на модернизации определенных частей системы. Этот фокус позволяет команде уделять больше внимания деталям в определенных областях, находить потенциальные проблемы раньше и минимизировать общее воздействие на приложение. Снижение рисков. Вопросы и соображения Применяя шаблон Strangler Fig, следует тщательно спланировать стратегию миграции. Она включает в себя определение компонентов, которые следует заменить в первую очередь, обеспечение надлежащей интеграции между старыми и новыми частями и поддержание согласованных моделей данных. Команды также должны установить четкие каналы связи и системы мониторинга для отслеживания хода и влияния каждой замены. Последствия миграции микросервисов Как мы уже обсуждали ранее, переход на микросервисы приносит выгоды. Однако он также делает многие другие вещи более сложными и дорогими. Например, команды QA и Dev могут столкнуться с ситуацией, когда они больше не смогут тестировать на локальных машинах, поскольку возможность локального запуска нескольких микросервисов ограничена. Или ваши журналы могут стать менее информативными, поскольку вместо того, чтобы одна служба обрабатывала один поток, теперь его обрабатывают несколько служб. В результате, чтобы просмотреть полную последовательность журналов, вам необходимо реализовать надлежащее инструментирование и трассировку. Давайте обсудим несколько важных аспектов, которые следует учесть и, возможно, спланировать до начала преобразования микросервисов. Развертывание и инфраструктура Монолит и микросервисы имеют разные минимальные требования к инфраструктуре. При запуске монолитного приложения вы обычно можете поддерживать более простую инфраструктуру. Такие варианты, как виртуальные машины или решения PaaS (например, AWS EC2) будут достаточны. Кроме того, вы можете управлять большей частью масштабирования, конфигурации, обновлений и мониторинга вручную или с помощью простых инструментов. В результате вы можете избежать сложных настроек инфраструктуры и положиться на разработчиков или инженеров поддержки, не требуя обширных знаний DevOps. Однако принятие архитектуры микросервисов меняет эту динамику. По мере роста количества сервисов ручной, практический подход быстро становится непрактичным. Для эффективной оркестровки, масштабирования и управления несколькими сервисами вам понадобятся специализированные платформы, такие как Kubernetes или, по крайней мере, управляемый контейнерный сервис, что вводит новый уровень сложности и эксплуатационных требований. Уровень платформы Поддерживать монолитное приложение относительно просто. Если возникает CVE, вы обновляете затронутую зависимость в одном месте. Нужно стандартизировать внешнюю связь сервиса? Реализуйте одну оболочку и повторно используйте ее во всей кодовой базе. В среде микросервисов эти простые задачи становятся намного сложнее. То, что раньше было тривиальным, теперь включает в себя координацию изменений в нескольких независимых сервисах, каждый со своим жизненным циклом и зависимостями. Дополнительная сложность увеличивает затраты времени и ресурсов. И ситуация ухудшается, когда у вас много команд и много разных сервисов. Поэтому многие организации вводят выделенный уровень платформы, обычно управляемый командой платформы. Цель состоит в том, чтобы создать основу, которую могут унаследовать все микросервисы: управление общими зависимостями, реализация стандартизированных шаблонов и предоставление готовых оберток. Объединяя эти элементы на уровне платформы, вы значительно упрощаете обслуживание и способствуете согласованности во всей системе. Заключение Разбиение монолита на микросервисы — это значительное архитектурное преобразование, требующее тщательного рассмотрения и планирования. В этой статье мы обсудили шаги, которые вы можете предпринять, чтобы подготовиться к этому и пройти процесс гладко. Придерживаясь шаблона Strangler Fig, вы получите постепенный процесс и обеспечите стабильность системы на протяжении всего преобразования. Кроме того, модульный монолит может быть не только полезным подготовительным шагом, но и может принести преимущества, которые могут побудить вас пересмотреть свое решение о преобразовании микросервисов и избежать соответствующей операционной сложности.
