WCF Service Design

Question

В настоящее время у нас есть служба WCF, которая начинает достигать своих пределов производительности.

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

У нас есть веб-приложения, которые должны связываться с определенным сервером на основе контекста ... например. Если веб-приложение имеет дело с объектами из ServiceInstance1, запросы должны быть направлены в EndPoint ServiceInstance1. Если веб-приложение имеет дело с объектами из ServiceInstance2, запросы должны быть направлены в EndPoint ServiceInstance2.

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

Как это делается?

В настоящее время я добавил ServiceReference для каждой службы от Менеджера, однако кажется, что после того, как Служба «Ссылка», ее типы становятся специфичными для типов ServiceReference, например.

Тип ServiceInstance1 - это все {ServiceInstance1}. Тип ServiceInstance2 - все {ServiceInstance2}.

Мне нужно, чтобы типы были одинаковыми в конце веб-приложения, поэтому это, очевидно, кажется неправильным способом.

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

IServiceManager.GetProjectById({GUID}) -> 

Возвращается к ServiceManager -> Определяет, какой хост имеет проект и возвращает ProjectObject от правильного ServiceInstance.

Где ProjectObject - это тип, определенный в ServiceInstance1 и ServiceInstance2.

Я думаю, что для первоначальной службы необходимо, чтобы некоторые из DLL были вытащены, чтобы на них можно было ссылаться со стороны веб-приложения, а ServiceManager и клиент GenericWCF.

Если я прав ура для меня Если кто-то может указать мне в правильном направлении, я был бы признателен. Если я ошибаюсь, кто-то может ругать меня и показать мне, как это правильно сделано!

Answer 1

Чтобы ответить на этот вопрос и закрыть его, я воспользовался стратегией маршрутизации в .NET 4.0 и пользовательским классом клиентов, который я смоделировал после генерируемых классов из прокси.

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

Короче говоря, это работает на 100%, как и ожидалось, включая ServiceManager, который можно даже обойти по определенным вызовам, которые мы разрешаем.

У нас даже есть возможность переместить проект с сервера на сервер во время выполнения!

Спасибо всем, кто помог! (Особенно для фактической работы без подачи ложки)

Answer 2

Самый простой способ выполнить то, что вы пытаетесь сделать, - прекратить генерировать ваши прокси, используя URL-адрес службы, размещенной на сервере. Вместо этого создайте свои прокси-серверы из * .xsd и * .wsdl локально и просто измените URL-адрес конечной точки. Кроме того, вы можете использовать ChannelFactory<T> для генерации прокси на лету и ссылаться на ваш .dll с вашего интерфейса.

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

Не ставьте на него слишком тонкую точку, но «Сервисная ссылка» Visual Studio не полезна и не должна использоваться для служб, которые вы разрабатываете.Это полезно только для служб, разработанных извне, URL и контракты которых, вероятно, будут NEVER изменить. Я лично никогда не имел возможности использовать его. Для ваших собственных услуг вы, вероятно, должны использовать ChannelFactory<T> или класс на основе ClientBase<T> для разработки прокси.

Answer 3

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

Что вы строите - это очень простой маршрутизатор сообщений. В WCF 4.0 есть дополнительная поддержка для routing services, поэтому вы должны проверить эти функции, прежде чем разрабатывать свои собственные. Для WCF 3.5 Журнал MSDN содержит статьи о построении маршрутизатора сообщений - part 1, part 2.