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

качестве системы. Такой подход даёт всем участникам и системе шанс вовремя реагировать на изменения внешних условий, что крайне важно для IT, где вводные меняются очень часто.

Раздел II. IT-архитектура для достижения бизнес-целей

Система не будет антихрупкой без правильного подхода к IT-архитектуре. Моё глубокое убеждение состоит в том, что если среднему менеджеру дать крутых разработчиков, то есть хотя бы шанс создать классный IT-продукт. Но если крутому менеджеру дать посредственных разработчиков, IT-продукт будет средним, а самое главное, он будет очень хрупким. Любые внешние изменения будут рушить его до тех пор, пока не наступит коллапс, который приведёт к банкротству или необходимости переписать всё с нуля.

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

Глава 1. От микросервисного монолита к оркестратору

Эволюция IT-архитектуры в вашем продукте, особенности каждого этапа и необходимость перехода к следующему этапу

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

Когда компании решают разделить монолит на микросервисы, в большинстве случаев они последовательно проходят четыре этапа: монолит, микросервисный монолит, микросервисы, оркестратор бизнес-сервисов (рис. 37).

Рис. 37. Четыре стадии эволюции IT-архитектуры

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

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

Этап № 1. Монолит

Характеристики

Обычно монолитную архитектуру (рис. 38) можно описать так:

1. Единая точка разработки и релиза.

2. Единая база данных.

3. Единый цикл релиза для всех изменений.

4. В одной системе реализовано несколько бизнес-задач.

Рис. 38. Архитектура монолитного приложения

Материалы для погружения в контекст для специалистов в IT:

1. Pattern: Monolithic Architecture[54].

2. Бизнес-гибкость через микросервисную архитектуру (раздел II, глава 2).

3. Don’t start with a monolith[55].

Проблемы

Система единая, при этом решает много разных бизнес-задач. Разные бизнес-задачи развивают разные подразделения компании и двигаются с разной скоростью. Отсюда возникает проблема с взаимозависимыми релизами разных подразделений, когда все ждут самого медленного.

Сложно масштабировать бизнес-приложения, которые объединяет монолит. Это приводит к тому, что особенности каждого приложения не учитываются, а масштабирование неэффективно.

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

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

Последнее ведёт к тому, что бизнесу тяжело быстро собрать обратную связь от рынка.

Как перейти на следующий этап

В основе процесса выделения микросервисов лежит вынесение бизнес-задач из монолита в отдельные сервисы. Для этого нужно руководствоваться принципом единственности ответственности (SRP)[56], который можно выразить так: у микросервиса должна быть только одна причина для изменения. Этой причиной является изменение бизнес-логики той единственной задачи, за которую он отвечает.

В дополнение к SRP есть подход от любителей Domain-Driven Design: микросервис ограничивается одним или несколькими Bounded Context[57].

Постепенно у вас образуется набор из микросервисов, где каждый отвечает лишь за свою бизнес-задачу (рис. 39).

Рис. 39. Архитектура небольшой системы на микросервисах

Погружение в контекст для специалистов в IT:

1. Переход от монолитной архитектуры к распределённой [58].

2. How to break a Monolith into Microservices[59].

3. Command and Query Responsibility Segregation (CQRS) на практике[60].

4. Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы (раздел II, глава 5).

Чтобы не упустить ничего важного при создании микросервисной архитектуры, полезно периодически проверять себя по чек-листу The Microservice Architecture Assessment[61].

Этап № 2. Микросервисный монолит

Характеристики

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

Из четырёх способов интеграции[62] в микросервисной архитектуре обычно не используют обмен файлами и стараются не использовать shared database[63], зато активно работают с RPC и очередью сообщений.

Получается, все части монолита распались на микросервисы, а их обратно соединили паутиной синхронных и асинхронных вызовов (рис. 40).

Рис. 40. Множество микросервисов создают путаницу на архитектуре

По факту получился тот же монолит, но с бо́льшим количеством новых проблем.

Проблемы

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

Эта проблема усложняется, если у микросервиса много экземпляров. Тогда добавляется еще одна ситуация: запрос может прийти на зависший экземпляр микросервиса.

Архитектуру сложно понять, и чем больше сервисов вы добавляете, тем запутанней всё становится. Добавление новых сервисов нелинейно повышает сложность архитектуры.

Неизвестно, кто потребители вашего API, что добавляет сложности в