Дизайн шины сообщений - поддерживает неявный порядок сообщений?

Question

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

Есть несколько вариантов:

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

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

Answer 1

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

На мой взгляд, первый вариант можно отбросить несмотря ни на что. :)

Answer 2

Ваш второй вариант предлагает лучшее из всех миров:

• когда заказ не требуется, мы выигрываем от простой архитектуры и масштабируемости.
• когда требуется заказ, он разрабатывается только один раз, а не для каждого приложения.

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