在观看了Azure Service Fabric的BUILD会议视频后，我想象一下这对于我们当前基于微服务的架构是否合适。有一件事我不太确定我将如何解决，但是 - API网关/代理。
考虑一个不那么简单的微服务架构，其中您在Azure Service Fabric中运行N个服务，从而暴露REST端点。在许多情况下，您希望将这些分散的API端点打包到单条目API中供消费者使用，以避免它们直接连接到服务结构实例。 Azure Service Fabric解决方案在各方面都看起来如此完整，我有点想知道当我在BUILD会谈期间提到的功能中没有看到一种简单解决这个问题的方法时我是否错过了一些明显的东西。
像Vulcan这样的服务旨在通过让服务在etcd中注册他们想要路由到它们的路径来解决这个问题。我猜测解决这个问题的一种方法可能是创建一个单独的有状态Web服务，其他服务可以自己注册，提供服务名称和路由到它们的路径。然后，有状态Web服务可以根据其状态将流量路由到正确的实例。但是，这似乎并不完全理想，例如删除应用程序时删除路由，以及通常使状态与群集中部署的服务保持同步。有没有人对此提出任何想法，或者有任何想法如何在Azure Service Fabric中解决这个问题？
您需要执行此操作的服务注册/可发现性实际上已存在。有一个称为命名服务的有状态系统服务，它基本上是服务实例的注册商和他们正在监听的端点。因此，当您启动服务（无状态或有状态）并在其上打开一些侦听器时，地址将在命名服务中注册。
现在，您需要填写的部分是用户与之交互的“网关”。这不必是有状态的，因为命名服务管理有状态部分。但是你必须提出一个适合你的寻址方案，然后它会将请求转发到正确的地方。基本上是这样的：
一般而言，我们不喜欢决定您的服务如何相互通信，但我们正在考虑如何将HTTP作为一个完整的内置解决方案来解决这个问题。
我们也为此目的实现了HTTP网关服务。为了确保我们可以为任何内部协议提供一个HTTP网关，我们使用ASP.NET 5中间件为基于HTTP的内部服务（如ASP.NET WebAPI）实现了网关。它通过使用ServicePartitionClient和CommunicationClientFactoryBase的一些重试逻辑将来自例如/ service的请求路由到fabric：/ myapp / myservice之类的内部Service Fabric地址。
我们开源这个中间件你可以在这里找到它：https://github.com/c3-ls/ServiceFabric-HttpServiceGateway
在项目的维基中还有一些文档。
此功能是为http端点构建的，从Service Fabric 5.0版开始。该文档可在https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reverseproxy/获得
Azure Service Fabric可以轻松实现此方案的标准体系结构：网关服务作为客户端连接的前端以及与前端网关通信的所有N个后端服务。作为Service Fabric的一部分，有一些通信API堆栈可以轻松地从客户端到服务以及服务本身之间进行通信。 Service Fabric提供的通信API堆栈隐藏了发现，连接和重试连接的详细信息，以便您可以专注于实际的信息交换。使用Service Fabric通信API时，服务不必实现将其名称和端点注册到特定路由服务的机制，除了创建服务本身的常规步骤之外。通信API接受服务URI和分区键，并自动解析并连接到正确的服务实例。 This article提供了一个很好的起点，可帮助您决定哪种通信API最适合您的特定情况，具体取决于您使用的是可靠的Actors还是可靠的服务，或HTTP或WCF等协议，还是编程选择写入服务的语言。在本文的最后，您将找到指向不同通信API的更详细文章和教程的链接。有关Web API服务中的通信的教程，请参阅this。
我们使用了一个名为Traefik的开源项目取得了惊人的成功。它周围有一个Azure Service Fabric包装器 - 它本质上是一个GoLang exe，它作为Managed Executable部署到集群上。
它支持断路器，加权循环LB，路径和标头版本路由（这对于托管多个API版本非常棒），列表还在继续。它有一个方便的门户网站来查看配置和健康状况。
它的真正力量在于你如何配置它。它是通过ServiceManifest.xml中的服务本身完成的。这允许您部署新服务并使它们能够立即路由到 - 无需更新路由表等。
例
<StatelessServiceType ServiceTypeName="WebServiceType">
<Extensions>
<Extension Name="Traefik">
<Labels xmlns="http://schemas.microsoft.com/2015/03/fabact-no-schema">
<Label Key="traefik.frontend.rule.example">PathPrefixStrip: /a/path/to/service</Label>
<Label Key="traefik.enable">true</Label>
<Label Key="traefik.frontend.passHostHeader">true</Label>
</Labels>
</Extension>
</Extensions>
</StatelessServiceType>
强烈推荐！
启动服务时，它会使用结构命名服务注册其端点。然后，您可以使用Fabric客户端API向Fabric询问已注册的端点，并将其与注册的服务名称相关联。
所以是的，正如您描述的情况一样，您将拥有一个接受传入URI进行连接的网关，然后使用该路径信息作为服务名称查找，然后在传入请求和实际内部之间创建代理连接端点位置。
看起来团队发布的样本显示了如何执行此操作：https://github.com/Azure/servicefabric-samples/tree/master/samples/Services/VS2015/WordCount
我想知道不要在N +服务中暴露Rest，而是在服务结构内部的任何地方使用默认的comm栈（或者尽可能地在内部保持简单）。仅在边缘入口点将REST暴露到结构中。使用std无状态Web 2.x api，它包装服务和角色的结构代理，和/或使用以相同方式暴露休息的结构服务。根据需要在前向休息服务中聚合您的api。我不确定我是否需要额外的聚合器开销来命名重定向（可能我错过了这个想法）。然后，这似乎只是组织（和保护）具有所需命名空间（即外观模式）的休息端点的练习。
我们正在使用具有网关模式的SF和网关后面的大约13个服务。我们使用SF提供的内置DNS服务，请参阅：https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-dnsservice，这允许内部服务使用已知（SF内部）DNS名称（包括内部服务的网关服务）来进行呼叫。有一些众所周知的asp.net核心网关（Ocelot，ProxyKit）可以使用，但我们推出了自己的。我们有一个外部负载均衡器可以路由到SF中的多个网关实例。