WCF Routing/ESB Architecture?

Question

Я работаю над созданием набора корпоративных услуг с использованием WCF 4 в своей организации и могу использовать некоторые рекомендации. Настройка/архитектура, которые я разработал до сих пор, похож на легкий пользовательский ESB. У меня есть одна главная услуга «брокер» (с использованием wsHttp), которая соединяется с тремя базовыми услугами netTcp. Оба брокера и базовые службы имеют общую сборку, содержащую модель, а также контрактные интерфейсы. В брокерской службе я могу выбрать, какие операции из базовых услуг я хочу открыть. Идея заключается в том, что потенциально у нас может быть ядро ​​набора услуг и несколько разных брокеров, в зависимости от потребностей бизнеса. Мы планируем разместить все (включая услуги netTcp) в IIS 7.5, используя AppFabric и WAS.

Вот мой вопрос, такая хорошая практика и будет ли она масштабироваться? Эти службы должны иметь возможность обрабатывать тысячи транзакций в день.

Я играл с маршрутизацией в WCF 4 вместо концепции обслуживания брокера, о которой я упомянул, однако, не видел в ней большой ценности, поскольку он просто перенаправляет.

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

private UnderlyingServiceClient _underlyingServiceClient = new UnderlyingServiceClient(); 

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

Моя цель заключается в обеспечении того, чтобы клиент, потреблявший их, мог «как можно быстрее получить доступ и выйти». Быстрый запрос-ответ.

Любой вход/обратная связь будет принята с благодарностью.

Answer 1

Если я правильно вас понимаю, у вас есть несколько «бэкэнд», возможно, на отдельных компьютерах. Затем у вас есть одна служба «fontend», которая в основном действует как прокси-сервер для бэкэнд, но полностью настраивается в коде. Мы делаем эту точную настройку с нескольких компьютеров в стойке. Наш интерфейс - IIS7, backend - это куча wcf-сервисов на нескольких машинах.

Один, будет ли он масштабироваться? Ну, добавление дополнительной мощности обработки на бэкэнде довольно просто, и писать код балансировки нагрузки тоже не так уж плохо. Для нас проблема заключалась в том, что интерфейс оказался увязшим, хотя он действовал только как прокси. В итоге мы добавили еще несколько интерфейсных компьютеров, «брокеры», как вы их называете. Это работает очень хорошо. Люди предположили, что я использую Microsoft ForeFront для автоматической балансировки нагрузки, но я еще не исследовал ее.

Двое, нужно ли кэшировать прокси? Я бы сказал, безусловно, да, но это отстой. Иногда эти каналы прерывают работу. У меня есть поток, который всегда работает в фоновом режиме. Каждые 3 секунды он просыпается, проверяет все службы wcf и wcf-клиентов в приложении. Любые, которые ошибочно, уничтожаются и воссоздаются.

проверка хост-каналы: ...

while(true) 
{ 
    try{if(MyServiceHost.State!=System.ServiceModel.CommunicationState.Opened) {ReCreate();}} catch{} 
    System.Threading.Thread.Sleep(3000); 
} 

проверка клиентских каналов: ...

private static ChannelFactory<IMath> mathClientFactory = new ChannelFactory<IMath>(bindingHttpBin); 
    while(true) 
    { 
    try 
    { 
     if(MyServiceClient.State==System.ServiceModel.CommunicationState.Faulted) 
     { 
     EndpointAddress ea = new EndpointAddress(ub.Uri); 
     ch = WcfDynamicLan.mathClientFactory.CreateChannel(ea); 
     } 
    } 
    catch{} 
    System.Threading.Thread.Sleep(3000); 
    } 

На клиенте, я не кэшировать только канал, но и кэш ChannelFactory. Это просто для удобства, хотя сделать код для создания нового канала короче.