Детализация сообщений для очередей сообщений и сервисных автобусов

Question

Я работаю над приложением, которое может генерировать тысячи сообщений в довольно узком цикле на клиенте для обработки на сервере. Цепочка событий выглядит примерно так:

1. Клиент обрабатывает элемент, помещает в локальную очередь.
2. Локальная обработка очереди принимает сообщения и вызывает веб-сервис.
3. Веб-служба создает сообщение в служебной шине на сервере.
4. Сервисная шина обрабатывает сообщение в базе данных.

Идея заключается в том, что все коммуникации асинхронные, поскольку для веб-службы будет много клиентов. Я знаю, что MSMQ может делать это напрямую, но у нас не всегда есть такая возможность администрирования на клиентах, чтобы настроить такие вещи, как безопасность и т. Д.

Мой вопрос о гранулярности сообщений на каждом этапе. Самый простой способ будет означать, что каждый элемент, обрабатываемый на клиенте, генерирует одно сообщение клиента / вызов веб-службы / сообщение служебной шины. Это хорошо, но я знаю, что лучше, если это возможно, объединять вызовы веб-служб, за исключением того, что существует компромисс между DTO веб-службы с высокой степенью детализации и краткосрочными транзакциями в базе данных. Этот конкретный сценарий не требует «бизнес-транзакции», когда обрабатываются все или ни одного элемента, я просто стремлюсь достичь наилучшего баланса между размером сообщения и количеством вызовов веб-службы и транзакциями базы данных.

Любой совет?

Answer 1

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

Этот подход, конечно, требует от вас возможности изменять интерфейс веб-службы после развертывания, поэтому вам необходим подход версиями для работы с клиентами, которые, возможно, не были переработаны, с поддержкой нескольких версий WS в параллели. Но, в любом случае, если не думать о версиях, то вы почти всегда попадаете в неоптимальные интерфейсы.

Answer 2

Абстрактная очередь сообщений

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

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

Вы также можете переводить сообщения из разных типов очередей в различных частях приложения или маршруте сообщения при изменении напряжений получателя, потому что они обрабатывают, например, 1000: 1 / с против 10: 1 / с на более высоком уровне.

Удачи

Answer 3

Интерфейсы Chatty (т. Е. Много-много сообщений) будут иметь тенденцию к большим накладным расходам от отправки входящего сообщения (и, на клиенте, ответа) на правильный код для обработки сообщения (это будет фиксированная стоимость за сообщение). В то время как большие сообщения, как правило, используют ресурсы при обработке сообщения.

Кроме того, большое количество выполняемых вызовов веб-служб будет означать необходимость управления многими соединениями TCP / IP, а также могут возникнуть проблемы с параллелизмом (включая блокировку в базе данных).

Но без некоторых деталей обработки сообщения трудно быть конкретным, кроме общих советов по поводу болтливых интерфейсов из-за фиксированных накладных расходов.