Андрей Трушкин – Архитектура цифрового мира (страница 6)

Первым этапом нового революционного перехода стала концепция микросервисной архитектуры, в соответствии с которой приложения представлялись в виде набора минимально зависимых (в идеальной ситуации независимых) модулей (микросервисов), каждый из которых представлял собой полноценную единицу развертывания с самостоятельным жизненным циклом. При этом взаимодействие микросервисов предполагалось осуществлять исключительно посредством API, что исключало необходимость владения информацией об особенностях исполнения контрагентов. Данная концепция соответствовала практикам гибкой разработки и DevOps. Пример предлагавшейся концепции представлен на Рисунке 8.

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

Показанные на Рисунке 8 микросервисы и межсервисные взаимодействия представлены в качестве примера.

При проектировании решений на основе микросервисной архитектуры учитывались следующие характеристики и качества микросервисов:

• Трудоемкость. Разработку микросервиса должна вести одна команда, сформированная в соответствии с гибкими практиками разработки.

• Независимость. Локальные задачи решаются средствами микросервиса. Команда, реализующая микросервис, не должна ожидать исполнения подзадач (в составе данного микросервиса) другой командой. Возникновение ситуаций ожидания являлось признаком ошибок проектирования.

• Бизнес-ориентированность. Микросервисы должны решать конкретные прикладные задачи заказчиков.

• Простота интеграции. Для реализации взаимодействия микросервисов не требуется использования отдельных программных компонентов (по примеру рассмотренного выше ESB решения).

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

• Децентрализация данных. Отдельные микросервисы работают с независимыми источниками данных в рамках собственных моделей данных. Модели данных разных микросервисов развиваются независимо друг от друга.

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

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

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

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

• Упрощение замены блоков функционала. В случае, когда бизнес-функции реализуются минимально зависимыми компонентами – микросервисами – их замена оказывает минимальное влияние на другие компоненты системы.

• Удобство и дешевизна масштабирования. При увеличении нагрузки на систему отсутствует необходимость в масштабировании всего программного комплекса (в отличие от эпох монолитных приложений и SOA), а возможно масштабировать только те микросервисы, на которые оказывается дополнительная нагрузка, что снижает технологические и финансовые риски.

• Соответствие создаваемой архитектуры организационной структуре предприятия. Возможным становится создание микросервисов, реализующих автоматизацию функционала, напрямую соответствующего должностным обязанностям подразделений предприятия. Таким образом уже на уровне концепции для микросервисной архитектуры реализуется закон Конвея.

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

• Удобство развертывания. При обновлении отдельного микросервиса отсутствует необходимость обеспечивать развертывание всей информационной системы.

Указанный перечь характеристик и потенциальных преимуществ перехода к микросервисной архитектуре обеспечили повышенный интерес к данной архитектурной концепции в 2010-е годы. Ряд технологических гигантов уже в начале десятилетия начали перевод своих технологических платформ на микросервисную архитектуру. В качестве примера можно привести Uber.

Следует отметить, что компании, осуществлявшие переход к микросервисной архитектуре, столкнулись с рядом сложностей. Компания Uber посредством своих Интернет-ресурсов (, 23.07.2020) достаточно подробно рассматривала проблемы, с которыми ей пришлось столкнуться. По ходу решения выявленных проблем ИТ-ландшафт компании неоднократно претерпевал серьезные изменения, иногда включавшие в себя полный пересмотр достаточно крупных элементов данного ландшафта, а также деталей проектирования. На ряде популярных Интернет-ресурсов профессиональной направленности размещались статьи многих компаний, содержавшие выражения яркого эмоционального характера по адресу микросервисной архитектуры. Основной претензией, высказанной в отношении архитектурной концепции, были резко возросшая сложность ИТ-решений, запутанность интеграций, трудности в организации управления бизнес-процессами, сложности с сопровождением созданного решения, невозможность выработать эффективную релизную модель. Анализируя проблемы, с которыми столкнулись участники рынка при переходе к микросервисной архитектуре, можно отметить следующие основные примеры неудачной реализации новых архитектурных концепций, которые и привели к упомянутым проблемам: https://eng.uber.com/microservice-architecture/

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

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

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

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

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

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