Раздел 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, что добавляет сложности в