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

проектировании API и его изменении.

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

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

Основные идеи: локализовать точки интеграции и контролировать все потоки данных. Для этого надо использовать:

1. API Gateway[64] для локализации синхронных взаимодействий и мониторинг/логирование трафика между микросервисами. В идеале, надо иметь визуализацию трассировки любого запроса.

2. Service Discovery[65] для отслеживания работоспособности экземпляров микросервиса и перенаправления трафика на «живые» экземпляры.

3. Запретить прямые вызовы между микросервисами.

Чтобы избежать типовых проблем и упростить разработку, рекомендую взять на вооружение подходы по повышению отказоустойчивости (материалы для специалистов в IT):

1. Circuit Breaker[66].

2. Tolerant Reader[67].

3. Embracing Failure[68].

4. The Timeout AntiPattern[69].

5. Graceful Degradation[70].

Этап № 3. Микросервисы

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

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

Становится заметна главная черта хорошей архитектуры: сложность системы растёт линейно с увеличением количества микросервисов.

Рис. 41. Разрыв прямых связей между микросервисами

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

1. Pattern: Microservice Architecture[71].

2. Microsoft Dev School – Микросервисы, чистый PaaS и конкурс «Мисс Россия»[72].

3. Microservices, a definition of this new architectural term[73].

Проблемы

На этом этапе сложные технические задачи решены, поэтому начинаются проблемы на уровне бизнес-задач:

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

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

3. Сборку новых продуктов из существующих кубиков хочется совместить с продуктовой разработкой, чтобы Владелец продукта[74] сам ориентировался в том, какие ресурсы ему доступны .

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

Многие компании не идут дальше, потому что на текущем этапе бизнес-задачи уже могут решаться достаточно быстро и эффективно. Тем, кто решает двигаться дальше:

1. Изучите концепцию Citizen Integrator[75]. Для наглядного примера заведите себе пару процессов в Zapier или подобном сервисе.

2. Опишите микросервисы в виде блоков, решающих бизнес-задачу (рис. 42), и сделайте из них конструктор. Это можно сделать: 1) на готовых инструментах, 2) обернуть BPM-движки типа Camunda, 3) написать всё самим с нуля. Все три подхода жизнеспособны. Выбор подхода зависит от стратегии вашей компании и наличии у вас ИТ-архитекторов и хороших программистов. В итоге вы будете мыслить на уровне бизнес-сервисов.

Рис. 42. Объединение микросервисов и сервисы для бизнеса

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

1. The Microservices Workflow Automation Cheat Sheet[76].

2. Clouds, iPaaS, Citizen Integrator and Why India’s Outsourcing Is Losing Money[77].

Этап № 4. Оркестратор бизнес-сервисов

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

Оркестратор бизнес-сервисов обычно является визуальной платформой, где соединяются сервисы, выставляются триггеры и условия ветвления, контролируются все потоки данных: реализована трассировка запросов, логирование событий, автомасштабирование по условиям. Сам оркестратор ничего не знает о специфике бизнес-процессов, которые на нём крутятся (рис. 43).

Рис. 43. Оркестрация бизнес-сервисов

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

Рис. 44. Сборка продуктов из «кубиков»

Проблемы

1. Создание, внедрение и развитие оркестратора бизнес-процессов является дорогим удовольствием.

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

3. Чем больше систем создаётся на оркестраторе, тем больше бизнес зависит от этого решения. Всё начинает напоминать проблемы монолита.

Естественное развитие

Эти четыре этапа показывают, как мне кажется, естественный ход вещей:

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

2. При первой попытке разделить монолит многие команды оказываются не готовы к возрастающей сложности. Монолит делится на много микросервисов, но из-за большого количество взаимосвязей получается тот же монолит, только с новыми проблемами: простейшие задачи типа трейсинга запроса или мониторинга инфраструктуры становятся вызовом для команды разработки.

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

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

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

Глава 2. Бизнес-гибкость через микросервисы

Почему микросервисы помогут вам ускорить поставку бизнес-ценности

История появления микросервисов

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

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