Концептуальная модель системы управления маршрутизацией, коммутацией и трансформацией потоков данных

Решение интеграции в облаке лучше всего подпадает под архитектуру Master/Worker (мастер/работник). Архитектура Master/Worker представляет собой применение клиент-серверного подхода для реализации распределенных вычислений. Мастер (сервер) регистрирует подключения клиентов (работников) и, по их запросу, передает задания для вычислений. Работники рассматриваются как ненадежные и не требующие наличия постоянного соединения с мастером. Пользователь производит настройку на мастере, которой распределяет задания (интеграционные планы) на исполнительные приложения. Проблема масштабирования в этом случае решается за счет динамического изменения количества работников, а так же за счет разделения интеграционных планов между работниками.

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

• — Мастера;
• — Работники;
• — Очереди (Queue).

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

Пользователь взаимодействует с Мастером посредством веб-интерфейса (по HTTP протоколу), в то время как остальные приложения (Работники и Очереди) используют для взаимодействия с мастером REST-интерфейс.

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

При начале работы приложение отправляет по REST-интерфейсу следующую команду:

/announce?id=&type=, где id — идентификатор сессии работы приложения, а type — тип приложения (Работник/Очередь).

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

При завершении работы приложение отправляет по REST-интерфейсу следующую команду:

/failure?id=, где id — идентификатор сессии работы приложения.

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

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

При запуске приложения Работника генерируется уникальный идентификатор сессии этого приложения.

Работник соединяется с Мастером по «хорошо известному» доменному имени Мастера, заданному в конфигурационном файле Работника.

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

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

Приложение Очередь служит промежуточным звеном между Мастером и Работником. Оно необходимо для решения проблем масштабирования. При установлении соединения Мастера с Работником Мастер передает Работнику информацию об очереди, с которой должен быть ассоциирован рабочий процесс. Помимо доставки сообщений Очередь еще выполняет функцию наблюдения за работоспособностью работника. Это происходит при помощи механизма heartbeat’ов — работник получает сообщения от очереди через равные промежутки времени (polling). Если данный промежуток времени превышен, а ответ от работника не получен, то это означает, что работник находится в недопустимом состоянии. В этом случае происходит уведомление всех заинтересованных приложений (в частности, Мастера).

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

Для того чтобы зарегистрировать приложение у мастера, очередь делает POST запрос на адрес мастера. После этого приложение Очередь готова принимать запросы на создание очередей и производить запись сообщений в очереди.

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

Далее Очередь получает GET и POST сообщения. При получении GET сообщения очередь возвращает одно сообщение, которое было ранее поставлено в очередь. При получении POST сообщения приложение добавляет одно сообщение в очередь.

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

Жизненный цикл каждого приложения состоит из двух фаз: фазы инициализации и исполнения.

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

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

Работа выполнена при финансовой поддержке Минобрнауки России по государственному контракту от 31.07.2012 г. № 14.514.11.4001 в рамках ФЦП «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007;2013 годы».