面向服务架构中的网关服务
我热衷于实现我自己的单入口“网关”，它可以做两件事。
首先，它记录 SOA 服务器已处理了多少请求，并将下一个请求循环到最可用的服务器。完全控制负载平衡逻辑很有吸引力。
其次，这个“网关”将是我所有服务（包括安全服务）的唯一联络人。如果客户端发送用户名-密码组合，它将它们传递给安全服务，安全服务在成功验证时授予令牌。如果客户端发送令牌，网关将通过安全服务运行该令牌，并且如果符合要求，则将请求传递给其中一项业务服务。隐藏或封装除网关之外的所有服务似乎是可取的。
我的问题是：有什么理由说明这不是“正确的做事方式”？当已经有一个框架可以实现我上面描述的功能时，我是否要重新发明轮子？我的堆栈是.NET 和 WCF。
I'm enamoured with the idea of implementing my own single-entry-point "gateway" that does two things.
First, it records how many requests have been handled by SOA servers and cycles the next request to the most available server. Full control over load balancing logic is attractive.
Second, this "gateway" would be the single liaison to all my services, including security. If the client sends up a username-password combo, it passes them to the security service which grants a token on successful authentication. If the client sends up a token, the gateway runs this token by the security service and, if it's kosher, passes the request to one of the business services. Hiding or encapsulating all services besides the gateway seems desirable.
My questions are: Is there any reason why this would not be "the right way to do things"? Am I reinventing the wheel when there's already a framework that does what I've described above? My stack is .NET and WCF.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好问题，但我必须同意 sweetfa 的评论，在 99% 的情况下，现成的负载均衡器将是最好的选择。更详尽的选项列表：
Good question, but I have to agree with sweetfa's comment, in 99% of cases an off-the-shelf load balancer will be the best option. A more exhaustive list of options: