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

Question

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

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

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

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

Answer 1

Хороший вопрос, но я должен согласиться с комментарием 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.