Это хорошая причина, чтобы использовать служебный автобус, альтернативы, пожалуйста

Question

Я на этапе планирования нашего нового сайта - это расширение некоторых мобильных приложений, которые мы создали. Мы хотим предоставить нашим пользователям центральную точку для общения, а также предоставить функции для пользователей, которые не хотят / не могут использовать мобильные приложения. Одной из функций, которые мы рассматриваем, является система репутации, похожая по своей природе на систему бейджей SO. Мы разрабатываем систему для использования SOA.

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

1. Чтобы искать определенные черты в действиях пользователей и отвечать на них, это означало бы, что запущена служба, которая может работать через «подключенные» определения вознаграждений и проверять пороговые значения, которые были выполнены, и реагировать соответствующим образом.
2. Чтобы инициировать события, когда пользователь выполняет действия - прослушивайте эти события и отвечайте соответствующим образом. Поскольку службы, которые будут выполнять эти действия, работают в отдельных доменах приложений, возможно, на отдельных серверах, единственный способ увидеть центральную шину сообщений для прослушивания и ответа на эти события - использовать что-то вроде MassTransit, nServiceBus или Rhino.Esb. ,

Я знаю, что использование служебной шины очень легко может быть неправильно спроектировано в приложение, которое просто не нуждается в этом, и в большинстве случаев - если вы не интегрируете разнородные гетерогенные системы - вам, скорее всего, она не понадобится при разработке новая система, но я немного потерян для вариантов, как лучший способ сделать это. Мне не нравится идея, что служба все время бьет в фоновом режиме. Но это звучит так, как будто это может быть намного проще на раннем этапе - позже - я боюсь думать!

Кто-нибудь здесь разработал такую ​​систему? Как ты это сделал? Мы проектируем высокую пропускную способность, так как ожидаем, что система будет способна справляться со вспышками пользователей.

Answer 1

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

• Плагины
• Обмен сообщениями о событиях - с использованием Emesary

Основная концепция заключается в том, что core не знает точно, какой модуль будет выполнять какую-либо задачу.

Сообщения определены и в точках внутри системы они отправляются.Отправитель не знает, требуется ли сообщение.Это эффективно разъединяет обширные фрагменты системы.

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

Код Emesary чрезвычайно мал и эффективен в первом случае, когда я его назвал ( Emesary , и выиспользовать его бесплатно или из Emesary CodePlex

Поскольку система становится все более сложной, возможно, что происходит много событий, если вы получаете более 20 Кбит / с, это всегда былоВ моем дизайне добавлена ​​фильтрация и маршрутизация (реализована за счет расширения интерфейса получателя, позволяющего получателю указывать сообщения, которые он хочет получать во время регистрации). Мне никогда не приходилось добавлять эту фильтрацию, потому что Emesary достаточно эффективен для обработкисообщений, которые занимают время.

Я создал версию Emesary, которая соединяет два уведомителя между разнородными системами с использованием WCF, Corba и TCP / IP. Я исследовал с помощью RabbitMQ и решилбыло возможно использовать это под Emesary при необходимости.

Базовый класс Diagram

Масштабируемый сервер.

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