12 методов улучшения монолита перед переходом на микросервисы
3 ноября 2022 г.12 способов подготовиться к микросервисам
Ваша команда решила, что пришло время избавиться от этого старого неуклюжего монолита (наконец-то!). Вы хорошо поработали с ним, но монолит стал настолько большим, что вы тратите больше усилий на его обслуживание, чем на добавление функций. Пришло время попробовать другой подход.
Кажется, микросервисы очень популярны в наши дни, поэтому, может быть, имеет смысл копнуть немного глубже и посмотреть, из-за чего весь этот шум?
Совет: пока не списывайте со счетов монолит. При некоторой подготовке он может сослужить вам хорошую службу на протяжении всего перехода. Вот 12 советов, как сделать переход на микросервисы максимально плавным.
Убедитесь, что вы знаете, во что ввязываетесь
Переписывание никогда не бывает легким, но, переходя от монолита к микросервисам, вы меняете больше, чем способ написания кода. вы меняете операционную модель компании. Вам придется не только освоить новый, более сложный технологический стек, но и руководству также потребуется скорректировать культуру работы и реорганизовать людей в более мелкие, многофункциональные команды.
Как лучше всего реорганизовать команды и компанию — темы, достойные отдельного поста. В этой статье я хочу сосредоточиться на технических аспектах миграции.
Во-первых, важно как можно больше изучить компромиссы, связанные с внедрением микросервисов, еще до начала работы. Вы хотите быть абсолютно уверены, что микросервисы (а не другие альтернативные решения, такие как модульные монолиты) являются правильным решением для вас.
Начните с изучения как можно большего об архитектуре микросервисов и просмотрите несколько примеров проектов, чтобы получить представление о том, как это работает. Вот несколько примеров:
* Создание микросервиса Go с помощью Gin и CI/CD * CI/CD для микросервисов в DigitalOcean Kubernetes * CI/CD для Spring Boot Microservice * https://semaphoreci.com/blog/spring-boot-microservices-cicd)
Составьте план
Чтобы снести монолит, требуется много подготовки, поскольку старая система должна оставаться работоспособной во время перехода.
Шаги миграции можно отслеживать с помощью тикетов и работать над ними в каждом спринте, как и над любой другой задачей. Это не только помогает набрать обороты (чтобы когда-нибудь осуществить миграцию), но и дает владельцам бизнеса прозрачность относительно того, как команда планирует реализовать такое крупное изменение.
Во время планирования вы должны:
* Распутать зависимости внутри монолита. * Определите необходимые микросервисы. * Разработка моделей данных для микросервисов. * Разработайте метод переноса и синхронизации данных между монолитными и микросервисными базами данных. * Разрабатывайте API и планируйте обратную совместимость. * Зафиксируйте базовую производительность монолита. * Установите цели доступности и производительности новой системы.
Если вы не переходите от довольно простого монолита, вам потребуются передовые методы, такие как проектирование, управляемое доменом (Domain-Driven Design, DDD). Если вы никогда не использовали его раньше, я написал краткое введение в применение DDD к микросервисам, которое стоит прочитать.
Поместить все в монорепозиторий
По мере того, как вы разбиваете монолит, большая часть кода будет перемещена из него в новые микросервисы. монохранилище поможет вам отслеживать такие изменения. Кроме того, наличие всего в одном месте поможет вам быстрее восстанавливаться после сбоев.
По всей вероятности, ваш монолит уже содержится в одном репозитории. Итак, нужно просто создать новые папки для микросервисов.
Использовать общий конвейер непрерывной интеграции
Во время разработки вы будете не только постоянно выпускать новые микросервисы, но и повторно развертывать монолит. Чем быстрее и безболезненнее будет этот процесс, тем быстрее вы сможете прогрессировать. Настройте непрерывную интеграцию и доставку (CI/CD) для автоматического тестирования и развертывания кода.
Если вы используете монорепозиторий для разработки, вам нужно помнить о нескольких вещах:
* Обеспечьте высокую скорость конвейеров, включив выполнение на основе изменений или используя инструмент сборки с поддержкой монорепозиториев, например < a href="https://semaphoreci.com/blog/bazel-build-tutorial-examples">Bazel или Брюки. Это повысит эффективность вашего конвейера за счет внесения изменений только в обновленный код. * Настройте несколько рекламных акций, по одной для каждого микросервиса и еще одну для монолита. Используйте эти акции для непрерывного развертывания.
Настройте отчеты о тестировании, чтобы быстро выявлять и устранять сбои.
Убедитесь, что у вас достаточно тестов
Рефакторинг приносит гораздо больше удовольствия и эффективности, когда мы уверены, что в коде нет регрессий. Автоматизированные тесты обеспечивают постоянную отправку монолитных обновлений.
Отличным местом для начала является пирамида тестирования. Вам понадобится большое количество модульных тестов, несколько интеграционные тесты и несколько приемочных тестов. р>
Старайтесь запускать тесты на своем локальном компьютере так же часто, как и в своем конвейере непрерывной интеграции.
Установите шлюз API или обратный HTTP-прокси
По мере развертывания микрослужб необходимо разделять входящий трафик. Перенесенные функции предоставляются новыми службами, а еще не готовые функции предоставляются монолитом.
Есть несколько способов маршрутизации запросов, в зависимости от их характера:
* Шлюз API позволяет перенаправлять вызовы API на основе таких условий, как аутентифицированные пользователи, файлы cookie, флаги функций или шаблоны URI. * Обратный HTTP-прокси делает то же самое, но для HTTP-запросов. В большинстве случаев монолит реализует пользовательский интерфейс, поэтому большая часть трафика будет направляться туда, по крайней мере, поначалу.
Используйте шлюзы API и обратные прокси-серверы HTTP для маршрутизации запросов к соответствующей конечной точке. Вы можете переключаться между монолитом и микросервисами на очень мелком уровне.
После завершения миграции шлюзы и прокси-серверы останутся — они являются стандартным компонентом любого микросервисного приложения, поскольку они обеспечивают переадресацию и балансировку нагрузки. Они также могут функционировать как автоматические выключатели в случае сбоя службы.
Монолит в коробке
Хорошо, это применимо только в том случае, если вы планируете использовать контейнеры или Kubernetes для микросервисов. В этом случае контейнеризация может помочь вам гомогенизировать вашу инфраструктуру. Шаблон монолита в коробке состоит из запуска монолита внутри контейнера, такого как Docker.
Если вы никогда раньше не работали с контейнерами, это хорошая возможность познакомиться с этой технологией. Таким образом, вы будете на шаг ближе к изучению Kubernetes в будущем. Нужно многому научиться, поэтому планируйте крутую кривую обучения:
- Узнайте больше о Docker и контейнерах.
- Запустите монолит в контейнере.
- Разрабатывайте и запускайте микросервисы в контейнере.
- После завершения миграции и освоения контейнеров узнайте больше о Kubernetes.
- По ходу работы вы можете масштабировать микросервисы и постепенно перенаправлять на них трафик.
Контейнеризация вашего монолита — это способ стандартизации развертывания и отличный первый шаг в изучении Kubernetes.
Подготовка к изменениям
Чтобы привыкнуть к микросервисам, требуется время, поэтому лучше начать с малого и привыкнуть к новой парадигме. Оставьте достаточно времени, чтобы каждый мог настроиться на правильный лад, повысить квалификацию и учиться на ошибках, не ограничивая себя дедлайнами.
Во время этих первых предварительных шагов вы многое узнаете о распределенных вычислениях. Вам придется иметь дело с облачным соглашением об уровне обслуживания, настраивать соглашения об уровне обслуживания для собственных служб, реализовывать мониторинг и оповещения, определять каналы для взаимодействия между командами и выбирать стратегию развертывания.
Выберите что-нибудь легкое для начала, например пограничные службы, которые мало пересекаются с остальной частью монолита. Например, в качестве первого шага вы можете создать микрослужбу аутентификации и маршрутизировать запросы на вход.
Использовать флаги функций
Флаги функций – это программный метод изменения функциональности системы без ее повторного развертывания. Вы можете использовать флаги функций, чтобы включать и выключать части монолита по мере их переноса, экспериментировать с альтернативными конфигурациями или проводить A/B-тестирование.
Типичный рабочий процесс для переноса с включенным флагом функции:
- Определите часть функциональных возможностей монолита для переноса в микрослужбу.
- Оберните функциональность флагом функции. Повторно разверните монолит.
- Создайте и разверните микросервис.
- Протестируйте микросервис.
- После этого отключите функцию на монолите, выключив ее.
- Повторяйте, пока миграция не будет завершена.
Поскольку флаги функций позволяют нам развертывать неактивный код в рабочей среде и переключать его в любое время, мы можем отделить выпуски функций от фактического развертывания. Это дает разработчикам огромную гибкость и контроль.
Модулизируйте монолит
Если ваш монолит представляет собой клубок кода, вы вполне можете получить клубок *распределенного* кода после завершения миграции. Подобно уборке дома перед капитальным ремонтом, сборка монолита на модули – это необходимый подготовительный этап.
Модульный монолит — это шаблон разработки программного обеспечения, состоящий из вертикально расположенных модулей, независимых и взаимозаменяемых. Противоположностью модульного монолита является классический N-уровневый или многоуровневый монолит.
Многоуровневые монолиты трудно распутать: в коде слишком много зависимостей (иногда круговых), что затрудняет внесение изменений.
Модульный монолит — следующая лучшая вещь после микросервисов и ступенька к ним. Правило состоит в том, что модули могут обмениваться данными только через общедоступные API, и по умолчанию все приватно. В результате код становится менее переплетенным, взаимосвязи легко определяются, а зависимости становятся четкими.
Два шаблона могут помочь в реорганизации монолита: фига-душитель и уровень защиты от коррупции.
Узор инжира-душителя
В шаблоне фигурка-душитель мы рефакторим монолит от края к центру. Мы грызем края, постепенно переписывая отдельные функции, пока монолит не будет полностью переделан.
Вызовы между модулями направляются через "фасад душителя", который эмулирует и интерпретирует ввод и вывод устаревшего кода. Постепенно создаются модули, постепенно заменяющие старый монолит.
Монолит состоит из модулей по частям. В конце концов, старый монолит исчезает и заменяется новым.
Шаблон уровня защиты от коррупции
Вы обнаружите, что в некоторых случаях изменения в одном модуле распространяются на другие по мере рефакторинга монолита. Чтобы бороться с этим, вы можете создать слой перевода между быстро меняющимися модулями.
Этот уровень защиты от повреждений предотвращает влияние изменений в одном модуле на остальные.
Уровень защиты от повреждения предотвращает распространение изменений путем перевода вызовов между модулями и монолитом.
Развязка данных
Сверхмощные микросервисы дают вам возможность развертывать любой микросервис в любое время практически без координации с другими микросервисами. Вот почему следует любой ценой избегать связывания данных, поскольку оно создает зависимости между службами. Каждая микрослужба должна иметь частную и независимую базу данных.
Может быть шокирующим осознание того, что вам нужно денормализировать общую базу данных монолита на (часто избыточные) меньшие базы данных. Но локальность данных — это то, что в конечном итоге позволит микросервисам работать автономно.
После разделения вам нужно будет установить механизмы для синхронизации старых и новых данных во время перехода. Например, вы можете настроить службу зеркального отображения данных или изменить код, чтобы транзакции записывались в оба набора баз данных.
Добавить наблюдаемость
Новая система должна быть быстрее, производительнее и масштабируемее, чем старая. Иначе зачем возиться с микросервисами?
Вам нужен базовый уровень для сравнения старого с новым. Перед началом миграции убедитесь, что у вас есть хорошие метрики и журналы. Может быть хорошей идеей установить какую-нибудь централизованную службу регистрации и мониторинга, так как это ключевой компонент для наблюдаемость любого микросервисного приложения.
Заключение
Путь к микросервисам никогда не бывает легким. Но я надеюсь, что с помощью этих советов вы сэкономите время и нервы.
Не забывайте выполнять итерации небольшими шагами, использовать CI/CD, чтобы гарантировать, что монолит тестируется на регрессии, и хранить все в одном репозитории, чтобы вы всегда могли перемотать назад, если что-то пойдет не так.
Удачного кодирования и спасибо за чтение!
Также опубликовано здесь
Оригинал