Руководство по архитектуре для реализации Rabbitmq .net - PullRequest
8 голосов
/ 24 октября 2011

Я ищу руководство по внедрению.Каковы преимущества и недостатки использования привязок wcf или простого ванильного .net rabbitmq api.Являемся ли момент, мы не обязаны использовать либо.Я новичок в rabbitmq, но сделал связку wcf.

У нас есть продукт, который собирает информацию от издателей на каждом устройстве.Продукт находится за брандмауэром (на данный момент).Издателю потребуется 3-4 канала.

  • Запрос / ответ на публикацию метрики для публикации / подписки на сервере с подтверждением от сервера.
  • Обновление канала для обновления базы издателей дляобнаружение метрики с сервера.
  • Канал пульса для проверки работоспособности сервера и ответа на пульс сервера.
  • Возможный канал мертвой буквы.

Издатель будет кроссплатформенным.Думая о хостинге на Mono, на Linux, BSD, Solaris, Android, MacOs, iOS и, возможно, Aix / HP-UX.Не знаю, насколько эффективными будут конечные точки wcf в этих случаях.

На сервере будет несколько рабочих, каждый из которых получит одно и то же сообщение от своего?Очередь, подтвердите это и обработайте это против их собственного rulebaseЯ хотел бы, чтобы рабочие были ориентированы на события.Сервер должен быть высокопроизводительным, от 10 до 100 тысяч сообщений в минуту.Никакие сообщения не могут быть потеряны от издателя к серверу.

Я склоняюсь к использованию простого API, поскольку он предлагает большую гибкость в отношении таких вещей, как многопоточность / сериализация / управление сеансами / безопасность / сжатие, но продукт может быть перемещен в Azure и предложен как SaaS или PaaS, иНаличие конечной точки wcf будет иметь смысл говорить с издателями на обоих окнах включения / выключения, но это будет в долгосрочной перспективе.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...