Привет, Хабр! Меня зовут Кирилл Рождественский, работаю тим-лидом в компании 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-инженеров, чтобы это поддерживать. Клиент хочет скачать один пакет, установить его на свой сервер, и чтобы все заработало.

На этом закончим первую из нашей серии статей о переходе с монолита на микросервисы. Делитесь своими мыслями по теме и задавайте вопросы  в комментариях.

В следующей части разберем 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 

• LinkedIn: https://www.linkedin.com/company/tcp-soft

* Продукт компании Meta, признанной в РФ экстремистской организацией