Всем привет!

О том, какую ценность это несет и как это работает, данная статья.

Термины: 

• Интеграционная шина (Enterprise Service Bus, ESB) - программное обеспечение для интеграции систем, которое обеспечивает обмен данными между системами и сервисами. 
  ESB состоит из брокера сообщений, который отвечает за передачу сообщений, и сервисов, которые добавляют к задачам надежной доставки сообщений дополнительную посредническую логику (трансформацию, смену протоколов, агрегацию, обогащение).

• Брокер - брокер сообщений, часть ESB. 
  В задачи брокера входит асинхронная передача сообщений по шаблонам p2p и pub/sub, гарантия их доставки, поддержка транзакционной обработки, маршрутизация, очередность, сглаживание пиковых нагрузок.

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

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

Обзор текущего процесса ESB (AS IS)

Текущий процесс по управлению интеграциями реализует три основных сценария:

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

  • Создание конфигураций в git.

  • Документацию в wiki, ТЗ и страницу по подключению для клиентов. 

  • Версию конфигурации для установки.

  • Набор тестов ручных и автоматических. 
    

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

• Наблюдаемость. Информация о том на каком стенде установлена конфигурация.

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

Процесс по управлению интеграциями схематично представлен на рисунке. 

На основе проведенного анализа у текущего процесса управления интеграциям (AS IS) был выявлен ряд ограничений:

• Проектирование 

  • Этап системного анализа (SA).  Большое количество времени уходит на определение того, к каким системам относятся подключаемые сервисы. Выполняется ручная проверка по реестру систем. Отсутствие справочника систем в текущем решении не позволяет установить связь с системами из реестра систем.

  • Этап разработки (Dev). Конфигурация создаётся и изменяется вручную в Git. Отсутствует контроль именований и другие правила объектов конфигураций, ручные проверки на дубликаты, работа с ветками. 

  • Создание необходимой документации выполняется системным аналитиком (SA) и разработчиком (Dev).
    

• Публикация

  • Этап (Ops) - установка версии конфигурации на некоторые стенды требует прямого участия операционной команды (Ops). 
    Процесс не автоматизирован: разработчику (Dev) необходимо передать сборку инженеру (Ops), дождаться установки и проверить результат. 

• Наблюдаемость

  • Источник информации - Git и Wiki, что затрудняет поиск информации даже для команды интеграции.

  • Часто необходимо обращаться к разработчику (DEV) для определения, установлена ли версия конфигурации на стенд.

  • Нет единого реестра, где можно было бы найти версию конфигурации, установленную на конкретный стенд. 

  • Отсутствует возможность отслеживать статус публикации, историю изменений или текущие ошибки. 

Что можем улучшить?

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

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

1. Плоскость управления (Control Plane)
   Все сценарии по управлению интеграциями от создания интеграции до установки на конкретный стенд должны быть централизованы в одной системе.
   Система должна включать лучшие практики и автоматизировать рутинные действия, которые выполняли роли SA, DEV, QA.  

2. Управление жизненным циклом конфигурации
   Каждая конфигурация имеет чётко определённый жизненный цикл: от создания до активного использования или удаления. Это позволяет отслеживать статус каждой конфигурации, контролировать изменения и обеспечивать обратную совместимость.
   Объекты из которых состоит конфигурация, поддерживают версионирование.
   Это позволяет иметь разные версии одной и той же конфигурации на разных стендах - dev, test и prod, тем самым реализовывать необходимые корпоративные сценарии. 

3. Единый реестр конфигураций, доступный через UI
   Клиенты могут получить доступ к реестру конфигураций через веб-интерфейс.
   Реестр позволяет быстро находить нужные конфигурации, просматривать их параметры и отслеживать статус.
   Фильтры по стенду и системе делают поиск интуитивно понятным и быстрым.

4. Готовность к управлению конфигурациями через API
   Новая шина предоставляет полноценный API для управления конфигурациями.
   Это позволяет еще больше автоматизировать процессы, интегрировав другие системы с ESB.

5. Self-service 
   Система реализует методы, при которых сценарии «проектирование» и «публикация» могут быть созданы клиентами, без участия команды интеграции. 

По результатам согласования целей и задач приступили к модернизации текущего решения ESB.

• Первая часть - это плоскость управления (Control plane), которая реализует новый подход к управлению интеграциями. В Control plane реализовано четыре модуля: Конфигурации (Configuration), Топология (Topology), Обновления (Upgrade), Реестр интеграций (Dashboard), каждый из которых решает конкретную задачу и в совокупности являются основой для Self-service.
  С Control plane работает оператор, клиенты или другие системы реализуя сценарии: «проектирование», «публикация», «наблюдаемость».

• Вторая часть - плоскость данных (Data plane). Это существующий ci в виде git и ci/cd-конвейера и стендов интеграционных шин от теста до прода. 

Перейдем к Control plane и рассмотрим каждый модуль отдельно:

• Конфигурации (Configuration). Основная задача модуля - обеспечить создание, изменение и хранение объектов конфигурации брокера (топики, очереди, маршруты, настройки безопасности и политики) и их версионирование.

  Принятые архитектурные решения:

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

  • Ключевые поля объектов становятся неизменяемыми после создания.

  • Для каждого объекта конфигурации поддерживается версионирование, что позволяет иметь разные версии одного и того же объекта.
    Например, версия очереди для стенда dev может отличаться от версии очереди для cтенда test, и обе версии будут корректно отображаться и управляться.

  • При создании и редактировании объектов проверяется соответствие принятому шаблону именования объектов. 

  • Автоматизировано создание связанных объектов. Например, при создании системы создаются роли и настройки безопасности.

• Топология (Topology) добавляет системы и окружения в модель управления для интеграции с ИТ-ландшафтом компании.

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

  • Окружение содержит полную информацию о стенде: тип стенда (dev, test, prod) и параметры брокеров.

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

  Принятые архитектурные решения:

  • Конфигурации брокера группируются в контейнеры (Upgrade), соответствующие задачам на изменения.

  • Upgrade имеет собственный жизненный цикл, от разработки до готовности к установке. 

  • Upgrade может быть установлен на стенд (или выполнен откат со стенда). В рамках установки автоматически создается версия релиза и отправляется в внутренний корпоративный Git-репозиторий. Далее ci/cd конвейер выполняет установку версии релиза (конфигураций) на стенд. Модуль отслеживает статус ci/cd конвейера и обновляет статус. 

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

• Реестр интеграций (Dashboard)
  Основная задача модуля - предоставить клиентам реестр конфигураций. 
  В интерфейсе можно ввести название системы, выбрать стенд и получить список всех маршрутов или любых других конфигураций, установленных на конкретном стенде.
  Каждый маршрут отображается с указанием системы источника, системы получателя, а также со ссылкой на соответствующий Upgrade. 
  Фильтры по системе, стендам и статусам позволяют быстро находить нужные конфигурации.

Технологии

Технически система построена на следующем стеке:

• Frontend - React

• Backend - Spring Boot 

• База данных - PostgreSQL 

Безопасность

Аутентификация реализована через систему аутентификации и авторизации на основе OAuth 2.0 и OpenID Connect.

Авторизация реализована по модели RBAC (Role-Based Access Control).

Реализовано несколько ролей с разными правами доступа, от просмотра до управления. 
При установке обновления на стенд система проверяет соответствие типов окружений - нельзя установить обновление на конкретный тип стенда если это не разрешено.

Реализован аудит. События логируются: кто, когда и что создал, изменил или удалил. 

Процесс (TO BE)

Процесс по управлению интеграциями (TO BE) c Плоскостью управления (Control plane) схематично представлен на рисунке.  

В процессе (TO BE) нет роли DEV. Снижена нагрузка на роли OPS и SA. 

Результаты

• автоматизации сценариев («проектирование», «публикация», «наблюдаемость»);

• уменьшения количества ролей в процессе; 

• общей централизации.

С помощью обновлённой ESB мы упростили управление интеграциями для команды интеграции. 
Время на реализацию сценариев «проектирование» и «публикация» сократилось, «наблюдаемость» стала прозрачной.
Возможность удаленного управления сценариями через api добавляет системе универсальность.

Ближайшие планы

Планируем дальнейшее развитие ESB:

• Интеграция c другими системами для дальнейшей автоматизации процесса. 

• Реализовать Self-service.

• Реализовать возможность валидации сообщений.

Спасибо за внимание!
Если есть вопросы, пишите в комментариях - обсудим.