Андрей Трушкин - Архитектура цифрового мира

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

• Слишком мелкая грануляция микросервисов. При крайне мелком дроблении создаваемой ИТ-системы на микросервисы возможна исключительно сложная топология ее развертывания. В подобном случае количество потенциальных зависимостей (даже на уровне API) между отдельными микросервисами может значительно усложнить развитие ИТ-системы, что в свою очередь негативно повлияет на показатели времени вывода продуктов заказчика на рынок, надежность и производительность создаваемого решения. Следуя терминам профессионального сообщества, на смену «зоопарку систем» приходил «серпентарий микросервисов».

• Слишком крупная грануляция микросервисов. Является обратной стороной предыдущего пункта и близка к ситуации «распределенного монолита». В качестве микросервисов выделяется несколько подсистем, которые содержат большое количество логики и, по сути, представляют собой полноценные ИТ-системы предыдущего архитектурного поколения, а не микросервисы.

• Большое количество точечных интеграций. При прямом взаимодействии микросервисов между собой возможна избыточная сложность построения интеграционных взаимодействий. В качестве примера можно привести обновление web-интерфейса приложения, требующего для выдачи данных с последующим представлением пользователю последовательного вызова 4—5 микросервисов. Обеспечить высокую производительность (необходимую для использования в удаленных каналах обслуживания) подобным образом спроектированного решения зачастую проблематично.

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

Первым стал продуктовый подход к архитектуре, позволивший эффективнее обеспечить ее применение в сочетании с гибкими методологиями разработки. Традиционно при проектировании архитектурных решений внимание уделялось информационным системам, но в рамках микросервисной архитектуры данное понятие потеряло свое предыдущее значение. Манифест Agile провозгласил ориентацию ИТ на решение проблем заказчиков, максимально быстрое создание минимально жизнеспособных продуктов (MVP), декларируя открытость ИТ миру. Архитектура не могла оставаться в стороне от подобных веяний, а потому также сменила фокус внимания на продукты, имеющие конкретное значение для заказчиков. Концепция продуктов в архитектуре будет рассмотрена в соответствующей главе. Отметим, что в случае микросервисной архитектуры было внесено предложение, получившее популярность благодаря успешной практике применения, проектировать новые ИТ-решения таким образом, чтобы микросервисы (или их группы) отвечали бы за автоматизацию продукта, представляющего ценность для заказчика. Таким образом, соответствующий микросервис (или группа микросервисов) могли бы разрабатываться действительно небольшой командой, сохраняя характеристики трудоемкости, представленные выше. Микросервисы, отвечающие за продукт, могут поддерживать режим сильной связности между собой, при этом их взаимодействие с микросервисами, обеспечивающими автоматизацию логики других продуктов, ограничено и подчиняется принципам слабой связности. Продуктами для финансовой сферы, на примере которой происходит рассмотрение в настоящей главе, могут служить вклады, накопительные счета, кредиты, банковские гарантии. Пример продуктовой микросервисной архитектуры представлен на Рисунке 9.

На Рисунке 9 показаны два банковских продукта (кредит юридическому лицу и банковская гарантия), автоматизация которых осуществляется в соответствии с микросервисной архитектурой. Микросервисы, осуществляющие автоматизацию одного продукта, обладают множеством связей между собой, при этом количество связей между микросервисами, отвечающими за автоматизацию различных продуктов, минимизировано. Таким образом осуществляется движение к атомарности реализации соответствующей продуктовой функциональности.

Рисунок 9. Пример продуктовой микросервисной архитектуры

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

Нельзя не упомянуть, что само понятие событийно-ориентированной архитектуры (event-driven architecture, EDA) и ее концепции старше, нежели микросервисная архитектура. В свое время методики EDA конкурировали с SOA за право считаться наиболее распространенными и применимыми при автоматизации различных областей человеческой деятельности, но не приобрели аналогичной популярности. Более того, зачастую концепция интеграции компонентов информационных систем и систем между собой посредством событий (основополагающая методика EDA) подменялась на практике обычным асинхронным обменом, представлявшим собой отложенные команды на исполнение. Можно сказать, что массовый переход к микросервисной архитектуре стал «вторым дыханием» для EDA. Решение таких задач как слабая связность компонентов между собой, снижение числа прямых интеграций, масштабируемость и надежность программных комплексов, независимость исполнения бизнес-функций, не терявших своей актуальности при переходе к микросервисной архитектуре обеспечивалось практиками EDA. Рассмотрим более подробно применение EDA в микросервисной архитектуре.