Я ищу некоторые рекомендации по реализации. Каковы плюсы и минусы использования привязок wcf или простого API vanilla .net rabbitmq. Момент, который мы тоже не обязаны использовать. Я новичок в rabbitmq, но сделал связку wcf.
У нас есть продукт, который собирает информацию от издателей на каждом устройстве. Продукт находится за брандмауэром (на данный момент). Издателю понадобится 3-4 канала.
- Запрос/ответ на публикацию метрики для публикации/подписки на сервере с подтверждением от сервера.
- Обновите канал, чтобы обновить базу правил издателя для обнаружения метрик с сервера.
- Канал пульса для проверки работоспособности сервера и ответа на пульс сервера.
- Возможный канал с мертвой буквой.
Издатель будет кроссплатформенным. Думаем о хостинге на Mono, Linux, BSD, Solaris, Android, MacOs, iOS и, возможно, Aix/HP-UX. Не знаю, насколько эффективными будут конечные точки wcf в этих случаях.
На сервере будет несколько рабочих, каждый из которых получит одно и то же сообщение от своего? очередь, подтвердите ее и обработайте в соответствии со своей собственной базой правил. Я хотел бы, чтобы рабочие были управляемы событиями. Сервер должен быть высокопроизводительным, от 10 000 до 100 000+ сообщений в минуту. Никакие сообщения не могут быть потеряны от издателя к серверу.
Я склоняюсь к использованию простого API, поскольку он предлагает большую гибкость в отношении таких вещей, как многопоточность/сериализация/управление сеансами/безопасность/сжатие, но продукт может быть перемещен в Azure и предлагаться как SaaS или PaaS, и иметь конечную точку wcf будет иметь смысл. поговорить с издателями в обоих окнах включения и выключения, но это будет в долгосрочной перспективе.
