使用Azure Service Fabric部署的微服务的API网关/代理模式 [英] API gateway/proxy pattern for microservices deployed using Azure Service Fabric

问题描述

在观看了Azure Service Fabric的BUILD会议视频之后，我离开了，想象这可能非常适合我们当前基于微服务的体系结构.但是，我不确定要如何解决的一件事-API网关/代理.

After watching the BUILD conference videos for Azure Service Fabric, I'm left imagining how this might be a good fit for our current microservice-based architecture. There is one thing I'm not entirely sure how I would go about solving, however - the API gateway/proxy.

考虑一个不那么简单的微服务体系结构，在该体系结构中，在暴露REST终结点的Azure Service Fabric中运行了N个服务.在许多情况下，您希望将这些碎片化的API端点打包为一个单一条目的API，供消费者使用，以避免让它们直接连接到服务结构实例. Azure Service Fabric解决方案在所有方面都看起来是如此完整，以至于我想知道是否在BUILD讨论中提到的功能之内没有找到一种简单地解决此问题的方法时，是否错过了一些明显的事情.

Consider a less-than-trivial microservice architecture where you have N number of services running within the Azure Service Fabric exposing REST endpoints. In many situations, you want to package these fragmented API endpoints up into a single-entry API for consumers to use, to avoid having them connecting to the service fabric-instances directly. The Azure Service Fabric solution seems so complete in every way that I'm sort of wondering if I missed something obvious when I don't see a way to trivially solve this within the capabilities mentioned during the BUILD talks.

像 Vulcan 这样的服务旨在通过让服务在

Services like Vulcan aim to solve this problem by having the services register the paths they want routed to them in etcd. I'm guessing one way of solving this may be to create a separate stateful web service that other services can register themselves with, providing service name and the paths they need routed to them. The stateful web service can then route traffic to the correct instance based on its state. This doesn't seem entirely ideal, though, with stuff like removing routes when applications are removed and generally keeping the state in sync with the services deployed within the cluster. Has anybody given this any thought, or have any ideas how one might go about solving this within Azure Service Fabric?

推荐答案

执行此操作所需的服务注册/发现能力实际上已经存在.有一个名为Naming Service的有状态系统服务，该服务基本上是服务实例和它们正在侦听的端点的注册器.因此，当您启动一个服务(无状态或有状态)并在其上打开一些侦听器时，该地址就会在命名服务中注册.

The service registration/discoverability you need to do this is actually already there. There's a stateful system service called the Naming Service, which is basically a registrar of service instances and the endpoints they're listening on. So when you start up a service - either stateless or stateful - and open some listener on it, the address gets registered with the Naming Service.

现在，您需要填写的部分是用户与之交互的网关".这不必是有状态的，因为命名服务管理有状态的部分.但是您必须提出一种适合您的寻址方案，然后它将请求转发到正确的位置.基本上是这样的:

Now the part you'd need to fill in is the "gateway" that users interact with. This doesn't have to be stateful because the Naming Service manages the stateful part. But you'd have to come up with an addressing scheme that works for you, and then it would just forward requests along to the right place. Basically something like this:

1. 接收请求.
2. 使用NS查找可以接受请求的服务.
3. 将请求转发给用户，并将响应返回给用户.
4. 如果该服务不再存在，则为404.

通常，我们不希望就您的服务如何相互通信作出任何规定，但是我们正在考虑将HTTP作为完整的内置解决方案来解决此问题的方法.

In general we don't like to dictate anything about how your services talk to each other, but we are thinking of ways to solve this problem for HTTP as a complete built-in solution.

这篇关于使用Azure Service Fabric部署的微服务的API网关/代理模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！