Архитектура маршрутизации WCF / ESB? - PullRequest
Новая
       26

Архитектура маршрутизации WCF / ESB?

4 голосов
/ 15 декабря 2011

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

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

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

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

private UnderlyingServiceClient _underlyingServiceClient = new UnderlyingServiceClient();

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

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

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

1 Ответ

0 голосов
/ 06 ноября 2012

Если я вас правильно понимаю, у вас есть несколько "бэкэнд" сервисов, возможно, на разных компьютерах.Затем у вас есть один сервис «fontend», который в основном действует как прокси для бэкэнда, но полностью настраивается в коде.Мы делаем эту точную настройку с несколькими компьютерами в стойке.Наш интерфейс - IIS7, сервер - это набор служб 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.Это просто для удобства, чтобы сделать код для создания нового канала короче.

...