有关 Azure Service Fabric 与 API 管理的概述Service Fabric with Azure API Management overview

云应用程序通常都需要使用前端网关,为用户、设备或其他应用程序提供同一个入口点。Cloud applications typically need a front-end gateway to provide a single point of ingress for users, devices, or other applications. 在 Service Fabric 中,网关可以是任意无状态服务(如 ASP.NET Core 应用程序),也可以是其他专为流量入口设计的服务(如事件中心IoT 中心Azure API 管理)。In Service Fabric, a gateway can be any stateless service such as an ASP.NET Core application, or another service designed for traffic ingress, such as Event Hubs, IoT Hub, or Azure API Management.

本文介绍了如何将 Azure API 管理用作 Service Fabric 应用程序的网关。This article is an introduction to using Azure API Management as a gateway to your Service Fabric applications. API 管理直接与 Service Fabric 集成,以便可以使用一组丰富的路由规则向后端 Service Fabric 服务发布 API。API Management integrates directly with Service Fabric, allowing you to publish APIs with a rich set of routing rules to your back-end Service Fabric services.

可用性Availability

重要

由于所需的虚拟网络支持,此功能在 API 管理的高级开发人员层中可用。This feature is available in the Premium and Developer tiers of API Management due to the required virtual network support.

体系结构Architecture

常见 Service Fabric 体系结构使用单页 Web 应用程序,向公开 HTTP API 的后端服务发出 HTTP 调用。A common Service Fabric architecture uses a single-page web application that makes HTTP calls to back-end services that expose HTTP APIs. Service Fabric 入门示例应用程序展示了此体系结构示例。The Service Fabric getting-started sample application shows an example of this architecture.

在此方案中,无状态 Web 服务用作 Service Fabric 应用程序的网关。In this scenario, a stateless web service serves as the gateway into the Service Fabric application. 使用这种方法,需要编写可以将 HTTP 请求代理到后端服务的 Web 服务,如下图所示:This approach requires you to write a web service that can proxy HTTP requests to back-end services, as shown in the following diagram:

有关 Service Fabric 与 Azure API 管理的概述 - 拓扑

随着应用程序越来越复杂,必须向大量后端服务呈现 API 的网关亦是如此。As applications grow in complexity, so do the gateways that must present an API in front of myriad back-end services. Azure API 管理旨在通过路由规则、访问控制、速率限制、监视、事件日志记录和响应缓存来处理复杂 API,最大限度地减少用户需要执行的操作。Azure API Management is designed to handle complex APIs with routing rules, access control, rate limiting, monitoring, event logging, and response caching with minimal work on your part. Azure API 管理支持 Service Fabric 服务发现、分区解析和副本选择,从而智能地将请求直接路由到 Service Fabric 中的后端服务,用户无需编写自己的无状态 API 网关。Azure API Management supports Service Fabric service discovery, partition resolution, and replica selection to intelligently route requests directly to back-end services in Service Fabric so you don't have to write your own stateless API gateway.

在此方案中,仍通过 Web 服务为 Web UI 提供服务,同时通过 Azure API 管理来托管和路由 HTTP API 调用,如下图所示:In this scenario, the web UI is still served through a web service, while HTTP API calls are managed and routed through Azure API Management, as shown in the following diagram:

有关 Service Fabric 与 Azure API 管理的概述 - 拓扑

应用程序方案Application scenarios

Service Fabric 中的服务可以是无状态服务,也可以是有状态服务,可采用以下三种方案之一进行分区:单独分区、Int64 范围分区和已命名分区。Services in Service Fabric may be either stateless or stateful, and they may be partitioned using one of three schemes: singleton, int-64 range, and named. 必须确定特定服务实例的具体分区,才能解析服务终结点。Service endpoint resolution requires identifying a specific partition of a specific service instance. 解析服务终结点时,必须指定服务实例名称(例如,fabric:/myapp/myservice)以及服务的具体分区,但单独分区情况除外。When resolving an endpoint of a service, both the service instance name (for example, fabric:/myapp/myservice) as well as the specific partition of the service must be specified, except in the case of singleton partition.

Azure API 管理可与无状态服务、有状态服务和任何分区方案的任意组合配合使用。Azure API Management can be used with any combination of stateless services, stateful services, and any partitioning scheme.

将流量发送到无状态服务Send traffic to a stateless service

最简单的情况是将流量转发到无状态服务实例。In the simplest case, traffic is forwarded to a stateless service instance. 为此,API 管理操作包含使用 Service Fabric 后端的入站处理策略,用于将请求映射到 Service Fabric 后端中的特定无状态服务实例。To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a specific stateless service instance in the Service Fabric back-end. 发送到该服务的请求将发送到该服务的随机实例。Requests sent to that service are sent to a random instance of the service.

示例Example

在以下方案中,Service Fabric 应用程序包含名为“fabric:/app/fooservice”的无状态服务,用于公开内部 HTTP API。In the following scenario, a Service Fabric application contains a stateless service named fabric:/app/fooservice, that exposes an internal HTTP API. 服务实例名称已知,并可直接在 API 管理入站处理策略中进行硬编码。The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy.

有关 Service Fabric 与 Azure API 管理的概述 - 拓扑

将流量发送到有状态服务Send traffic to a stateful service

与无状态服务方案类似,流量可以转发到有状态服务实例。Similar to the stateless service scenario, traffic can be forwarded to a stateful service instance. 在此示例中,API 管理操作包含使用 Service Fabric 后端的入站处理策略,用于将请求映射到特定有状态服务实例 的特定分区。In this case, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps a request to a specific partition of a specific stateful service instance. 每个请求映射到的分区是通过 lambda 方法并根据传入 HTTP 请求中的一些输入(如 URL 路径中的值)计算得出。The partition to map each request to is computed via a lambda method using some input from the incoming HTTP request, such as a value in the URL path. 可以将策略配置为仅将请求发送到主要副本,也可以配置为发送到读取操作的随机副本。The policy may be configured to send requests to the primary replica only, or to a random replica for read operations.

示例Example

在以下方案中,Service Fabric 应用程序包含名为“fabric:/app/userservice”的已分区有状态服务,用于公开内部 HTTP API。In the following scenario, a Service Fabric application contains a partitioned stateful service named fabric:/app/userservice that exposes an internal HTTP API. 服务实例名称已知,并可直接在 API 管理入站处理策略中进行硬编码。The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy.

服务通过 Int64 分区方案分为两个分区,键范围介于 Int64.MinValueInt64.MaxValue 之间。The service is partitioned using the Int64 partition scheme with two partitions and a key range that spans Int64.MinValue to Int64.MaxValue. 后端策略将 URL 请求路径中的 id 值转换为 64 位整数,在此范围内计算分区键,尽管可以使用任何算法来计算分区键。The back-end policy computes a partition key within that range by converting the id value provided in the URL request path to a 64-bit integer, although any algorithm can be used here to compute the partition key.

有关 Service Fabric 与 Azure API 管理的概述 - 拓扑

将流量发送到多个无状态服务Send traffic to multiple stateless services

在更高级方案中,可以定义 API 管理操作,将请求映射到多个服务实例。In more advanced scenarios, you can define an API Management operation that maps requests to more than one service instance. 在此方案中,每个操作均包含一个策略,用于根据传入 HTTP 请求中的值(如 URL 路径或查询字符串),将请求映射到特定服务实例(如果是有状态服务,则将请求映射到服务实例中的分区)。In this case, each operation contains a policy that maps requests to a specific service instance based on values from the incoming HTTP request, such as the URL path or query string, and in the case of stateful services, a partition within the service instance.

为此,API 管理操作包含使用 Service Fabric 后端的入站处理策略,用于根据从传入 HTTP 请求中检索到的值,将请求映射到 Service Fabric 后端中的无状态服务实例。To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a stateless service instance in the Service Fabric back-end based on values retrieved from the incoming HTTP request. 对服务的请求将发送到该服务的随机实例。Requests to a service are sent to a random instance of the service.

示例Example

在此示例中,使用以下公式为应用的每个用户新建一个无状态服务实例,名称动态生成:In this example, a new stateless service instance is created for each user of an application with a dynamically generated name using the following formula:

  • fabric:/app/users/<username>

    每个服务都有一个独一无二的名称,但这些名称并不是提前已知,因为服务是根据用户或管理员输入创建而成,无法硬编码到 APIM 策略或路由规则中。Each service has a unique name, but the names are not known up-front because the services are created in response to user or admin input and thus cannot be hard-coded into APIM policies or routing rules. 相反,向其发送请求的服务的名称是根据 URL 请求路径中的 name 值在后端策略定义中生成。Instead, the name of the service to which to send a request is generated in the back-end policy definition from the name value provided in the URL request path. 例如:For example:

    • /api/users/foo 发出的请求被路由到服务实例 fabric:/app/users/fooA request to /api/users/foo is routed to service instance fabric:/app/users/foo
    • /api/users/bar 发出的请求被路由到服务实例 fabric:/app/users/barA request to /api/users/bar is routed to service instance fabric:/app/users/bar

有关 Service Fabric 与 Azure API 管理的概述 - 拓扑

将流量发送到多个有状态服务Send traffic to multiple stateful services

与无状态服务示例类似,API 管理操作可以将请求映射到多个有状态 服务实例。在此方案中,可能还需要对每个有状态服务实例执行分区解析。Similar to the stateless service example, an API Management operation can map requests to more than one stateful service instance, in which case you also may need to perform partition resolution for each stateful service instance.

为此,API 管理操作包含使用 Service Fabric 后端的入站处理策略,用于根据从传入 HTTP 请求中检索到的值,将请求映射到 Service Fabric 后端中的有状态服务实例。To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a stateful service instance in the Service Fabric back-end based on values retrieved from the incoming HTTP request. 除了可以映射到特定服务实例外,还可以将请求映射到服务实例中的特定分区,并视需要映射到分区内的主要副本或随机次要副本。In addition to mapping a request to specific service instance, the request can also be mapped to a specific partition within the service instance, and optionally to either the primary replica or a random secondary replica within the partition.

示例Example

在此示例中,使用以下公式为应用的每个用户新建一个有状态服务实例,名称动态生成:In this example, a new stateful service instance is created for each user of the application with a dynamically generated name using the following formula:

  • fabric:/app/users/<username>

    每个服务都有一个独一无二的名称,但这些名称并不是提前已知,因为服务是根据用户或管理员输入创建而成,无法硬编码到 APIM 策略或路由规则中。Each service has a unique name, but the names are not known up-front because the services are created in response to user or admin input and thus cannot be hard-coded into APIM policies or routing rules. 相反,向其发送请求的服务的名称是根据 URL 请求路径中的 name 值在后端策略定义中生成。Instead, the name of the service to which to send a request is generated in the back-end policy definition from the name value provided the URL request path. 例如:For example:

    • /api/users/foo 发出的请求被路由到服务实例 fabric:/app/users/fooA request to /api/users/foo is routed to service instance fabric:/app/users/foo
    • /api/users/bar 发出的请求被路由到服务实例 fabric:/app/users/barA request to /api/users/bar is routed to service instance fabric:/app/users/bar

每个服务实例同样通过 Int64 分区方案分为两个分区,键范围介于 Int64.MinValueInt64.MaxValue 之间。Each service instance is also partitioned using the Int64 partition scheme with two partitions and a key range that spans Int64.MinValue to Int64.MaxValue. 后端策略将 URL 请求路径中的 id 值转换为 64 位整数,在此范围内计算分区键,尽管可以使用任何算法来计算分区键。The back-end policy computes a partition key within that range by converting the id value provided in the URL request path to a 64-bit integer, although any algorithm can be used here to compute the partition key.

有关 Service Fabric 与 Azure API 管理的概述 - 拓扑

后续步骤Next steps

按照教程操作,使用 API 管理创建首个 Service Fabric 群集,并通过 API 管理向服务发送请求。Follow the tutorial to set up your first Service Fabric cluster with API Management and flow requests through API Management to your services.