Читать книгу - "Антихрупкость в IT - Александр Васильевич Бындю"

так изящно сделать бы не получилось.

Переход на микросервисы

Тема перехода на микросервисную архитектуру стала одной из самых горячих на конференциях по архитектуре ПО. Бизнес почувствовал, что такая архитектура даёт преимущество.

Заказчики и разработчики захотели раздробить монолитные приложения на множество маленьких сервисов, чтобы увеличить скорость доставки релизов до пользователей, разделить ответственность команд, уменьшить взаимозависимость бизнес-функций приложения и использовать горизонтальное масштабирование вместо вертикального.

В следующей главе я подробно расскажу, на что надо обратить внимание, когда вы захотите перейти на микросервисную архитектуру.

Глава 3. Скрытые расходы при переходе на микросервисы

Успешность перехода на микросервисы зависит от понимания факторов, влияющих на стоимость этого перехода

В идеальном мире можно просто взять исходный код монолита, разделить его между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не бывает. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?

Я опишу факторы, которые затягивают процесс перехода на микросервисы и делают его намного более дорогим, чем ожидалось вначале. Вы получите чек-лист для оценки этих факторов и будете более реалистичны при расчёте бюджета перехода.

1. Изменение подхода к работе с мастер-данными

Обычно у монолита есть одна или две большие базы данных, содержащие в себе разношёрстные мастер-данные. В самом монолите написан код, который управляет этими мастер-данными. Например, если «зелёная» часть базы данных – это адресный справочник, то «зелёный» код монолита управляет адресами. Получается, в базе данных монолита множество мастер-данных, а в коде монолита много мастер-систем (рис. 46).

Рис. 46. Связь приложения и базы данных в монолите

В микросервисах управление мастер-данным происходит иначе: баз данных много, перемешивать мастер-данные между микросервисами нельзя, а управлять мастер-данными может только один микросервис. Например, «зелёный» микросервис теперь получил свою базу данных с адресами и только он может вносить изменения в эти мастер-данные. Другие микросервисы могут читать данные с адресами, но только через «зелёный» микросервис (рис. 47).

Рис. 47. Каждый микросервис работает со своим хранилищем данных

Чёткое разграничение мастер-данных и мастер-систем по микросервисам нужно закладывать в оценку перехода. Занимает такая работа довольно много времени, которое уходит на следующее:

1. анализ схемы данных монолита,

2. анализ потоков обработки данных,

3. анализ использования данных сторонними системами,

4. бизнес-цели компании по работе с данными,

5. «нарезка» данных по новым базам,

6. миграция данных в новые базы микросервисов,

7. тестирование миграции.

Четыре основные стратегии работы с мастер-данными описаны в статье «Управления мастер-данными в микросервисной архитектуре»[80]. Желательно изучить эту тему до проектирования новой архитектуры.

Как и предыдущие факторы, переработку мастер-данных нужно оценивать и учитывать в бюджете перехода на микросервисы ещё до старта перехода.

2. Невозможность повторного использования исходного кода монолита

При беглом изучении кода монолита может показаться, что код аккуратно разделён по бизнес-контекстам[81] и в нём не нарушается принцип единственности ответственности. Если это так, значит, можно взять код монолита, распределить этот код по микросервисам, соединить микросервисы между собой, и получится та же система, но на микросервисной архитектуре (рис. 48).

Рис. 48. Идеальное разделение кода монолита на микросервисы

Практика показывает, что границы ответственности так или иначе растекаются внутри монолита. Из-за этого не получается использовать «копипаст» из монолита для заполнения микросервиса кодом. Весь код и тесты придётся написать с нуля для правильного разделения ответственностей по микросервисам (рис. 49).

Рис. 49. Реальная ситуация с выделением кода из монолита в микросервисы

Если случилось чудо и код монолита окажется идеально написан (чего никогда не происходит), то всё равно этот код придётся дописывать и переписывать под требования микросервисной архитектуры и под изменения в инфраструктуре (см. п. 4).

Не поддавайтесь на оптимизм Владельца Продукта и разработчиков монолита. Закладывайте столько времени своих разработчиков и тестировщиков, как если бы вы писали систему с нуля, а не просто переносили готовый код из одного места в другое. Кроме этого, до начала работ желательно договориться с командой, писавшей монолит, чтобы они выделили время на ваши вопросы по коду.

3. Проектирование системы заново

Разработчики так или иначе перепишут код монолита, но нужен кто-то, кто правильно разделит монолит на микросервисы, исходя из бизнес-требований. При проектировании микросервисной архитектуры нужно учесть текущее состояние бизнеса и будущие цели. Вам придётся заново сделать анализ потребностей бизнеса для правильной «нарезки» (рис. 50).

Рис. 50. Необходимость работы по перепроектированию системы

Запланируйте время IT-архитектора, бизнес-аналитиков и стейкхолдеров на анализ бизнес-требований. Кроме этого, запланируйте время на проектирование API будущей системы.

4. Создание нового подхода к управлению инфраструктурой

Микросервисы предъявляют новые требования к инфраструктуре. Не получится взять инфраструктуру монолита и на ней развернуть микросервисы: нужно учесть множество особенностей и применить специальные инструменты, чтобы не попасть в ситуацию, когда вместо монолита вы создали микросервисный монолит (рис. 40).

Что нужно учесть в оценке:

1. Создание инфраструктуры для управления API: анализ вызовов, система прав, публикация API и т. д. Для примера рекомендую посмотреть функциональность Apigee или подобных сервисов.

2. Переход DevOps-инженеров на работу только в концепции Infrastructure as Code (IaC) и контейнеризацию.

3. Реализовать тотальное логирование и мониторинг микросервисной архитектуры.

5. Измерение и проверка SLA каждого микросервиса

Обычно внутри монолита не замеряются SLA вызова функций. Мало кто отслеживает скорость ответа метода в коде или скорость работы хранимой процедуры в базе данных. При разделении монолита на микросервисы метод, который раньше вызывался из кода, становится вызовом API. Приходится гарантировать другим микросервисам конкретный SLA, чтобы вся конструкция работала предсказуемо.

Для любителей SRE[82] уточню, что было бы правильнее использовать термин SLO, потому что SLA = SLO + санкции за нарушение договорённостей.

Другими словами, ранее неявные SLA становятся явными и требуют проработки (рис. 51).

Рис. 51. Выделение SLA из монолита в микросервисы

Работа по определению SLA каждого микросервиса, описанию SLA, тестированию и постоянному мониторингу стоит денег, она не случится сама собой. Это довольно сложный процесс и его надо закладывать в