Служба шлюза в сервис-ориентированной архитектуре - PullRequest
Новая
       43

Служба шлюза в сервис-ориентированной архитектуре

1 голос
/ 04 июля 2011

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

Во-первых, он записывает, сколько запросов было обработано SOA-серверами, и повторяет следующий запрос на наиболее доступном сервере. Полный контроль над логикой балансировки нагрузки привлекателен.

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

Мои вопросы: есть ли причина, по которой это не было бы "правильным способом делать вещи"? Я заново изобретаю колесо, когда уже есть структура, которая делает то, что я описал выше? Мой стек - .NET и WCF.

1 Ответ

1 голос
/ 12 июля 2011

Хороший вопрос, но я должен согласиться с комментарием sweetfa, в 99% случаев лучшим вариантом будет стандартный балансировщик нагрузки.Более исчерпывающий список опций:

  1. аппаратный балансировщик нагрузки / шлюз (например, IBM XML Gateway) - очень масштабируемый и дорогой
  2. программное обеспечение сервисной шины (например, Oracle Service Bus) подойдетбезопасность и балансировка нагрузки - очень настраиваемые и дорогие.Менее масштабируемое, чем аппаратное решение
  3. программное обеспечение с открытым исходным кодом для балансировки нагрузки (например, модуль Apache HTTPD Proxy) будет иметь большое количество пользователей, которые помогут вам настроить его через форумы.Многие решения достаточно масштабируемы и надежны, но будут иметь более сложный способ настройки, чем варианты 1 и 2
  4. балансировка нагрузки на основе реестра служб (UDDI v3), когда потребитель службы ищет URI поставщикана каждом вызове.Реестр будет балансировать запросы, возвращая разные URI.Это решение не будет выступать в качестве шлюза безопасности, и потребители могут полностью его игнорировать
  5. построить свой собственный, если вам нужен какой-то усовершенствованный алгоритм адаптивной балансировки нагрузки или если вы хотите нестандартный уровень безопасности.Давайте забудем о нестандартной безопасности, это редко хорошая идея, но адаптивное распределение нагрузки может быть желательным.Варианты 1-3 будут использовать циклический или взвешенный циклический или адаптивный циклический отбор на основе времени отклика, и они будут обнаруживать неотвечающие случаи.Варианты 1 и 3 предоставляют еще одну сложную для реализации функцию, а именно липкость сеанса HTTP, но она не обязательна для служб SOAP или REST
...