Каковы некоторые подходы к корреляции / отображению объектов между различными системами, использующими архитектуру служебной шины?

Question

Я исследую использование архитектуры служебной шины на нашем предприятии для координации данных и бизнес-процессов между системами в нашей среде.

Наша ситуация типичная: ориентированные на клиента веб-приложения, которые передают сообщения во внутренние системы для выставления счетов, инвентаризации и т. Д. У нас есть несколько бизнес-структур, которые являются общими для большинства или для всех этих систем; каждая из этих систем поддерживает свои собственные версии этих объектов в своих собственных базах данных.

Применительно к концепции сервисной шины, мы можем опубликовать на автобусе сообщение с нашего клиентского веб-портала, представляющее заказ. Это сообщение может использоваться каждой заинтересованной системой (биллинг, инвентарь и т. Д.) Для создания соответствующих записей о клиентах в своих собственных базах данных. Однако когда одна из этих внутренних систем должна опубликовать сообщение о состоянии заказа, она будет иметь идентификатор заказа из своей собственной базы данных. Если нашему веб-порталу потребуется использовать это сообщение, он не будет знать, как соотнести идентификатор заказа, отправленный ему из нашей внутренней системы, с идентификатором заказа, который был сохранен в базе данных веб-портала.

Поскольку ни одна другая система по сути не знает о том, как эквивалентные объекты коррелируются между системами, кажется, что должен существовать некоторый тип механизма отображения, чтобы позволить системам преобразовывать идентификаторы, содержащиеся в сообщениях, в идентификаторы, относящиеся к ней. Например, можно создать таблицу базы данных, которая отображает идентификаторы из одной системы в другую. Эта таблица может быть запрошена для получения соответствующего идентификатора для целевой системы. В настоящее время наша компания не использует агрегацию объектов или какой-либо другой репозиторий типов "360 представлений", чтобы служить единым авторитетным источником для общей информации об объектах, из которой универсальный идентификатор может передаваться и использоваться всеми системами.

Является ли использование такого подхода сопоставления сущностей для сопровождения реализации служебной шины правильным? Если да, существуют ли какие-либо установленные руководящие принципы для разработки дизайна? Если нет, мне интересно услышать об альтернативных подходах к объединению сущностей между системами для облегчения интеграции через служебную шину.

PS: Если это помогает, я в настоящее время оцениваю среду MassTransit для построения нашей шины, так что, если есть информация, чтобы предложить определенную для нее, это также очень приветствуется.

Answer 1

Без более подробной информации я бы рассмотрел подход, который выглядит примерно так:

1. Сайт публикует SubmitNewOrder сообщение
2. Служба MiddleManager будет принимать это SubmitNewOrder сообщение и преобразовать его в задачи для каждой системы; с этим преобразованием вы могли бы сделать перевод ID
3. Каждая система имеет конечную точку, которая будет использовать правильное сообщение / команду и действовать соответственно

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

Если вы хотите углубиться в это, Enterprise Service Bus: Theory in Practice - это отличная книга для начала. Это не имеет ничего общего с MassTransit, но многие из этих теорий применимы и создают отличную основу.

Answer 2

Я проделал довольно много подобной работы в моей нынешней компании. Я родом из C# и был знаком с концепцией обслуживания автобусов. Проект, над которым я работал, в основном на Java, поэтому мы решили использовать Mule ESB в качестве нашего решения. Я очень рекомендую это, но я понимаю, что это может не играть "из коробки" также с кодом.NET.

Вопрос: Как вы управляете сущностями в разных системах?

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

Когда сущность приходит из одной системы, я считаю, что лучше всего создавать копии этой сущности в разных системах. Служебная шина будет извлекать данные, преобразовывать их, а затем загружать их в соответствующую систему. Источник и пункт назначения имеют фиксированный формат данных объекта, а сервисная шина выполняет перевод. Это сработало очень хорошо для нас.

Для общих сущностей это немного сложнее. Мы допускаем частичные изменения (одна система изменяет 5 свойств / полей, другая система управляет другими 3 свойствами / полями), что до сих пор работало нормально. Мы пытались минимизировать общие объекты из-за риска несогласованности данных. (Например, "Почему эта сущность выглядит странно? О, да, какая-то система изменила поле состояния, и я забыл, что это может сделать это".)

Использование очередей

Мы используем ActiveMQ и концепцию темы для передачи данных из системы в систему. Тема похожа на очередь, но многие подписчики могут слушать тему. Например, у нас есть внутренняя CMS, которая создает статьи. Когда пользователь публикует статью, она выходит в тему ActiveMQ.

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

Это оказалось очень легко понять / кодировать / тестировать / поддерживать.

Наличие картографической базы данных

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

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

Но если вы можете создать хранилище данных (XML, база данных, обычный файл и т. Д.), В котором есть сопоставления сущностей, я думаю, это нормально.

Генеральный Совет

Несколько советов от работы с сервисными автобусами:

1. Сервисный автобус - это не серебряная пуля. Это работает лучше всего, когда у вас есть широкий спектр технологий из моего опыта. Например, у нас есть MySQL, SQL Server, ActiveMQ, Mongo, CouchDb, Elastic Search и т. Д.

2. Я не знаю, как работает Mass Transit, но у Мула есть концепция потоков. Поток - это один концептуальный поток данных из точки А в точку Б. У вас может быть много потоков. Я делаю все возможное, чтобы сделать это очень просто. Это делает тестирование немного проще. Поскольку это интеграционная работа, отладка не так проста, и поэтому я предпочитаю устранять любые сложности.

3. Постарайтесь приблизить объекты к месту назначения как можно ближе к источнику. Другими словами, если я беру данные из веб-службы.NET и записываю их в SQL, я хочу, чтобы объект перешел на служебную шину на 90% пути к полному преобразованию. Опять же, это упрощает логику сервисной шины.