|
Professor Seleznov
|
Всем привет!
Мы команда интеграции в Московской Бирже (MOEX).
В наши задачи входит развитие интеграционной шины (ESB).
Без надёжной интеграционной шины невозможно представить ни один межсистемный процесс.
В этом году мы реализовали проект по модернизации существующего решения ESB.
В результате улучшили процессы управления интеграциями и сократили время на создание типовых интеграций в несколько раз.
О том, какую ценность это несет и как это работает, данная статья.
Термины:
- Интеграционная шина (Enterprise Service Bus, ESB) - программное обеспечение для интеграции систем, которое обеспечивает обмен данными между системами и сервисами.
ESB состоит из брокера сообщений, который отвечает за передачу сообщений, и сервисов, которые добавляют к задачам надежной доставки сообщений дополнительную посредническую логику (трансформацию, смену протоколов, агрегацию, обогащение).
- Брокер- брокер сообщений, часть ESB.
В задачи брокера входит асинхронная передача сообщений по шаблонам p2p и pub/sub, гарантия их доставки, поддержка транзакционной обработки, маршрутизация, очередность, сглаживание пиковых нагрузок.
- Конфигурация- это набор параметров брокера, топики, очереди, маршруты, настройки безопасности и политики обработки, необходимые для реализации обмена сообщениями между системами (например, от системы A к системе B).
- Версия конфигурации - архив в корпоративном репозитории, содержащий файлы конфигурации. Устанавливается на конкретный стенд.
Обзор текущего процесса ESB (AS IS)
Текущий процесс по управлению интеграциями реализует три основных сценария:
- Проектирование. Определяет создание, изменение или удаление конфигураций и включает:
- Создание конфигураций в git.
- Документацию в wiki, ТЗ и страницу по подключению для клиентов.
- Версию конфигурации для установки.
- Набор тестов ручных и автоматических.
- Публикация. В рамках этого сценария выполняется установка версии конфигурации или откат на конкретный стенд, на конкретный брокер.
- Наблюдаемость. Информация о том на каком стенде установлена конфигурация.
И представляет собой многоэтапный последовательный процесс, в котором задачи распределены между разными инструментами и ролями в команде.
Процесс по управлению интеграциями схематично представлен на рисунке.
Процесс по управлению интеграциями AS IS
На основе проведенного анализа у текущего процесса управления интеграциям (AS IS) был выявлен ряд ограничений:
- Проектирование
- Этап системного анализа (SA). Большое количество времени уходит на определение того, к каким системам относятся подключаемые сервисы. Выполняется ручная проверка по реестру систем. Отсутствие справочника систем в текущем решении не позволяет установить связь с системами из реестра систем.
- Этап разработки (Dev). Конфигурация создаётся и изменяется вручную в Git. Отсутствует контроль именований и другие правила объектов конфигураций, ручные проверки на дубликаты, работа с ветками.
- Создание необходимой документации выполняется системным аналитиком (SA) и разработчиком (Dev).
- Публикация
- Этап (Ops) - установка интеграции на некоторые стенды требует прямого участия операционной (Ops) команды.
Процесс не автоматизирован: разработчику (Dev) необходимо передать сборку в (Ops), дождаться установки и проверить результат.
- Наблюдаемость
- Источник информации - Git и Wiki, что затрудняет поиск информации даже для команды интеграции.
- Часто необходимо обращаться к разработчику (DEV) для определения, установлена ли версия конфигурации на стенд.
- Нет единого реестра, где можно было бы найти версию конфигурации, установленную на конкретный стенд.
- Отсутствует возможность отслеживать статус публикации, историю изменений или текущие ошибки.
Что можем улучшить?
По результатам анализа и с учетом ожидаемого роста числа подключаемых систем и увеличением объёмов интеграции, мы приступили к модернизации существующего процесса.
Определили цели и задачи, а именно, в новой версии интеграционной шины мы ожидаем 5 возможностей, меняющих подход к управлению интеграциями:
- Плоскость управления (Control Plane)
Все сценарии по управлению интеграциями от создания интеграции до установки на конкретный стенд должны быть централизованы в одной системе.
Система должна включать лучшие практики и автоматизировать рутинные действия, которые выполняли роли SA, DEV, QA.
- Управление жизненным циклом конфигурации
Каждая конфигурация имеет чётко определённый жизненный цикл: от создания до активного использования или удаления. Это позволяет отслеживать статус каждой конфигурации, контролировать изменения и обеспечивать обратную совместимость.
Объекты из которых состоит конфигурация, поддерживают версионирование.
Это позволяет иметь разные версии одной и той же конфигурации на разных стендах - dev, test и prod, тем самым реализовывать необходимые корпоративные сценарии.
- Единый реестр конфигураций, доступный через UI
Клиенты могут получить доступ к реестру конфигураций через веб-интерфейс.
Реестр позволяет быстро находить нужные конфигурации, просматривать их параметры и отслеживать статус.
Фильтры по стенду и системе делают поиск интуитивно понятным и быстрым.
- Готовность к управлению конфигурациями через API
Новая шина предоставляет полноценный API для управления конфигурациями.
Это позволяет еще больше автоматизировать процессы, интегрировав другие системы с ESB.
- Self-service
Система реализует методы, при которых сценарии «проектирование» и «публикация» могут быть созданы клиентами, без участия команды интеграции.
По результатам согласования целей и задач приступили к модернизации текущего решения ESB.
Архитектура новой версии ESB
Новая версия 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.
Фильтры по системе, стендам и статусам позволяют быстро находить нужные конфигурации.
Модуль "Dashboard"
Технологии
Технически система построена на следующем стеке:
- 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
В процессе (TO BE) нет роли DEV. Снижена нагрузка на роли OPS и SA.
Результаты
Внедрение новой версии ESB позволит снизить затраты на реализацию типовых задач интеграций на 65% по предварительным оценкам команды.
Это достигается за счёт:
- автоматизации сценариев («проектирование», «публикация», «наблюдаемость»);
- уменьшения количества ролей в процессе;
- общей централизации.
С помощью обновлённой ESB мы упростили управление интеграциями для команды интеграции.
Время на реализацию сценариев «проектирование» и «публикация» сократилось, «наблюдаемость» стала прозрачной.
Возможность удаленного управления сценариями через api добавляет системе универсальность.
Ближайшие планы
Планируем дальнейшее развитие ESB:
- Интеграция c другими системами для дальнейшей автоматизации процесса.
- Реализовать Self-service.
- Реализовать возможность валидации сообщений.
Спасибо за внимание!
Если есть вопросы, пишите в комментариях - обсудим.-Источник
|
