面向服务的体系结构中的网关服务

Question

我很痴迷于实现我自己的单入口点“网关”的想法，它做了两件事。

首先，它记录了SOA服务器处理了多少请求，并将下一个请求循环到最可用的服务器。完全控制负载平衡逻辑很有吸引力。

其次，这个“网关”将成为我所有服务的唯一联络人，包括安全性。如果客户端发送用户名 - 密码组合，它会将它们传递给安全服务，该服务在成功进行身份验证时授予令牌。如果客户端发送令牌，则网关会通过安全服务运行此令牌，如果是Kosher，则将请求传递给其中一个业务服务。隐藏或封装除网关之外的所有服务似乎是可取的。

我的问题是：有什么理由说这不是“正确的做事方式”吗？当我已经有一个框架完成我上面描述的内容时，我会重新发明轮子吗？我的堆栈是.NET和WCF。

Answer 1

很好的问题，但我必须同意sweetfa的评论，在99％的情况下，现成的负载均衡器将是最好的选择。更详尽的选项列表：

1. 硬件负载平衡器/网关（例如IBM XML Gateway） - 非常可扩展且昂贵
2. 服务总线软件（例如Oracle Service Bus）也将进行安全性和负载平衡 - 非常可配置且昂贵。可扩展性低于硬件解决方案
3. 开源负载均衡器软件（例如Apache HTTPD代理模块）将拥有大量用户，可以帮助您通过论坛进行设置。许多解决方案都具有相当大的可扩展性和稳健性，但与选项1和2相比，它具有更复杂的配置方式
4. 基于服务注册表（UDDI v3）的负载平衡，当服务使用者在每次调用时查找提供者URI时。注册表将通过返回不同的URI来平衡请求。此解决方案不会充当安全网关，消费者可能会完全忽略它
5. 构建您自己的，如果您需要一些高级自适应负载平衡算法或者您需要非标准安全层。让我们忘记非标准安全性，这很少是一个好主意，但自适应负载平衡是可取的。选项1-3将根据响应时间执行循环或加权循环或自适应循环，并且它们将检测无响应的实例。选项1和3提供了另一个难以实现的功能，即HTTP会话的粘性，但它不是SOAP或REST服务所必需的