скачать книгу бесплатно
Необходимо учитывать, что при слабой связности компонентов (микросервисов) продуктовых областей между собой их также можно реализовывать распределенной командой. Но данный вариант является на сегодняшний день не слишком реалистичным ввиду сложностей координации продуктовой команды.
Рассмотрев развитие архитектуры в современных условиях, требующих предоставления возможности разработки программного обеспечения распределенными командами, перейдем к рассмотрению второй смысловой плоскости распределенности как одной из ключевых тенденций развития архитектуры – требования к распределенному выполнению создаваемых ИТ-решений.
Как мы уже говорили выше, проводя обзор ключевых тенденций развития архитектуры, требования к распределенному функционированию современных ИТ-решений стали новыми с точки зрения рынка ИТ, что привело к существенному пересмотру подходов к проектированию. Рука об руку с распределенностью пришли требования по приоритетному развитию дистанционных каналов обслуживания клиентов и партнеров. Все эти требования возникли вследствие стремительного роста стартапов и формирования на их основе технологических гигантов. В фильме Дэвида Финчера «Социальная сеть» (The Social Network, 2010) режиссер вкладывает в уста героя Джастина Тимберлейка (играет Шона Паркера) пророческие слова: «Мы жили в деревнях, а потом в городах, а теперь будем жить в Интернете!» Безусловно, и сегодня можно встретить на просторах Интернета ехидные комментарии в адрес данных слов, утверждающие, что жизнь не ушла не только из городов, но и из деревень. Но речь шла не о физическом месте проживания (мы уже видели по ходу настоящего раздела, насколько иллюзорным может становиться его значимость в современном мире), а о mindset. Специально расшифровывая подобные аспекты, персонаж Рашиды Джонс (играет адвоката Мэрилин Делпи) замечает относительно проникновения современных технологий в нашу жизнь: «Босния… У них нет дорог, но есть Facebook». Разумеется, речь идет не о физическом исчезновении деревень и городов, отсутствии необходимости в инфраструктуре обеспечения жизнедеятельности, а о коренном изменении мышления, формировании совершенно нового mindset. Технологические решения проникают в нашу жизнь, причем доступны они в любой точке земного шара. Современный человек не мыслит свою жизнь без Интернета, без сервисов, предоставляемых самыми различными компаниями как в региональном, так и в глобальном масштабе. Но любая медаль имеет обратную сторону – технологические решения, прорвавшись в жизнь человека, связали себя новыми требованиями – они должны быть доступны из любой географической точки и предоставлять неизменно высокое качество сервиса. В противном случае они станут неконкурентоспособными. Подобные требования являются исключительно важными с точки зрения архитектуры.
Ранее по ходу настоящего раздела мы рассмотрели современные организационные, технические и архитектурные практики, применяющиеся для разработки современных ИТ-решений распределенными командами. Как же будут функционировать создаваемые таким образом решения? Например, решение, иллюстративно представленное на Рисунках 13 и 14, должно быть доступно всем юридическим лицам России (кроме, разумеется, тех, на кого наложены предписанные законом ограничения). Рассмотрим функционирование распределенного решения, принимая во внимание те архитектурные принципы, которые уже были предложены для его организации: микросервисная архитектура, продуктовый подход, практики EDA.
Описанные ранее ключевые принципы микросервисной архитектуры имеют ряд следствий практического применения. Одним их них является то, что абсолютное большинство микросервисов проектируется и разрабатывается в формате stateless компонентов, то есть они не сохраняют свое состояние между вызовами – для выполнения данной функции служит внешнее по отношению к микросервису хранилище информации. Таким хранилищем может быть база данных, in-memory data grid (IMDG), платформа событийного обмена (и такие варианты реализации используются, например, The New York Times). С точки зрения самих микросервисов отсутствие сохранения состояния между вызовами позволяет создавать количество экземпляров микросервиса, необходимое для корректной обработки запросов, учитывая возможный рост числа последних. Отсутствие необходимости репликации сессий на уровне экземпляров микросервисов позволяет минимизировать внимание, уделяемое данному вопросу, и масштабировать микросервисы в допустимых инфраструктурой пределах. При этом крайне важным оказывается наличие располагаемых инфраструктурных мощностей для развертывания соответствующих программных компонентов в таких местах, где сетевая латентность не станет преградой для высокого качества сервиса. Например, финансовая организация, предоставляющая услуги в части продуктов по всей территории России, может быть заинтересована в нескольких центрах обработки данных, которые будут географически распределены.
Если функционирование прикладной логики, реализующей соответствующие продукты, достаточно хорошо ложится на распределенную модель, то возникают вопросы, на какой же уровень переносится растущая сложность исполнения ИТ-решений. Выше уже отмечалось, что для сохранения состояния решений используются внешние по отношению к микросервисам хранилища данных. И вопрос функционирования данных хранилищ в распределенной конфигурации становится исключительно важным. Традиционные решения с централизованными базами данных оказываются слабо применимыми в современных условиях – несколько мощных вычислительных узлов попросту не доставят данные микросервисам за приемлемые временные промежутки. В случае, если речь идет о доступности ИТ-решений по дистанционным каналам, когда время отклика и предоставления услуг (по крайней мере, их части) должно составлять несколько секунд, таковые задержки недопустимы. Создание территориально распределенных кластеров традиционных решений по хранению данных также оказывается проблематичным – используемые такими решениями методы синхронизации и поддержания целостности данных зачастую оказываются несостоятельными в условиях значительной сетевой латентности. Соответственно, мир оказывается заинтересован в принципиально новых хранилищах информации. И такие хранилища, опять же, пришли из стартапов. Например, одно из самых популярных на сегодняшний день решений по построению распределенных баз данных Apache Cassandra было создано в Meta Platforms (ранее Facebook). Аналогично распределенные конфигурации предлагают IMDG решения, такие как Apache Ignite. Отметим, что приводимые примеры современных технологий являются решениями с открытым исходным кодом.
Современные распределенные платформы предполагают совершенно новый уровень производительности и надежности в распределенной среде. Безусловно, модель работы с информацией в данном случае отличается от моделей, принятых в соответствии с традиционными подходами предыдущих архитектурных поколений, синхронизация больших объемов данных в распределенной среде вносит свои ограничения. И здесь на помощь командам разработки приходит большое количество потенциальных топологий рассматриваемых решений. Благодаря глобальной цепочке разделения труда, актуальной для создания подобных технологических решений, становится возможным создать набор потенциальных конфигураций, количественный и качественный состав которого значительно превосходит то, что предлагалось традиционным «закрытым» программным обеспечением. Подобные технологические решения предоставляют новые возможности для проектирования программного обеспечения, но и предъявляют дополнительные требования к работе архитектора. Если ранее он мог ссылаться на известные топологии и лучшие практики (которых было достаточно ограниченное число) «закрытого» программного обеспечения, использовавшегося организацией, то теперь он должен ориентироваться в широком спектре современного открытого программного обеспечения, его возможных топологиях, а также лучших практиках применения последних. Создаваемые информационные системы должны подвергаться тщательному архитектурному анализу на предмет вариантов развертывания, доступа клиентов, сценариев использования, интеграционной составляющей. Результатом анализа станет выбор необходимого программного обеспечения для реализации, рекомендации по его использованию, направляющие по развитию для команд разработки.
Все сказанное касается не только хранения информации и использования распределенных СУБД. Платформа событийного обмена также должна обеспечивать возможность исполнения решений в распределенной конфигурации. Из современных решений первым кандидатом на подобную роль может считаться Apache Kafka, уже использующаяся в таких компаниях, как вышеупомянутый The New York Times, Linkedin, Uber, «Сбербанк России» и многих других. Решение изначально поддерживает распределенную топологию развертывания и предоставляет широкий спектр возможностей для «тонкой» настройки.
Поскольку микросервисы не сохраняют состояние между вызовами, они нуждаются в предварительной выборке данных для отображения пользователю необходимой ему информации, а также реакции на его запросы. Для обеспечения эффективного доступа к часто используемым данным обычно применяются технологии кэширования (IMDG), также поддерживающие распределенные топологии. Примерами могут служить упомянутый выше Apache Ignite или Infinispan.
Пример решения, представленный на Рисунках 13 и 14, не является исчерпывающим с точки зрения распределенного функционирования современных ИТ-решений. Например, для финансовой сферы актуально выполнение групповых операций, предполагающих проведение однотипных действий над огромными объемами данных. Примером такой операции может служить массовое начисление процентов по счетам. Современные технологии позволяют осуществлять выполнение подобных ресурсоемких операций в оперативной памяти на распределенных узлах обработки, при этом мощность каждого отдельного узла соответствует скорее продвинутому персональному компьютеру, а не гигантскому серверу, что представляет собой разительное отличие от традиционных подходов, стяжавших недобрую славу в профессиональном сообществе и по праву получивших наименование жаргонного типа «залить железом». Аналогичным образом данные могут храниться не только в распределенных базах данных, но и в распределенной файловой системе, что принципиально снижает стоимость хранения (крайне актуально при современном росте объемов хранимых данных).
Таким образом, мы видим, что на всех уровнях создания и развития программного обеспечения востребована концепция распределенного исполнения, под нее создается соответствующий технологический базис. Задача архитектора при этом – не только распределить границы областей разработки решения по продуктовым областям, но и предложить технологические платформы и их топологии, позволяющие максимально эффективно выполнять задачи ИТ-решения по мере реализации последнего. Одновременно учитывается возможность непредсказуемой нагрузки на решение посредством дистанционных каналов. Например, если финансовая организация предложит исключительно выгодный по меркам рынка продукт, каналом предложения которого и соответствующего приема заявок станет сайт компании (без требования регистрации, что выгодно отличает его перед, например, системами дистанционного банковского обслуживания, ДБО), то нагрузка на ИТ-ландшафт может резко возрасти за краткий промежуток времени. Создаваемая архитектура должна позволить решению сохранить корректность функционирования и качество предоставления услуг и при столь агрессивно возрастающей нагрузке.
Основываясь на вышеизложенном, можем отметить, что роль архитектора в рамках ответа на те вызовы, которые ставит перед архитектурой фактор распределенности, существенно изменилась. На сегодня необходимо обладать знанием широкого спектра программного обеспечения, рассчитанного на функционирование в распределенной гетерогенной среде, знать его основные топологии и сценарии их применения, погружаться в предметную область для качественной грануляции проектируемых информационных систем, позволяющей вести разработку силами распределенных команд. На сегодня архитектор – это не выделенный специалист, привлекаемый командами «по случаю», но лидер технологических изменений. Он задает ключевые направляющие создания, развития решений, а также их технологического наполнения.
Архитектура и бизнес-процессы
Важнейшей тенденцией развития архитектуры является ее способность обеспечить качественное и эффективное исполнение бизнес-процессов, актуальных для организации, автоматизация деятельности которой рассматривается.
Любая современная организация обеспечивает структуризацию своей деятельности на основании ее упорядочивания с последующим описанием и формирования бизнес-процессов, которые в удобочитаемом формате (например, в BPMN-нотации) обеспечивают наглядное и доступное описание выполняемых действий. При этом к бизнес-процессам обычно предъявляются требования по обеспечению возможности моделирования, определения этапа исполнения, а также задания количественных метрик (KPI), позволяющих проводить их анализ и оптимизацию.
Для обеспечения автоматизированного исполнения бизнес-процессов используются движки исполнения бизнес-процессов (BPM-движки), обеспечивающие следующие основные возможности:
• Моделирование процесса при помощи наглядных визуальных средств (полнота поддержки BPMN-нотации может варьироваться в зависимости от конкретного моделирующего средства).
• Задание связей, как выполняемых в рамках процесса действий, так и интеграций с внешними системами, которые ответственны как за непосредственное выполнение операций, так и могут предоставлять интерфейсы автоматизированных рабочих мест для выполнения задач пользователями (внутренними и внешними).
• Автоматизированное выполнение шагов процесса в соответствии с заданным алгоритмом.
• Назначение ролей, ответственных за этапы выполнения процесса.
• Определение метрик и KPI процесса и его составляющих, а также ролей, задействованных в процессе.
При этом в течение долгого времени BPM-движки представляли собой сложные платформы автоматизации монолитного характера, которые осуществляли управление всеми бизнес-процессами организации. Указанный подход содержал серьезные риски, которые затрудняли эффективное внедрение средств автоматизации управления бизнес-процессами:
• Невысокая производительность средств автоматизации процессов стала одним из основных препятствий их внедрения. Зачастую многие организации осуществляли автоматизацию бизнес-процессов, жестко программируя их выполнение, при этом основной мотивацией такого выбора была именно забота о производительности.
• Монолитный характер BPM-движков приводил к сложной технологической связи бизнес-процессов (зачастую не столь тесно связанных между собой на уровне потребностей бизнеса) и невозможности их независимого масштабирования, что увеличивало затраты на инфраструктурное обеспечение приемлемого качества функционирования.
• Поддержание большого количества бизнес-процессов на уровне монолитного BPM-движка явным образом ставило перед организациями проблему создания общей модели данных, применимой для всех бизнес-процессов, либо обеспечения согласования различных используемых моделей данных – оба приведенных варианта направления работы влекли серьезные трудозатраты, за которыми логичным образом следовали и финансовые затраты.
Пример монолитного BPM-движка в ИТ-ландшафте схематично показан на Рисунке 15.
Рисунок 15. Пример монолитного BPM-движка в ИТ-ландшафте
На Рисунке 15 представлен BPM-движок, обеспечивающий выполнение бизнес-процессов ИТ-ландшафта, выстроенного в монолитной или SOA архитектуре. Некоторое число информационных систем (N – на рисунке) обеспечивают автоматизацию бизнес-действий, организуемых в некоторое число бизнес-процессов (K – на рисунке). Соответственно, монолитный движок должен поддерживать значительное число (в современной организации оба параметра могут варьироваться от сотен до тысяч) сочетаний бизнес-действий и систем. При этом независимое масштабирование невозможно.
Подобная топология развертывания решения по автоматизации бизнес-процессов затрудняла разработку ИТ-решений распределенными командами разработки, а распределенное исполнение (в современном понимании, подробно рассмотренном выше) информационных систем и ИТ-ландшафта в целом исключалось. Долгое время лидирующая роль на рынке BPM-движков принадлежала «закрытым» решениям, поставляемым крупными компаниями – разработчиками программного обеспечения, таким как IBM и Oracle.
Ранее рассматривались такие архитектурные практики трансформации как переход к микросервисной архитектуре, использование продуктового подхода и EDA. Нетрудно заметить, что при реализации новых технологических решений в парадигме микросервисной архитектуры монолитный BPM-движок становится узким местом в части скорости разработки: каждая информационная система в микросервисной парадигме разрабатывается несколькими продуктовыми командами, что в свою очередь предъявляет серьезные требования к развитию BPM-движка. Нельзя не отметить, что резко возросшие требования к производительности создаваемых решений предъявляют качественно иные требования к масштабированию всех компонентов ИТ-ландшафта, в том числе BPM-движку.
В рамках перехода к микросервисной архитектуре и продуктовому подходу, подробно рассмотренным в предыдущих разделах, меняется и концепция управления бизнес-процессами. Продуктовый подход предполагает, что силами команды гибкой разработки (возможно, нескольких команд при сложном многофункциональном продукте) будет осуществляться полный цикл работ по автоматизации продукта, предоставляющего самодостаточную ценность для клиентов и/или партнеров. Такой продукт подразумевает в том числе автоматизацию сложных бизнес-процессов, связанных с обработкой его жизненного цикла. При этом отдельные элементы таких бизнес-процессов могут быть действиями, реализуемыми на уровне распределенных компонентов (микросервисов), но их объединение является действием иного порядка, которое имеет смысл назвать управлением бизнес-процессом с продуктовой спецификой или продуктовым бизнес-процессом, в соответствии с современными архитектурными практиками также являющимся микросервисом. Иллюстративно данная концепция представлена на Рисунке 16.
Для иллюстрации взят пример продукта – электронной банковской гарантии – и один бизнес-процесс – заведение банковской гарантии. В соответствии с ранее представленными подходами к проектированию, управление бизнес-процессом реализовано в формате микросервиса. Отметим, что бизнес-процесс как управляющий компонент (в отличие от компонентов, непосредственно выполняющих бизнес-действия), вынесен за пределы продуктовой области и взаимодействует с продуктовыми микросервисами посредством платформы событийного обмена. Структура автоматизации продуктовых бизнес-процессов выглядит следующим образом:
Рисунок 16. BPM-движок в микросервисной архитектуре
• Каждый набор микросервисов, обеспечивающих автоматизацию жизненного цикла продукта, должен иметь возможность осуществлять управление бизнес-процессами (содержать один или более BPM-движков), ассоциированными с данным продуктом или группой продуктов.
• Применяемые технологии BPM-движков должны обеспечивать простоту и удобство использования в микросервисной топологии развертывания.
• BPM-движок должен либо обладать высокой производительностью, либо предоставлять широкие возможности масштабирования (рекомендуемым является сочетание возможностей).
• Хранение описаний (схем) бизнес-процессов, исполняемых продуктовым BPM-движком, должно быть локальным по отношению к автоматизации бизнес-функционала. Схемы не должны запрашиваться из удаленного реестра, что позволяет избежать в том числе проблем сетевой латентности.
Важным требованием к системе управления бизнес-процессами в современной архитектуре с учетом применения продуктового подхода и практик EDA является также следующее: низкий порог входа в том числе с точки зрения компетенций. Из представленных на сегодняшний день на рынке решений, удовлетворяющих всем перечисленных требованиям, можно отметить BPM Camunda, являющееся программным обеспечением с открытым исходным кодом.
Как отмечалось выше, реальные бизнес-процессы, выполняющиеся в современных организациях, обладают сложной структурой, включающей сотни и тысячи шагов и бизнес-действий. В случае выполнения подобных процессов одним микросервисом последний нарушит одно из ключевых требований, предъявляемых в парадигме микросервисной архитектуры, заключающееся в простоте каждого микросервиса. Рассмотрим, каким образом возможно решить таковую проблему.
Решение проблемы переноса управления сложными бизнес-процессами в парадигму микросервисной архитектуры состоит из нескольких этапов. Первым из них является технический рефакторинг бизнес-процессов.
Важным свойством, облегчающим применение BPM-движков, является наличие развитых средств моделирования процессов с использованием общепринятых нотаций (стандартом де-факто является BPMN). Использование подобных средств качественно улучшает возможности взаимодействия владельца продукта, оперирующего бизнес-понятиями, и команды гибкой разработки, состоящей из технических специалистов.
Вместе с тем, подобный подход несет в себе некоторые риски:
• Отражение в бизнес-процессе исключительно логики бизнес-уровня – необходимой, но не достаточной части автоматизации, предполагающей исполнение и технических задач. В данном случае расширение техническими задачами специализированных бизнес-действий (компонентов бизнес-процесса) может оказаться некорректным с точки зрения потенциального масштабирования создаваемого ИТ-решения. Более корректным стоит признать включение в состав бизнес-процесса в том формате, в котором уже производится автоматизация, отдельных этапов технического характера. Это и становится первой стадией технического рефакторинга бизнес-процесса.
• Отрисовка инструментальными средствами бизнес-процесса целиком без предварительного мелкого гранулирования. В рассматриваемом варианте существует серьезный риск создания монолитного артефакта – бизнес-процесса, скорость разработки которого и внесения изменений будет существенно ниже, нежели на уровне продуктовой логики. С учетом того, что изменения в продуктовых бизнес-процессах могут инициироваться на регулярной основе (в зависимости от потребностей рынка, участником которого является автоматизируемая организация), озвученный риск следует признать исключительно важным. Соответственно, приступая к автоматизации бизнес-процесса, следует всегда рассматривать возможность его декомпозиции на составляющие, что становится вторым этапом технического рефакторинга бизнес-процесса.
Таким образом, при осуществлении технического рефакторинга выполняются следующие основные задачи:
• Формирование технической карты бизнес-процесса с учетом детализированного бэклога продукта, содержащего как пользовательские истории, так и технические задачи, выполнение которых необходимо в рамках реализации продуктовой логики.
• Анализ компонентов бизнес-процесса на предмет повторяемости и независимости с выделением в отдельные исполняемые единицы.
• Анализ контекста процесса на предмет разрыва и возможности разделения на составляющие по границам контекста.
Понятие контекста бизнес-процесса было сформулировано еще в период внедрения BPM-систем в классической архитектуре монолитного типа. Данный термин актуален и в настоящее время. Под контекстом бизнес-процесса понимается совокупность информации, характеризующая выполняемые в ходе бизнес-процесса действия, получаемые и обрабатываемые данные, а также служебная информация, необходимая для обработки бизнес-данных.
На основании понятия бизнес-процесса вводится понятие бизнес-транзакции как набора связанных действий, выполняемых в рамках бизнес-процесса. При этом выделяются локальные транзакции, которые могут выполняться в рамках связанного неделимого набора действий (в качестве примера такой локальной транзакции можно рассматривать процесс скоринга кредитной заявки), могущего исполниться лишь целиком и подлежащего отмене в случае возникновения ошибок, и глобальные, состоящие из последовательности локальных. Глобальная транзакция не может быть отменена, поскольку зафиксированы результаты исполнения локальных транзакций, входящих в ее состав. В случае возникновения ошибок по ходу выполнения глобальной транзакции отмена результатов локальных транзакций, завершившихся успешно, возможна посредством выполнения компенсационных действий (алгоритмов), которые, в свою очередь, также могут быть сложными бизнес-процессами. Примером невозможности отмены является ошибочное уведомление клиента о тех или иных событиях по ходу исполнения бизнес-процесса. В данном случае компенсационным алгоритмом может быть отправка корректирующих уведомлений.
Каждая локальная транзакция характеризуется своим транзакционным контекстом, определяющим ее состояние. В общем случае контексты локальных транзакций недоступны друг другу. Контекст бизнес-процесса, представляющего собой глобальную транзакцию, определяется набором контекстов локальных транзакций, входящих в его состав. При этом локальные транзакционные контексты являются непрозрачными друг для друга и могут управляться независимо посредством BPM-движка (в парадигме микросервисной архитектуры – различных движков).
Задачи, требующие неавтоматизированного вмешательства пользователя или вызова внешней (по отношению к управляющему бизнес-процессом BPM-движку) системы, могут выполняться непредсказуемо долго, в результате чего их реализация должна осуществляться в рамках отдельных локальных транзакций с собственным контекстом. Совокупность локальных транзакций и их контекстов составляет общую глобальную транзакцию бизнес-процесса и ее контекст соответственно. Аналогично в отдельном контексте должен выполняться вложенный бизнес-процесс.
Важным аспектом технического рефакторинга и управления контекстом бизнес-процесса является то, что реальное значение для бизнеса имеет глобальная транзакция и ее контекст, соответственно, при обеспечении рефакторинга необходимо поддерживать целостность глобального контекста бизнес-процесса. Этой цели служат такие шаблоны управления исполнением бизнес-процессом, как оркестровка и хореография.
В ходе внедрения систем управления бизнес-процессами (еще в парадигме монолитных решений и SOA) был определен термин оркестровка. Оркестровка – централизованное управление бизнес-процессом, осуществляемое из одной точки. К преимуществам оркестровки относят удобство осуществления мониторинга бизнес-процесса, вся информация о состоянии и исполнении которого содержится в одном компоненте ИТ-ландшафта организации. К недостаткам – сложность и перегруженность этой одной точки управления исполнением (выше уже говорилось о том, что исполняющий таким образом реальный бизнес-процесс микросервис теряет соответствие требованию простоты реализации).
В противоположность оркестровке вводится шаблон хореографии. Хореография предполагает отсутствие единой точки управления исполнением бизнес-процесса – компоненты, которые должны действовать согласованно, публикуют события в соответствии с практиками EDA, которые прослушиваются другими компонентами, составляющими в совокупности бизнес-процесс. К достоинствам данного шаблона проектирования можно отнести практически неограниченные возможности масштабирования под высокой нагрузкой, соответствующей современным дистанционным каналам. К недостаткам – сложные алгоритмы организации сквозного мониторинга бизнес-процессов.
Как видно из приведенного описания, каждый способ организации управления бизнес-процессами имеет свои преимущества и недостатки, поэтому в современных архитектурных практиках указанные шаблоны скомбинированы следующим образом:
• Для каждого бизнес-процесса, подлежащего автоматизации, проводится технический рефакторинг в соответствии с концепцией, изложенной выше: составляется техническая карта, включающая как бизнес-действия, так и необходимые технические задачи, формируется контекст процесса, выделяются составляющие его локальные контексты.
• Бизнес-процесс, выполняющийся в рамках одного локального контекста, управляется в соответствии с шаблоном проектирования оркестровки, что обеспечивает его максимальную прозрачность с точки зрения мониторинга.
• Оркестровка локального бизнес-процесса осуществляется с использованием BPM-движка в соответствии с лучшими практиками переноса последнего в парадигму микросервисной архитектуры, представленными ранее по ходу настоящего раздела. Примером такого движка может являться BPM Camunda.
• Поскольку оркестровка локального процесса осуществляется посредством выделенного микросервиса, масштабирование производится независимо от других сервисов (как содержащих логику управления локальными бизнес-процессами, так и тех, в которых она отсутствует – микросервисах, осуществляющих исполнение продуктовой логики).
• Управление бизнес-процессами, выполняющимися в рамках отдельных локальных транзакций, но составляющих общий глобальный бизнес-процесс, осуществляется на основе шаблона проектирования хореографии.
• Применение шаблона проектирования хореографии для управления глобальным процессом предполагает использование лучших современных практик EDA (наличия платформы событийного обмена, носящей технический характер), а также специальной организации мониторинга его состояния и исполнения экземпляров бизнес-процессов. В качестве платформы событийного обмена может использоваться, например, Apache Kafka.
• Каждый экземпляр процесса, выполняющегося в рамках локального контекста, может масштабироваться независимо от экземпляров процессов, исполняющихся в рамках иных локальных контекстов.
Отметим, что представленный подход позволяет обеспечивать в автоматизации управления бизнес-процессами следование принципам распределенности. Локальные бизнес-процессы могут исполняться независимо друг от друга, распределяясь, например, по территориальному признаку. Каждый экземпляр локального бизнес-процесса при этом масштабируется независимо не только от других бизнес-процессов, но и от экземпляров локальных бизнес-процессов, составляющих вместе с ним общий бизнес-процесс с глобальным контекстом. Например, в общем бизнес-процессе может быть нагруженный этап, содержащий большое количество неавтоматизированных пользовательских задач. В результате объекты, идущие по бизнес-процессу, например, заявки на электронные банковские гарантии, скапливаются именно на данном этапе. Распределенная структура бизнес-процесса позволяет масштабировать процессный микросервис (workflow микросервис), отвечающий именно за этот этап, не осуществляя аналогичного масштабирования с другими составляющими бизнес-процесса. Подобный подход приводит к существенной экономии инфраструктурных мощностей. Необходимо также отметить, что workflow микросервис, выполняющий обобщенные задачи, может быть задействованным в качестве локального бизнес-процесса в нескольких глобальных процессах, например, в процессах прохождения кредитных заявок и заявок на электронную банковскую гарантию.
Пример распределенного бизнес-процесса, выполняющегося совместно с продуктовыми микросервисами, представлен на Рисунке 17.
На Рисунке 17 представлена совместная работа микросервисов, автоматизирующих прикладную логику продукта электронных банковских гарантий, и процессных микросервисов, отвечающих за функционирование бизнес-процесса. Проиллюстрирован один бизнес-процесс – заведение электронной банковской гарантии (рассматривается поступление заявки на гарантию с внешней площадки). По итогам технического рефакторинга общий бизнес-процесс, выполняющийся в рамках глобального контекста обработки заявки, разбит на 5 локальных бизнес-процессов, выполняющихся в рамках собственных локальных контекстов. Каждый локальный процесс реализуется в рамках микросервисной парадигмы и осуществляет оркестровку действий, входящих в него и реализуемых прикладными микросервисами, пользовательскими неавтоматизированными задачами или внешними по отношению к рассматриваемому ИТ-решению системами. В рамках глобального процесса для синхронизации исполнения локальных элементов используется шаблон проектирования хореография в соответствии с принципами EDA, основой реализации выступает платформа событийного обмена.
