使用Azure Service Fabric部署微服务的API网关/代理模式

Question

使用Azure Service Fabric部署微服务的API网关/代理模式

33

观看了Azure Service Fabric的BUILD会议视频后，我想象这可能非常适合我们目前基于微服务的架构。然而，有一件事情我不太确定该如何解决 - API网关/代理。

考虑一个微不足道的微服务架构，其中您有N个在Azure Service Fabric中运行并暴露REST端点的服务。在许多情况下，您希望将这些碎片化的API端点打包到单个入口API中供消费者使用，以避免他们直接连接到服务织物实例。 Azure Service Fabric解决方案似乎在各个方面都非常完整，以至于我有点想知道是否存在一种显而易见的方式可以在BUILD演讲中提到的功能内轻松解决这个问题。

像Vulcan这样的服务旨在通过在etcd中注册要路由到它们的路径来解决此问题。我猜解决这个问题的一种方式可能是创建一个单独的有状态Web服务，其他服务可以向其注册，提供服务名称和需要路由到它们的路径。然后，有状态的Web服务可以根据其状态将流量路由到正确的实例。但是，这似乎并不完全理想，例如删除应用程序时删除路由以及通常将状态与集群中部署的服务保持同步等问题。有人考虑过这个问题吗？或者有任何想法如何在Azure Service Fabric中解决这个问题吗？

- Trond Nordheim

7个回答

19

为此，我们还实现了一个HTTP网关服务。为确保我们可以针对任何内部协议使用一个HTTP网关，我们使用了ASP.NET 5中间件来实现基于HTTP的内部服务（例如ASP.NET WebAPIs）的网关。通过使用ServicePartitionClient和一些重试逻辑从CommunicationClientFactoryBase，它将请求从例如/service路由到一个内部Service Fabric地址，例如fabric:/myapp/myservice。

我们开源了这个中间件，你可以在这里找到它: https://github.com/c3-ls/ServiceFabric-HttpServiceGateway 项目的维基上还有更多文档。

- Christian Weiss

在https上设置这个东西非常麻烦，我遇到了很多问题。你们有尝试在https上运行它吗？ - Alex Gordon

13

从服务织物（Service Fabric）5.0版本开始，该功能已经为HTTP端点内置。文档可在https://azure.microsoft.com/zh-cn/documentation/articles/service-fabric-reverseproxy/查看。

- dtriana

3

在大多数情况下，通过反向代理进行通信就足够了，只要您了解使用它的后果。您集群中暴露 HTTP 终端点的任何服务都可从外部客户端进行访问。您的 DevOps 团队很可能会发现这是不可接受的。 - FunksMaName

4

我们使用了一个名为Traefik的开源项目，取得了惊人的成功。它有一个Azure Service Fabric的包装器 - 实际上是一个GoLang可执行文件，部署到集群作为托管可执行文件。

它支持熔断器、加权轮询负载均衡、路径和标头版本路由（这对于托管多个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>

强烈推荐！

- KnowHoper

我也使用Traefik与Service Fabric。非常无缝！ - pixelTitan

3

Azure Service Fabric使得实现标准架构变得容易，这种架构包括一个网关服务作为客户端连接的前端和所有N个后端服务与前端网关通信。作为Service Fabric的一部分提供了几个通信API堆栈，使得从客户端到服务以及服务内部的通信变得容易。Service Fabric提供的通信API堆栈将发现、连接和重试连接的细节隐藏起来，使你可以专注于实际信息交换。当使用Service Fabric通信API时，服务不需要实现将其名称和端点注册到特定路由服务的机制，除非这些是创建服务本身的常规步骤。通信API接受服务URI和分区键，并自动解析并连接到正确的服务实例。该文章提供了一个良好的起点，以帮助您根据使用可靠Actor或可靠服务、协议如HTTP或WCF以及服务编写的编程语言的选择，在您特定情况下最适合的通信API是哪些。在文章的结尾，您将找到有关不同通信API的更详细的文章和教程的链接。有关Web API服务中通信的教程，请参见此处。

- Kunal Deep Singh - MSFT

2

我知道Service Fabric服务的通信监听器概念，以便与服务进行实际通信；我的想法是像“Service1”想要服务于/foo/*，“Service2”想要服务于/bar/*；然后在api.mydomain.com前面设置一个共享的API代理，将适当的URI代理到后端的适当服务中。编排这种类型的路由似乎需要一些工作，我的问题更多的是“Service Fabric会提供这样的功能吗，还是我需要自己动手实现？” - Trond Nordheim

另外，为了进一步澄清；我希望这种API代理能够在运行时发现哪些服务需要哪些路径（通过枚举Service Fabric集群中的服务，提取每个服务的元数据 - 或者让服务自己告诉代理它们想要路由到自己的路径）。当可能有数百个服务时，维护一些硬编码路由似乎是最麻烦的。 - Trond Nordheim

1

我们正在使用SF网关模式，并在网关后面使用约13个服务。我们使用SF提供的内置DNS服务，请参见：https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-dnsservice，这允许内部服务使用已知（对SF内部而言）的DNS名称进行服务调用，包括网关服务到内部服务的调用。有一些众所周知的asp.net核心网关（Ocelot，ProxyKit）可供使用，但我们自己开发了一个。我们有一个外部负载均衡器来路由到SF中的多个网关实例。

- Thomas P Morgan

0

当服务启动时，它会向 Fabric 命名服务注册其端点。使用 Fabric 客户端 API，您可以向 Fabric 查询已注册的服务名称及其关联的端点。

因此，正如您所描述的那样，您将拥有一个网关来接受连接的传入 URI，并将该路径信息用作服务名称查找，然后在传入请求和实际内部端点位置之间创建代理连接。

看起来团队已发布了一个示例，展示如何执行此操作：https://github.com/Azure/servicefabric-samples/tree/master/samples/Services/VS2015/WordCount

- Brad Merrill

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Vaclav Turecek · Accepted Answer

你需要做的服务注册/发现其实已经存在。有一个有状态的系统服务叫做命名服务，它基本上是服务实例和它们正在侦听的端点的注册机构。所以当你启动一个服务 - 无论是有状态还是无状态的 - 并在上面打开一些侦听器时，该地址就会在命名服务中注册。

现在你需要填写的部分是用户与之交互的“网关”。这不必是有状态的，因为命名服务管理有状态的部分。但是你需要想出适合自己的寻址方案，然后它就会将请求转发到正确的位置。基本上像这样：

接收请求。
使用命名服务找到可以处理请求的服务。
将请求转发到该服务并将响应返回给用户。
如果服务不存在，则返回404。

通常我们不希望指定服务彼此之间的交流方式，但是我们正在考虑在HTTP中解决这个问题的内置完整解决方案。