观看 Azure Service Fabric 的 BUILD 会议视频后，我一直在想象它如何适合我们当前基于微服务的架构。然而，有一件事我并不完全确定如何解决 - API 网关/代理。
考虑一个不那么简单的微服务架构，其中有 N 个服务在公开 REST 端点的 Azure Service Fabric 中运行。在许多情况下，您希望将这些碎片 API 端点打包成单条目 API 供使用者使用，以避免它们直接连接到服务结构实例。 Azure Service Fabric 解决方案在各个方面似乎都非常完整，当我在 BUILD 会谈期间没有找到一种方法来简单地解决这个问题时，我有点想知道我是否错过了一些明显的东西。
服务如Vulcan旨在通过让服务注册它们想要路由到它们的路径来解决这个问题etcd https://coreos.com/etcd/。我猜测解决这个问题的一种方法可能是创建一个单独的有状态 Web 服务，其他服务可以向其注册，提供服务名称以及它们需要路由到它们的路径。然后，有状态 Web 服务可以根据其状态将流量路由到正确的实例。不过，这似乎并不完全理想，比如在删除应用程序时删除路由以及通常保持状态与集群中部署的服务同步。有没有人考虑过这个问题，或者有任何想法如何在 Azure Service Fabric 中解决这个问题？
执行此操作所需的服务注册/可发现性实际上已经存在。有一个称为命名服务的有状态系统服务，它基本上是服务实例及其正在侦听的端点的注册器。因此，当您启动一个服务（无论是无状态还是有状态）并在其上打开一些侦听器时，该地址就会在命名服务中注册。
现在您需要填写的部分是用户与之交互的“网关”。这不必是有状态的，因为命名服务管理有状态的部分。但是您必须想出一个适合您的寻址方案，然后它会将请求转发到正确的位置。基本上是这样的：
- 接收请求。
- 使用NS查找可以接受请求的服务。
- 将请求转发给它，并将响应转发给用户。
- 如果该服务不再存在，则返回 404。
一般来说，我们不喜欢规定任何有关服务如何相互通信的内容，但我们正在考虑如何将 HTTP 作为完整的内置解决方案来解决此问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
