#c# #wcf #architecture #rabbitmq
#c# #wcf #архитектура #rabbitmq
Вопрос:
Я ищу некоторые рекомендации по реализации. Каковы плюсы и минусы использования привязок wcf или использования простого ванильного api .net rabbitmq. В данный момент мы не ограничены в использовании. Я новичок в rabbitmq, но сделал пакет wcf.
У нас есть продукт, который собирает информацию от издателей на каждом устройстве. Продукт находится за брандмауэром (на данный момент). Издателю потребуется 3-4 канала.
- Запрос / ответ на публикацию метрики для публикации / подписки на сервере с подтверждением с сервера.
- Обновить канал, чтобы обновить базу правил издателя для обнаружения метрик с сервера.
- Канал сердцебиения для проверки работоспособности сервера и ответа на сердцебиение сервера.
- Возможный канал мертвых писем.
Издатель будет кроссплатформенным. Подумываю о размещении на Mono, Linux, BSD, Solaris, Android, macOS, iOS и, возможно, Aix / HP-UX. Не знаю, насколько эффективными будут конечные точки wcf в этих случаях.
На сервере будет несколько рабочих, каждый из которых получит одно и то же сообщение от своего? поставьте его в очередь, подтвердите его и обработайте в соответствии со своей собственной базой правил. Я бы хотел, чтобы рабочие были управляемыми событиями. Сервер должен быть высокопроизводительным, от 10 до 100 тыс. сообщений в минуту. Никакие сообщения не могут быть потеряны от издателя к серверу.
Я склоняюсь к использованию простого api, поскольку он обеспечивает большую гибкость в отношении таких вещей, как потоковое управление / сериализация / управление сеансами / безопасность / сжатие, но продукт может быть перемещен в Azure и предлагаться как SaaS или PaaS, а наличие конечной точки wcf имело бы смысл для общения с издателями как в окнах включения, так и выключения,но это будет в долгосрочной перспективе.
Комментарии:
1. На этот вопрос слишком широкий ответ. Рекомендуем удалить его или значительно сократить (я предполагаю, что необходимость больше не актуальна).
2. Прошло некоторое время. Что вы выбрали?
3. Было бы лучше разделить этот вопрос на несколько. Чтобы разделить нагрузку между рабочими, вы бы выбрали одну- долговременную очередь, разделяемую между рабочими, явные подтверждения. Начните с простого, используйте только одного работника. Для пары сотен сообщений в секунду вашим узким местом будет ввод-вывод, связанный с обработкой (чтение / запись БД, другие побочные эффекты …), и ничего на стороне брокера, особенно при предварительной выборке> 1.
4. Это старый вопрос. Я был бы рад разделить его.
Ответ №1:
Архитектура программного обеспечения заключается в том, чтобы откладывать решения, а не принимать их заранее.
Используемые вами привязки должны быть относительно легко изменены по мере продвижения вашего проекта. Поскольку они являются деталями реализации, важно, чтобы вы определяли четкие, краткие и простые интерфейсы в своем коде, поэтому ваш собственный код для этих сервисов зависит от его абстракции (определяемого вами интерфейса), а не от конкретной реализации (кода, который использует привязки, и того факта, чтоброкер говорит на amqp).
Выберите реализацию, которая имеет наибольший смысл сейчас (учитывая ваши планы по переходу на Azure), но не вступайте в брак с ней.