Перспектива
IT‑системы взаимодействуют и, следственно, интегрируются по тем же причинам, что и люди:
Когда наша работа требует информация от других людей.
Когда нам нужно, чтобы кто‑то что‑то для нас сделал.
Когда мы хотим пообщаться с кем‑то.
Соответствующими примерами из области IT могли бы послужить вызов API, операция и пинг/проверка состояния, спускаясь от наиболее распространенного до наименее распространенного типа взаимодействия. Благодаря ИИ в обозримом будущем может появиться и настоящее общение между IT‑системами.
Архитектура предприятия рассматривает взаимодействие между технологическими системами и людьми, участвующими в бизнес‑процессах. В качестве последних могут выступать клиенты, сотрудники и партнеры. Не все можно автоматизировать. Люди могут быть как в конце, так и в середине этого уравнения, и мы должны сделать их в равной степени частью его решения.
Интеграция систем обходится дорого и часто становится причиной сбоев. Как и в случае с людьми, следующие принципы делают взаимодействие между системами быстрым, эффективным и емким:
Специализация обязанностей (целостность / cohesion)
Отсутствие жесткой необходимости знать то, как что‑то устроено или предоставляет информацию (слабая связанность / loose coupling)
Общность языка (стандартизированные протоколы)
Подход к пониманию интеграции
Интеграция — это не просто HTTP, REST, старый добрый FTP или SQLNet. Это интересная и сложная область архитектуры, представляющая из себя целую дисциплину. Более того, не существует какого‑либо единственно правильного угла, под которым можно рассматривать ее. Я смотрю на нее с шести точек зрения (перспектив), которые позволяют мне формировать обоснованные архитектурные требования к интеграции, постановки задач и решения.
Эти точки зрения на интеграцию, от самого широкого охвата к более детальному приближению, следующие:
Рамки интеграции предприятия → Иерархия паттернов интеграции предприятия → Паттерны интеграции приложений → Горизонтальная интеграция слоев системы → Stateless против stateful интеграции → Интеграция безопасности
(Мы будем использовать релевантную с точки зрения архитектуры терминологию из предметно‑ориентированного проектирования (DDD, Domain Driven Design), особенно специфические для DDD термины для слоев — UI, приложение, домен и инфраструктура. Другие термины DDD выделены курсивом. Если вы не ориентируетесь в этой терминологии, то я рекомендую вам почитать мои статьи о DDD, часть I и II).
Как только вы научитесь рассматривать интеграцию в рамках приведенных ниже перспектив, вы сможете определять и решать проблемы интеграции целостно, эффективно и результативно.
Перспектива 1: Рамки интеграции предприятия
Полезно начать с представления о том, где происходят взаимодействия, поскольку это влияет на их характер и решения.
Внутридоменные
Интеграции в рамках бизнес‑домена являются наиболее распространенными. Они соединяют родственные системы, имеющие схожую архитектуру и модели проектирования (предполагая DDD). Это позволяет упростить карты контекстов между ограниченными контекстами и обеспечить более прямую интеграцию с меньшим количеством проблем, связанных с мощностью и масштабированием: например, интеграция между системой управления запасами и системой закупок.
Междоменные
Интеграций между бизнес‑доменами меньше, но проблем больше. Единый язык, скорее всего, будет разный в каждом домене, а полезная информация и объекты‑ответы часто нуждаются в преобразовании при взаимодействии. Инфраструктура также может быть разделена (в разной степени), что приводит к необходимости реализации ряда функций (см. Перспективу 2) для успешной интеграции, например, интеграции между системой отслеживания заказов в домене продаж и системой управления взаимодействиями с клиентами в домене обслуживания клиентов.
Между предприятиями
Интеграция между предприятиями‑партнерами в сценариях B2B и B2B2C растет в геометрической прогрессии благодаря современным веб‑ и цифровым сервисам. К счастью, стандарты интеграции сервисов и облачные сервисы не отстают от развивающихся веб‑, мобильных и цифровых архитектур, удовлетворяя потребности в надежных, быстро масштабируемых, безопасных и гибких интегрированных сервисах, охватывающих от двух до нескольких десятков компаний в таких экосистемах, как онлайн‑продажи, логистика, путешествия, автомобилестроение, производство, авиаперелеты, банковские и финансовые услуги.
Схема ниже хорошо демонстрирует эту перспективу:
Рекомендации
В рамках создания архитектур интеграции рассматривайте каждый тип интеграции отдельно с учетом его характеристик и пяти перспектив, приведенных ниже.
Перспектива 2: Иерархия паттернов интеграции предприятия
Иерархия бизнес-функций
BPM (Business Process Management) — управление бизнес‑процессами координирует людей, системы, информацию и средства для получения бизнес‑результатов в доменах и поддоменах предприятия. Примерами могут служить проектирование, производство, маркетинг, привлечение клиентов, продажи и т. д. Архитектура бизнес‑процессов автоматизирует динамическую интеграцию бизнес‑процессов в максимально возможной степени, чтобы обеспечить четко определенные, повторяемые, эффективные и надежные результаты.
Рабочий процесс (workflow) — это определенная последовательность задач, исполняемых людьми и системами, работающими вместе для выполнения бизнес‑задачи. Его можно рассматривать как подмножество бизнес‑процесса. Примером может служить процесс утверждения кредита. Архитектура рабочих процессов интегрирует людей и IT‑системы для инициирования, маршрутизации, аналитической поддержки принятия решений, физического труда, автоматизированных задач, координации и мониторинга рабочих процессов.
Интеграция систем — в хорошо спроектированном IT‑ландшафте функциональность разделена на целостные системы, отражающие возможности (capabilities) бизнес‑домена и поддоменов. Эти системы работают вместе, чтобы обеспечить полезные результаты для рабочих процессов и бизнес‑процессов. Интеграция систем автоматизирует их динамическое взаимодействие. (Подробнее о типах систем, которые необходимо интегрировать, читайте в этой статье → Практическая абстракция функциональных IT‑систем).
Интеграция компонентов — все IT‑системы внутренне разделены на целостные и слабо связанные компоненты и подкомпоненты. Они интегрируются посредством стандартных паттернов (см. Перспективу 4) для реализации внешне полезных функций системы.
На изображении ниже показана эта схема:
Иерархия технических функций
Интеграция стоит дорого и должна быть как можно более простой. Насколько сложной и проблемной она будет, зависит от степени зрелости IT‑систем (они же приложения). Когда клиентские и серверные системы/сервисы взаимодействуют друг с другом в рамках бизнес‑процесса, могут потребоваться некоторые (или все) из следующих функций:
Повторная попытка — сервер не отвечает с первой попытки.
Передача сообщений — с сервером нельзя связаться напрямую.
Управление нагрузкой (постановка в очередь, балансировка, пул соединений) — сервер может отвечать на ограниченное количество запросов в определенный момент времени.
Публикация и подписка — на сервере есть информация, которую может использовать один или несколько потребителей, пока она актуальная.
Преобразование объектов — клиент и сервер работают на разных наборах данных.
Преобразование протоколов — клиент и сервер используют разные протоколы связи.
Синхронное/асинхронное преобразование — клиент ожидает ответа в режиме онлайн, в то время как сервер рассчитан на ответ в режиме офлайн, или наоборот.
Объединение функций или данных — клиенту требуется комбинация из более чем одной операции и/или хранилища информации.
Маршрутизация — необходимо соединение с конкретным сервером на основе определенных правил.
Оркестрация — для ответа клиенту необходимо выполнить последовательность операций, и эта логика находится в одном месте. (Хореография — родственная концепция, в которой действия и логика последовательности распределены по задействованным сервисам; однако ее функциональные возможности ограничены, и обычно на практике оказывается, что в той или иной форме централизованный оркестровщик все‑таки присутствует, даже если это всего лишь пассивный набор справочных правил).
Контроль версий — разным клиентам нужны разные версии одной и той же операции.
Безопасность (см. Перспективу 6) — клиент и сервер должны быть защищены одним или несколькими способами.
Чем больше этих потребностей удовлетворяют клиентские и серверные системы внутри компании, тем меньше архитектор интеграции должен обеспечивать их извне. Другими словами, архитектура приложений и информационная архитектура существенно влияют на сложность и стоимость создания и эксплуатации интеграционной архитектуры.
Обычно нам приходится заботиться о некоторых внешних интеграционных функциях. Но чем более прямой и несложной будет интеграция, тем лучше.
Научиться адаптировать архитектурные решения для компании можно на онлайн-курсе "Enterprise Architect".
Паттерны и платформы промежуточных интеграционных решений
Ниже приведены паттерны решений внешней интеграции в порядке возрастания масштаба. Строго говоря, это не архитектурные паттерны, и некоторые из них функционально пересекаются. Поэтому следует осознавать их различия и использовать терминологию с осторожностью:
RPC (remote procedure call) — удаленный вызов процедуры, это когда компьютерная программа вызывает процедуру (подпрограмму) для выполнения из другого адресного пространства (обычно на другом компьютере в общей сети), но выглядит это так, как если бы это был обычный (локальный) вызов процедуры, чтобы упростить программирование и лишний раз не возиться с деталями сети, протокола, ОС и т. д.
Intra‑app интеграция — взаимодействие между слоями UI, приложения, домена и репозитория системы (термины DDD; или слоями UI, бизнес‑логики и базы данных в старой терминологии), например, между UI и слоем бизнес‑логики (с использованием протоколов HTTP) и между бизнес‑логикой и слоем базы данных (с использованием протоколов TNS/TTC поверх TCP/IP для Oracle DB).
Read API (DAL) — Read API или слой доступа к данным (Data Access Layer) является общим интеграционным слоем для оперативных источников данных (ODS), баз данных систем управления информацией (MIS DBs) и бизнес‑уровней BI, к которым обращаются транзакции чтения OLTP и OLAP.
API (Application Programming Interface) — программный интерфейс для взаимодействия между IT‑системами. API обычно поддерживает множество операций. При разработке учитывается стандартизация сигнатур функций и сетевых протоколов, после чего публикуется документ со спецификацией API. API часто имеют различные версии, доступные для разных клиентов. Также может поддерживаться динамическое обнаружение и связывание API и операций клиентами во время выполнения.
API GW — API Gateway реализует комбинацию таких архитектурных паттернов, как фасад, адаптер, медиатор и (обратный) прокси‑сервер. Он принимает клиентские вызовы и направляет их к сервисам, обеспечивая при этом такие функции, как маршрутизация, ограничение скорости, преобразование протоколов, агрегирование, безопасность, версионирование, протоколирование и т. д.
Системы обмена сообщениями — интеграционный паттерн обмена сообщениями позволяет обеспечить слабую связанность систем путем асинхронного взаимодействия, что также делает связь более надежной, поскольку обе системы не должны работать одновременно. Система обмена сообщениями отвечает за передачу данных от одной системы к другой, поэтому они могут сосредоточиться на информации, которой им нужно поделиться, а не управлять активным взаимодействием. Это похоже на почтовую службу.
Системы очередей (сообщений) — схема очередей расширяет асинхронную схему обмена сообщениями, формируя конвейер, в котором несколько сообщений могут последовательно храниться клиентскими или серверными системами до тех пор, пока они не будут потреблены, обычно по принципу FIFO (First In, First Out), или пока не станут неактуальными. Клиентские системы помещают запросы‑сообщения в очереди, а обслуживающие системы забирают и обслуживают сообщения в очередях ответов. Очереди повышают надежность и чистую пропускную способность, а также снижают потерю данных. Такая слабая связанность обеспечивает независимую и гибкую разработку систем. Управление очередями и их содержимым, контроль времени жизни сообщений, масштабирование, протоколирование и т. д. — это функции, предоставляемые платформой очередей сообщений. Это больше похоже на очередь за билетами в кино.
Системы с публикацией и подпиской (Publish‑Subscribe) — представляют из себя асинхронный и слабосвязанный паттерн коммуникации для обслуживающей системы, позволяющий сделать информацию или функции доступной заинтересованным клиентам в виде подписки. Это больше похоже на публикацию газет и подписку на них заинтересованных читателей.
ESB (Enterprise Service Bus) — сервисная интеграционная шина объединяет в одной программной платформе множество интеграционных функций, таких как обмен сообщениями, постановка в очередь, публикация‑подписка, маршрутизация, преобразование протоколов, преобразование объектов и т. д. Они являются одной из наиболее распространенных платформ EAI (см. ниже).
EAI‑платформы (Enterprise Application Integration) — в широком смысле платформы интеграции приложений предприятия могут обеспечивать все 12 интеграционных функций, описанных в разделе выше, и типы решений со 2 по 9 из этого списка.
Менеджеры рабочих процессов — платформы управления рабочими процессами объединяют системы и людей для инициирования, маршрутизации, поддержки принятия решений, ручных действий, автоматизированных заданий, координации и мониторинга последовательности шагов, выполняемых системами и людьми вместе для решения бизнес‑задач.
Менеджеры бизнес‑процессов — BPM‑платформы автоматизируют динамическую интеграцию бизнес‑процессов для обеспечения четко определенных, повторяемых, эффективных и надежных результатов. Они часто включают в себя сервисы по обнаружению, анализу и оптимизации.
Рекомендации
То, что требуется для интеграции, органично вытекает из архитектуры приложений и информации, а также бизнес‑процессов и рабочих процессов, которые они обслуживают. Но иногда нам приходится принимать решение о том, стоит ли рефакторить приложения для достижения лучшей интеграции или использовать внешнюю платформу.
Тест, изображенный ниже, помогает оценить необходимость внешней поддержки. Если оценка низкая, то рекомендуется рефакторинг приложений.
Перспектива 3: Паттерны интеграции приложений
С самого своего зарождения паттерны проектирования приложений включали в себя интеграционные паттерны. Некоторые из них соответствуют архитектурному мышлению — мы можем адаптировать и перенять их. В книге «Банды четырех», посвященной паттернам проектирования приложений, описаны следующие архитектурно значимые паттерны. Будучи архитектором приложений и интеграции, изучите и используйте эти их:
Фасад — обеспечивает единый интерфейс для набора интерфейсов в подсистеме. Фасад определяет интерфейс более высокого уровня, который упрощает использование подсистемы. Например, API‑фасад для Order (заказ) объединяет интерфейсы нескольких базовых подсистем, таких как ManageStock, CheckPayment, FulfilOrder и т. д.
Адаптер — преобразует интерфейс класса в другой интерфейс, который ожидают клиенты. Адаптер позволяет работать вместе классам, которые иначе не могут работать из‑за несовместимости интерфейсов. В архитектурных терминах вместо класса следует понимать систему, приложение, компонент или подкомпонент. Например, PaymentGWAdapter заполняет обязательное поле clienttype, требуемое интерфейсом платежной системы, значением по умолчанию для клиента, который его не предоставляет.
Прокси — предоставляет суррогат или заменитель другого объекта для контроля доступа к нему. Функционально эту группу паттернов можно разделить на удаленные прокси (локальное представление удаленного API), виртуальные прокси (обеспечивают кэширование и доступ к бэкэнду по требованию), защитные прокси (контролируют доступ на основе ролей и правил) и вспомогательные прокси (предоставляют дополнительные сервисы, такие как подсчет, ведение журнала и т. д.). Например, CDN (сеть доставки контента) использует обратный прокси для обеспечения безопасности, балансировки нагрузки и масштабирования.
Наблюдатель (он же публикация/подписка) — определяет зависимость «один ко многим» между объектами таким образом, что все зависимые объекты получают уведомления и автоматически обновляются при изменении состояния одного объекта. (Событийно‑ориентированная архитектура является примером этого паттерна). Например, если расписание рейсов авиакомпании (субъекта) меняется и несколько туристических порталов (наблюдателей) должны знать об этом, паттерн наблюдатель интегрирует их с помощью уведомлений, запросов и т. д.
Медиатор — определяет объект, который инкапсулирует взаимодействие множества объектов. Медиатор способствует слабой связанности, не позволяя объектам явно ссылаться друг на друга и позволяя вам варьировать их взаимодействие независимо друг от друга. Например, платформа онлайн‑продаж общается с несколькими платежными шлюзами через посредника, поэтому все эти компоненты можно заменить независимо друг от друга.
Слой защиты от повреждений (Anti‑corruption Layer, этот паттерн взят из DDD) — когда объединяются системы, основанные на разных моделях, необходимость новой системы адаптироваться к семантике другой системы может привести к искажению модели новой системы. Создайте изолирующий слой для предоставления клиентам функциональности в терминах их доменной модели. Слой общается с другой системой через ее существующий интерфейс, не требуя практически никаких изменений в другой системе. Внутри слой осуществляет преобразование между двумя моделями в обоих направлениях по мере необходимости. Например, мобильное банковское приложение взаимодействует со старой центральной банковской системой через ACL, который отделяет проверку кредитов от заказов, объединенных в одну функцию в старой системе.
Рекомендации
Возьмите на вооружение DDD, поскольку это естественным образом приводит к созданию ограниченных контекстов, системных архитектур поддоменов и контекстных карт, которые определяют выбор моделей внутри‑ и межсистемной интеграции.
19 марта пройдет открытый урок, на котором разберем роль корпоративного архитектора в 2025 году: навыки, инструменты, перспективы. Если интересно, записывайтесь на странице курса "Enterprise Architect" и присоединяйтесь.
