Читать книгу Архитектура цифрового мира - Андрей Николаевич Трушкин - Страница 4

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

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

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

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

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

Возьмем в качестве наглядного примера финансовую сферу. Основой финансовой сферы являлась (и является) учетная платформа (в России традиционное название – автоматизированная банковская система, АБС). Эта система (при исходном проектировании) выполняла следующие функции:

• Учет финансовых/хозяйственных операций;

• Ведение счетов;

• Ведение плана счетов;

• Бухгалтерский документооборот;

• Валютный учет;

• Многофилиальный учет;

• Налоговый учет;

• Формирование учетной документации для проведения проверок;

• Формирование оперативной и аналитической бухгалтерской отчетности (операционный день и т. п.).

По мере автоматизации производственных и бизнес-процессов финансовой организации в состав учетной платформы включались исходно несвойственные ей функции:

• Ведение данных клиентов;

• Управление бизнес-процессами;

• Автоматизированные рабочие места сотрудников, ведущих обслуживание клиентов;

• Продуктовые операции (не только учетного характера, но и, например, продуктовые конвейеры);

• И т. д.

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

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

Пример указанного функционала монолитной системы в формате учетной платформы приведен на Рисунке 6.

На Рисунке 6 представлено разделение учетной платформы на следующие составные блоки:

• Целевой функционал, который направлен на автоматизацию собственно учетной функции;

• Вмененный функционал, который не связан непосредственно с целями учета;

• Автоматизированные рабочие места, к которым можно отнести целевые (АРМ бухгалтерии) и вмененные (АРМ специалиста по обслуживанию клиентов).

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

Рисунок 6. Пример монолитной системы в формате учетной платформы

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

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

Революционным переходом можно было считать переход финансовых организаций того времени (речь идет о передовых организациях соответствующего сектора) к модели сервис-ориентированной архитектуры (service-oriented architecture, SOA), предполагавшей разнесение различных блоков функционала по отдельным автоматизированным системам, каждая из которых предоставляла доступный контрагентам функциональный набор в формате групп сервисов, при этом интеграционные взаимодействия между системами, как предполагалось, должны были осуществляться унифицированным образом. Пример организации SOA представлен на Рисунке 7.

Рисунок 7. Пример организации SOA

Рассмотрим структуру SOA, пример которой представлен на Рисунке 7, более подробно. При внедрении соответствующих архитектурных практик ИТ-ландшафт организации (в нашем примере финансовой) распределялся по функциональному назначению: выполнение учетных функций (учетная платформа), управление взаимодействием с клиентом (система Customer Relationship Management, CRM), системы дистанционного банковского обслуживания (ДБО), продуктовые конвейеры (на Рисунке 7 в качестве примера приведен кредитный конвейер).

Создатели архитектурных практик SOA стремились выставить акценты при разработке и развитии информационных систем в соответствии с функциональными границами областей, ими автоматизировавшимися. При этом унификация интеграционного взаимодействия осуществлялась посредством реализации шаблона проектирования «Корпоративная сервисная шина» (Enterprise Service Bus, ESB), подробное описание которого приведено в книге Gregor Hohpe, Bobby Woolf «Enterprise Integration Patterns» (2003, ISBN 978—0321200686). Для реализации указанного шаблона применялись, как правило, отдельные информационные системы (было выпущено немало как «закрытых» решений, таких как IBM WebSphere ESB, так и основанных на принципах открытого кода, как Apache ServiceMix). Ключевыми задачами, решавшимися при реализации шаблона ESB, были следующие:

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

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

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

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

Таким образом, решение, реализующее шаблон ESB, оказывалось сквозным в масштабах организации, что привело к дополнению его функционала задачами информационной безопасности, аудита, трассировки и т. д. Кроме того, для реализации непосредственных задач решение реализовывало ряд шаблонов проектирования, представленных как в вышеупомянутом труде («Enterprise Integration Patterns»), так и в одной из основополагающих работ в сфере ИТ: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides «Design Patterns: Elements of Reusable Object-Oriented Software» (1994, ISBN 0-201-63361-2). К числу подобных шаблонов можно отнести каноническую модель данных, адаптер и т. д.

Как уже отмечалось выше, переход к SOA стал революционным в плане развития архитектуры и внедрения ИТ в организациях. В результате разгрузки учетных платформ от несвойственного им функционала передовые в технологическом плане финансовые организации смогли приступить к активной автоматизации своих производственных и бизнес-процессов. Практики SOA стали основными, при этом к началу 2010-х годов ведущие финансовые организации в целом завершили перевод собственной автоматизации в данном ключе. Сформированный ИТ-ландшафт был, безусловно, намного сложнее, чем представленный на Рисунке 7 пример – в крупных финансовых организациях он включал в свой состав сотни и тысячи информационных систем. Можно отметить, что к этому периоду SOA из революционной практики стала эволюционной с ярко выраженной тенденцией к застою и деградации. В чем же выражалась соответствующая тенденция?

Представим себе ситуацию, что в финансовой организации 200 информационных систем, которые выстроены и взаимодействуют между собой в соответствии с принципами SOA. При этом каждая информационная система предоставляет 10 сервисов, посредством которых ее функционал доступен контрагентам. Как результат, на интеграционной шине представлено 2000 сервисов. Каждая из систем развивается независимо в соответствии с планами владельцев систем (предположим, что владельцами систем в организации являются бизнес-подразделения). Соответственно, команда специалистов, отвечающая за развитие ESB решения, должна поддерживать актуальность всех 2000 сервисов, добавлять новые, обеспечивать корректность функционирования всего комплекса. Не будем забывать, что нередким является случай, при котором потребителями одного сервиса являются несколько информационных систем. В таком случае при развитии соответствующего сервиса необходимо также поддерживать механизмы версионности, а также обеспечивать регрессионное тестирование. Емкость любой команды не является бесконечной величиной. Кроме того, важным является тот факт, что ESB не представляет собой конечной значимой бизнес-функциональности, то есть участие членов команды развития ESB решения в создании бизнес-ценности является опосредованным, что ограничивает возможности масштабирования соответствующей команды. Результатом, как правило, являлось то, что скорость внесения изменений на уровне ESB была существенно ниже, нежели в информационных системах, автоматизирующих прикладной функционал. Особенно заметной разница в скорости внесения изменений была при сравнении ESB с системами дистанционного банковского обслуживания (ДБО), где соответствующая скорость традиционно одна из самых высоких в автоматизации финансового сектора. Автор лично был свидетелем того, как уже выполненные доработки уровня ДБО ожидали необходимых интеграционных доработок год и более.

Шаблон ESB и следование ему было не единственной причиной потенциальной деградации. Заказчики и партнеры любой организации (финансовая не является исключением) заинтересованы в продуктах, которые она предоставляет. В случае финансовой организации это могут быть вклады, счета, кредиты, банковские гарантии и т. д. В случае следования методикам SOA предоставление продукта клиентам и партнерам предполагало реализацию соответствующего функционала в рамках нескольких информационных систем: канального представления, исполнения процессов, связанных с соответствующим продуктом, принятия решений в части исполняющихся процессов, постановки продукта на бухгалтерский учет и т. д. При этом нельзя забывать, что отдельные системы пусть и предоставляли свой функционал в виде набора сервисов, доступность которых контрагентам обеспечивало ESB решение, сами по себе оставались монолитными комплексами с длительными релизными циклами. Многие из этих систем требовали специфических компетенций для развития. При этом компетенции требовались не только технического, но и методологического характера. В результате выпуск продукта зависел от системы с максимально длительным релизным циклом. На фоне успехов стартапов, ряд которых к началу 2010-х годов уже стали технологическими гигантами, сложившаяся ситуация не могла устраивать представителей традиционных секторов экономики (пример, приведенный в настоящей книге для финансовой организации, является характерным для традиционных секторов экономики в целом). Тенденции, сформировавшиеся после экономического кризиса 2008-го года, также требовали повышения эффективности всех отраслей человеческой деятельности. Возникла необходимость в новом революционном переходе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Возможность самопотребления. Микросервисы могут сами реагировать на опубликованные ими события. Такая возможность должна обеспечиваться при реализации.

Пример решения, выстроенного в соответствии с концепциями микросервисной архитектуры, продуктового подхода и EDA, представлен на Рисунке 10.

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

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

Сочетание микросервисной архитектуры, продуктового подхода и EDA позволило многих компаниям провести кардинальную трансформацию своего ИТ-ландшафта, осуществив новый революционный переход, и значительно повысить качество предлагаемых услуг, обеспечить высокую скорость внесения изменений и вывода продуктов на рынок. При этом на новый качественный уровень вышли производительность и надежность их решений. Соответствующие архитектурные подходы используются в LinkedIn, Uber, Netflix, Monzo Bank и других технологических лидерах современности.

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

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

Многие компании, активно развивающиеся в различных направлениях человеческой деятельности, имеют давнюю по меркам ИТ историю, что непосредственно сказывается на уровне их автоматизации. В России крупнейшие корпорации осуществляют автоматизацию своей деятельности 25—30 лет, в США и Западной Европе этот процесс даже более длителен. По ходу развития возникает ситуация сосуществования ИТ-решений различных поколений: рядом сосуществуют монолитные решения, многие из которых разработаны с использованием устаревших технологических стеков, сервис-ориентированные решения, есть наработки с использованием микросервисной архитектуры. Нередко в профессиональном экспертном сообществе поднимается вопрос, зачастую инициируемый и заказчиками решений по автоматизации, который заключается в том, какой путь выбрать в части архитектурных преобразований: эволюционный или революционный. В случае перехода организации, обладающей большим объемом унаследованного (legacy) ИТ-ландшафта вопрос можно конкретизировать следующим образом: стоит ли дробить системы предыдущего поколения на микросервисы, либо стоит создавать новый ИТ-ландшафт фактически с нуля.

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

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

Таким образом, варианты революционного и эволюционного развития архитектуры можно уподобить Сцилле и Харибде из «Одиссеи»: проход рядом со скалой Сциллы грозил Одиссею и его спутникам гибелью части экипажа, Харибда же – общей гибелью всех мореходов. Именно поэтому главным аспектом архитектурного перехода, развития архитектуры являлся и является mindset, который должен быть направлен строго на революционное развитие.