Часто хочется перейти от монолита к микросервисам, но многие сдаются. Как обеспечить это преобразование, не увязнув в трудностях?
Несколько команд начали разбивать свой монолит на микросервисы, поскольку спагетти-код перестал поддерживаться.
Другие команды предпочитают начинать новый проект, поскольку это лучший способ не попасть в ловушку монолита.
В обоих случаях они страдают и не видят преимуществ микросервисной архитектуры.
Мы узнаем, почему.
Микросервисы усложняют работу на всех уровнях
Он вводит промежуточную сериализацию/десериализацию и дублирование данных, которые немного утомительны в обслуживании.
Для интеграции необходимо выбрать политику обратной совместимости и тестирования между каждой парой взаимодействующих модулей.
Службы должны развертываться независимо друг от друга, с собственными циклами управления версиями и выпусками.
Для отладки необходимо иметь возможность отслеживать трассировку нескольких служб.
Но они не самые плохие.
Разделить приложение сложно
Хороший сплит — это больше, чем просто технический сплит. Это зависит от продукта, поэтому волшебной формулы не существует.
В большинстве случаев границы размыты. Микросервисы не все одинакового размера. Будут и маленькие, и большие.
Когда разрыв слишком мал, мы платим высокую цену на всех уровнях, и вернуться назад очень сложно. Мы ищем актуальный и долгосрочный раскол.
Давайте рассмотрим наиболее распространенные препятствия при переходе на сервис-ориентированную архитектуру.
Ловушки, которых следует избегать
- Разделить на мелкие краевые части. Это не очень увлекательно: скорее болезненно, чем полезно
- Сделайте синхронизированные выпуски/развертывания для всех сервисов. Это означает, что циклы разработки всегда будут коррелированы и, следовательно, медленны.
- Сверхпроектная инфраструктура. Чрезмерная сложность замедляет работу команд.
- Начните без опыта по этому вопросу. Решение будет сложнее.
Вам не нужны микросервисы
Как мы видели, это не «бесплатно». Для настройки и обслуживания системы вам потребуются знания и люди.
Это масштабное решение для крупных продуктов и крупных организаций.
К счастью, это не единственный вариант. Предпочтительно выбрать альтернативу, подходящую для вашего продукта и вашей организации.
Альтернатива: макросервис
Макросервис с буквой «а» имеет те же свойства, что и микросервис, но крупнее.
Преимущество макросервиса заключается в минимизации некоторых сложностей с микросервисами, таких как зависимости, разделенные трассировки стека и т. д.
Это позволяет постепенно переходить к сервис-ориентированной архитектуре. Размер и количество макросервисов будет зависеть от ваших потребностей и штатного расписания.
Отлично, но как перейти от монолита к макросервисам?
Бинарное деление
Это простая итеративная и поэтапная стратегия. Это выглядит так:
- Разделите код на две части примерно одинакового размера. При необходимости продублируйте код.
- Создайте отдельный контейнер для каждой части, чтобы получить два макросервиса.
- Настройте инфраструктуру и организацию
- После стабилизации повторите с одним из макросервисов.
Цель состоит в том, чтобы развернуть новую архитектуру в рабочей среде для проверки подразделения. Это позволяет настроить решение (маршрутизацию, зависимости, тесты, журналы, развертывание, управление версиями и т. д.) перед созданием нового подразделения.
Еда на вынос
Крайне важно осуществить постепенную трансформацию путем согласования технологической и организационной сторон.
Не стоит недооценивать сложность сервис-ориентированной архитектуры. Лучший способ добиться успеха — интегрировать людей, которые разбираются в предмете.
