面向服务架构中的网关服务答案

【问题标题】：Gateway Service in Service-Oriented Architecture面向服务架构中的网关服务
【发布时间】：2011-07-04 01:28:48
【问题描述】：

我很喜欢实现我自己的单入口点“网关”，它可以做两件事。

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

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

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

【问题讨论】：

有许多硬件负载平衡器提供此功能。如果购买是一种选择，也许你应该考虑一下
谢谢。但是，与实现我自己完全控制的负载平衡相比，这样做有什么好处呢？我可以看到潜在的成本节约。还有什么吗？
大多数负载平衡器让您可以控制平衡的发生方式。优点是它们通常被很好地利用，具有庞大的使用基础和经过验证的性能，通常你的时间可以更好地花在其他事情上，而不是重新发明捕鼠器，这很可能不会有很多特征。如果您正在寻找一个简单的负载均衡器，一定要自己动手做，但是稍微高于正常水平的东西我会考虑已经构建的硬件或软件负载均衡器。

标签： service soa gateway entry-point

【解决方案1】：

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

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

【讨论】：

6.使用一个简单的开源软件平衡器，该平衡器可以使用您自己的 Java 代码轻松扩展，甚至可以嵌入到自己的程序中（例如膜路由器）。