1

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

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

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

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

4

1 回答 1

1

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

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