Это хорошая / плохая архитектура: несколько служб WCF взаимодействуют друг с другом через один статический объект?

Question

Немного предыстории: я обычно работал над небольшими проектами, для которых не требовалась значительная архитектура или проблемы масштабирования (например, разработка небольших веб-приложений с использованием веб-форм и MVC).

Что яЯ работаю над: сейчас я создаю набор приложений WCF (сервис WCF, который маршрутизирует сообщения между клиентом-запросчиком и клиентом-ответчиком), который должен быть стабильным, масштабируемым и, очевидно, отзывчивым.

Что я делаю: у меня есть «брокерская служба», выполняющая две конечные точки, одну для клиентов-запросчиков и одну для клиентов-респондентов.Каждая служба и клиент по существу работают со значениями по умолчанию WCF, за исключением того, что ConcurrencyMode имеет значение Reentrant.

//Client
[CallbackBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

//Service
[ServiceBehavior(ConcurrencyMode=ConcurrencyMode.Reentrant)]

Естественно, что каждый экземпляр службы (PerSession) независим от друг друга и не может взаимодействовать с каждымДругой.Итак, чтобы построить мост между ними, у меня есть класс MessageBroker с одноэлементным экземпляром, к которому сервисы обращаются.Посредник перенаправляет запросы от запрашивающей службы к службе-ответчику и направляет ответы таким же образом.

Меня беспокоит то, чтобы этот один объект / экземпляр направлял все сообщения для всей системы и влияние на производительностьтот.Сейчас каждый из клиентов вызывает свои соответствующие методы Send *, используя предопределенные * асинхронные методы, определенные при добавлении ссылки на службу, а обратные вызовы на клиентах запускают события, используя методы вызова Begin / End делегата события.Кроме того, на данный момент все методы вызываются синхронно.Я подумываю добавить больше многопоточности в форме использования методов вызова Begin / End делегата в брокере (у меня есть еще один вопрос об исчерпании потоков в пуле потоков с использованием этого метода).

Поскольку яЯ новичок во всей этой концепции дизайна / архитектуры, и я хочу знать, является ли то, что я делаю, правильным путем или мне следует подумать о внедрении другой архитектуры (это первое и, казалось бы, самое очевидное,Я придумал).

На самом деле у меня нет наставника, чтобы обмениваться идеями на местном уровне, поэтому я надеюсь, что сообщество может дать небольшое руководство.

Спасибо за любые советы и предложенияили критика.:)

Answer 1

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

• пережить пики в нагрузке
• масштабирование вместо увеличения
• управление временем простоя службы (как на вашем конце, так и на стороне клиента службы)

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

Вы также можете рассмотреть услугу для предоставления инфраструктуры обмена сообщениями, например Amazon SQS .

И, наконец, если ваша серверная часть работает на основе SQL Server, то вы можете использовать асинхронный обмен сообщениями прямо из базы данных: Service Broker .

Answer 2

Этот тип проблемы - именно то, для чего был создан BizTalk. Вы могли бы расследовать либо привнесение, либо подражание его поведению.

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

По сути, Biztalk поддерживает не одноэлементное состояние, используя состояние базы данных для точного хранения сообщения. Считай это как конечный автомат. В случае, если biztalk get перезагружается или теряет связь где-либо, он может легко вернуться туда, где он был в конвейере сообщений. Поэтому любой поток может обрабатывать любые изменения состояния сообщения; что делает его довольно надежным.

Выше приведена очень упрощенная версия того, что делает Biztalk. Кроме того, существуют другие системы обмена сообщениями, которые имеют похожее поведение. Возможно, вы захотите сделать некоторые исследования, прежде чем погрузиться в разработку собственного решения. Лично я считаю, что Biztalk довольно дорогой. Но мой опыт показывает, что он надежен и стоит намного дешевле, чем попытка разработчика (или команды) имитировать его функциональность.