Привет, Хабр! Меня зовут Кирилл Рождественский, работаю тим-лидом в компании TCP-Soft, но поскольку инициатива написать настоящий материал была совместной с коллегами из Mango Office, с которыми мы делаем общий продукт, они предоставили мне аккаунт для публикации в их блоге.
В серии из трех статей я расскажу о миграции с монолитной на микросервисную архитектуру. Разберемся, когда и кому это действительно нужно, рассмотрим 7 паттернов этого процесса и его самый больной вопрос: «Как быть с данными?». В первой части, то есть под катом, вспомним ключевые определения и выясним, когда микросервисы использовать стоит, а когда нет. Она ориентирована на людей, не слишком хорошо знакомых с микросервисами, более опытным специалистам рекомендуем эту часть пропустить.
Итак, что такое монолит и микросервис?
Монолит — это одно приложение, которое инкапсулирует в себе всю бизнес-логику. Монолит может одновременно заниматься и обработкой контактных данных, и менеджментом платежных транзакций. Часто одним из характерных признаков монолита является прямая работа с базой данных.
В противовес монолиту микросервисная архитектура подразумевает разделение по множеству признаков: бизнес-логике, владению данными, зонам ответственности и т.д.
Важно отметить, что простое разбиение монолита на несколько процессов не делает автоматически архитектуру микросервисной. Если несколько процессов продолжают работать с общей базой, или же падение одного из процессов ведет к неработоспособности другого — это не микросервис, а распределенный монолит.
5 характерных признаков микросервиса
1. Ориентированность на бизнес-домен
Что такое «бизнес-домен»? Как следует из названия, это понятие, которое хорошо знакомо бизнесу и которым он может оперировать. Бизнес привык использовать некие абстрактные сущности, понятные конечному заказчику. Клиент никогда не будет требовать «реализовать подключение к БД через DBA на Java». Зато вполне может попросить поддержку разделения контактов адресной книги на группы в разрезе организации. Мы являемся разработчиками сервисов для виртуальной телефонии, и в нашем случае примерами бизнес-сущностей являются «Адресная книга», «Перечень сотрудников», «СМС-рассылки» и т.д.
2. Независимость в плане владения кодом
Вся экспертиза по микросервису должна быть сконцентрирована в рамках одной команды. Например, если перестали создаваться контакты в адресной книге, все в компании должны знать, к какой команде идти и от кого требовать решение проблемы.
3. Независимость с точки зрения технологий
Мы можем экспериментировать и выбирать наиболее подходящие под каждую конкретную задачу стеки. Если критична производительность, уходим в C++. Необходимо быстро разворачивать rest-endpoint’ы, используем, например, Node.js. Так, у нас большинство микросервисов написаны на Node.js с использованием чистого JavaScript. Однако для критических сервисов (такими являются, например, точки подключения клиентских приложений) мы используем уже TypeScript, что значительно снижает количество ошибок, попадающих на бой, и ускоряет отладку.
4. Независимость по данным
В идеале у каждого микросервиса должна быть своя, абсолютно независимая база данных. Это даст сразу несколько существенных преимуществ:
Так как данными обладает только один микросервис, мы можем как угодно менять схему хранения, не рискуя сломать функционал, за который не отвечаем.
Мы можем не бояться, что кто-то нечаянно повредит наши данные.
Мы можем применять наиболее подходящие технологии для конкретных задач, например, ClickHouse для OLAP-решений, Elasticsearch для индексации, MongoDB для хранения содержимого веб-страниц.
5. Независимость развертывания
То, за что многие любят, ценят и пытаются внедрить микросервисы. Неправильно, если KPI-сервер не может деплоиться без перезапуска адресной книги. Ровно как и кажется странным ждать общего релиза всей инфраструктуры только для того, чтобы поменять формат отчета.
5 случаев, когда стоит задуматься о переходе на микросервисы
1. Необходимо повысить автономность групп
Любой монолит рано или поздно разрастается до больших размеров, а вместе с ним — команда. Когда мы имеем набор микросервисов, можем выделить узких специалистов на разные функции. Благодаря этому все вокруг понимают, куда идти, если сломается что-то определенное.
Отметим, что микросервисная архитектура связана с Agile. С чем сталкивались мы при миграции на гибкую методику разработки: люди делятся на команды лишь организационно, а работать при этом вынуждены с одной кодовой базой. Переход на микросервисы позволяет делиться на команды логически и каждой из них заниматься только одной конкретной задачей в своем направлении.
2. Необходимо сократить время доставки
Здесь логика связана с одной из характеристик микросервисов — независимостью развертывания. Чем более узкий функционал зашит в микросервис, чем больше он обособлен и чем меньше зависит от сторонних компонентов, тем проще его задеплоить.
3. Необходимо повысить отказоустойчивость
Зачастую проще отслеживать производительность и ошибки отдельных микросервисов, чем всего монолита. К тому же, в правильно реализованной микросервисной архитектуре отказ одного компонента не влияет на жизнь остальных. Например, если упадет микросервис, отвечающий за работу с сотрудниками, коммутатор должен продолжать работу, и звонки будут проходить.
4. Необходимо увеличить гибкость при масштабировании
Зачастую монолит можно масштабировать только вертикально. Однако любые ресурсы, будь то CPU или оперативная память, конечны. Микросервисы же в подавляющем большинстве легче спроектировать, исходя из горизонтального масштабирования.
Также немаловажную роль имеет локальность масштабирования. Если, например, у нас медленно выполняются запросы к адресной книге, мы можем увеличить мощности только одного микросервиса, а не всей инфраструктуры. Это удобнее и, что порой очень важно для бизнеса, намного дешевле.
5. Хочется опробовать новую технологию
Например, хотим «пощупать» новый фреймворк, который в 10 раз быстрее работает со строковыми данными. В монолите функционал новой технологии может занимать очень маленькую долю от общего. Пересобирать весь монолит ради эксперимента, который гипотетически даст перфоманс в 3% кода, невыгодно бизнесу и неоправданно для команды. С маленькими микросервисами пробовать новое проще и удобнее.
4 случая, когда на микросервисы переходить не стоит
Лет 5-7, а то и 10, назад на микросервисы пытались перейти все (примерно как сегодня на Scrum), лишь потому что это модно. Сегодня же очевидно: чтобы из одного большого проблемного монолита не получилось много проблемных микросервисов, не надо стараться перейти на микросервисы, если:
1. У вас и сейчас все работает
Если у вас приложение на стадии глубокой поддержки и сейчас развивается довольно неактивно или активно, но по уже проторенным дорожкам, и какого-то принципиально нового функционала не появляется, то объективных причин для перехода на микросервисы нет.
2. У вас стартап
Разработку проекта не стоит начинать с микросервисной архитектуры, так как она весьма сложна, требует дополнительных расходов и никак не способствуют быстрому выходу на рынок.
3. Нет ярко выраженной доменной модели
Если в монолите нет четко выраженной доменной модели, либо все связано со всем, и когда вынимается один кирпичик, вся башня разваливается, опять-таки лучше не торопиться. Начать лучше с рефакторинга существующего кода. И когда монолит будет «причесан», из него можно по частям выносить функционал в микросервисы.
4. Вы предоставляете коробочное решение
Если вы предоставляете коробочное решение, которое должно развертываться на стороне клиента, хорошим вариантом будет его реализация в виде монолита. Клиент скорее всего не захочет деплоить у себя монструозную инфраструктуру и нанимать штат DevOps-инженеров, чтобы это поддерживать. Клиент хочет скачать один пакет, установить его на свой сервер, и чтобы все заработало.
На этом закончим первую из нашей серии статей о переходе с монолита на микросервисы. Делитесь своими мыслями по теме и задавайте вопросы в комментариях. Мой ник, под которым я отвечаю в комментариях: @vi_ki_ng.
В следующей части разберем 7 миграционных паттернов: «удавка», «композиция UI», «разделение по абстракции», «шпион», «параллельное выполнение», «канареечный релиз», «декоратор».
Подписывайтесь на наши соцсети:
Аккаунты Mango Office
ВКонтакте: https://vk.com/mangotelecom
Телеграм: https://t.me/mango_office
Аккаунты TCP-Soft
Instagram*: https://www.instagram.com/tcp_soft
Facebook*: https://www.facebook.com/tcpsoftminsk
* Продукт компании Meta, признанной в РФ экстремистской организацией