Регистрация службы WCF для распространяемых приложений - PullRequest
1 голос
/ 13 января 2010

Я нахожусь в процессе разработки клиент-серверного приложения, которое будет использовать WCF для связи с клиентом. Вполне возможно, что он может стать сильно загруженным и захотеть создать его распределенным образом. Для этого я разделил приложение на несколько сервисов. Может быть запущено N служб для обработки запросов.

  • Служба входа
  • игровой сервис
  • обслуживание в номерах
  • и т.д.

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

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

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

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

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

Спасибо

1 Ответ

2 голосов
/ 13 января 2010

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

Используя шину, вы можете использовать подход pub / sub для связи между службами или, более того, с точки зрения бизнеса.

Я бы отказался от подхода к базе данных в # 1 для хранения манифеста сервисов, вместо этого оставив эту информацию в рабочей конфигурации шины. При подходе «паб / суб» и потенциально содержащейся в нем информации о маршруте вы должны быть на правильном подходе.

Взгляните на NServiceBus или MassTransit

...