Сценарии интеграции приложений. Переосмысление

Каждый год в конце декабря я пытаюсь ответить себе на вопрос: зачем я веду этот блог. И каждый год находится хотя бы одна запись, которой мне удалось что-то более или менее внятно объяснить. В этом году такой заметкой стала «Объясняем матрицу Захмана». К сожалению, количество не очень понятных записей превосходит количество понятных. Есть темы, с которыми не получается справиться с первого раза. Одна из них: «Сценарии интеграции приложений». Я пытался писать об этом с 2010 года и результат не считаю удовлетворительным. Поэтому, мы её немного перезапустим. Кстати, в конце января 2019 года я проведу вебинар «Нужна ли предприятию сервисная шина? Вебинар по ИТ-стратегии», анонс которого отслеживайте в telegram-канале https://telegram.im/@it_arch, а сегодня несколько соображений по интеграции.

Сначала краткий обзор предыдущих сообщений. Кроме уже упомянутого, это:

Затем про книжки. Благодаря комментариям читателей я хочу добавить к упомянутой в раннем сообщении книге Шаблоны интеграции корпоративных приложений (Enterprise Integration Patterns, см. http://www.eaipatterns.com/ ) тоже не очень новую, но, на мой взгляд, неплохую книжку от Microsoft с названием Integration Patterns.

А теперь несколько слов о переосмыслении подхода к описанию сценариев интеграции приложений. Наверное, самое важно в описании сценариев или же паттернов состоит в том, чтоб избавиться от мышления «точка-точка». В описании паттерна количество действующих лиц (участников) всегда больше двух. Ну, а даже если их только два, то взаимодействие между ними нетривиальное.

Приведу пример. Довольно сложно человеку, который не знает что такое command-query responsibility segregation (CQRS), объяснить что же это. Статья в Википедии не поможет. Поиск по сайтам, тоже не очень. Если хватит терпения, то можно посмотреть видео Greg Young – CQRS and Event Sourcing  или послушать эту историю в моем исполнении.  Я использую следующий методический трюк. Сначала рассказываю про CAP-теорему на простом примере. Представьте себе, что вам нужно сделать хранилище для некоторой информационной системы. Обязательным условием, которое вы не в силах изменить, является дублирование каждой записи минимум на двух разных узлах. В простейшем случае у вас есть два экземпляра базы данных (см. рисунок ниже).

Функция модификации записи в этом случае может выглядеть так: Клиент1 отправляет команду БД1. Она блокирует изменяемую запись и запускает процедуру модификации на всех других узлах. БД2, получив команду на обновление, блокирует свой экземпляр записи, меняет его, разблокирует и сообщает об этом БД1. Дождавшись завершения операции на всех узлах, в том числе и у себя, БД1 возвращает управление клиенту. С доступностью в этом случае у нас есть некоторые проблемы. С согласованностью тоже, но об этом чуть позже. Поэтому мы выбираем другую тактику обновления записи: не дожидаемся завершения операций на всех узлах, а меняем запись только в БД1 и сразу возвращаем управление Клиенту1, а команду на обновление записи на других узлах помещаем в очередь сообщений.

Ну, а теперь самое интересное. Какой бы вариант мы не выбрали, существует одна маленькая проблема: что случится если одновременно с Клиентом1 эту же запись начнет модифицировать Клиент2, например, отправив такую команду на узел БД2? Правильно, ничего хорошего. Очевидным решением нарушения согласованности данных в этом случае является использования для модификации данных только одного узла.

Ну, а дальнейшие рассуждения очевидны. Можно вспомнить про глаголы протокола HTTP, порассуждать об event sourcing, растиражировать БД2 в разных форматах, удобных для определенного типа запросов на чтение – это всё следствия. Главное понять почему полезно разделять стороны записи и чтения, command и query. (Кстати, если кто-то из ваших коллег еще не знает, что такое CQRS, пригласите его на тренинг Мастерская проектирования ИТ-решений http://itexpert.ru/aws/ – это была рекламная пауза, продолжаем).

Повторю свой главный тезис: вы не можете описать сценарии интеграции, рассматривая их как простое взаимодействия всего двух агентов. Нужен более широкий контекст. Передача данных из пункта А в пункт Б, как правило, происходит в рамках более длинного маршрута, например, петли CQRS. Аналогичные суждения справедливы и для синхронизации изменений общекорпоративных справочников и для event-based интеграции и для расширения функционала системы посредством микросервисов. Второй тезис: такие идеи надо рассказывать, а не описывать текстом, кодом или картинками. В какой-то мере, помогут анимированные картинки, как например представлены паттерны рабочих процессов на сайте Workflow Patterns (см, например: http://www.workflowpatterns.com/patterns/control/basic/wcp4_animation.php), но они не ответят на ваши вопросы не расскажут об исключениях. В общем, сценарии интеграции приложений располагают к живому общению

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *