使用 Azure API 管理的 Service Fabric 概述

云应用程序通常都需要使用前端网关，为用户、设备或其他应用程序提供同一个入口点。 在 Service Fabric 中，网关可以是任何无状态服务，例如 ASP.NET 核心应用程序，也可以是用于流量入口的其他服务，例如 事件中心、 IoT 中心或 Azure API 管理。

本文介绍如何将 Azure API 管理用作 Service Fabric 应用程序的网关。 API 管理直接与 Service Fabric 集成，使你可以将 API 与一组丰富的路由规则发布到后端 Service Fabric 服务。

可用性

Architecture

常见的 Service Fabric 体系结构使用单页 Web 应用程序，该应用程序对公开 HTTP API 的后端服务进行 HTTP 调用。 Service Fabric 入门示例应用程序演示了此体系结构的示例。

在此方案中，无状态 Web 服务充当 Service Fabric 应用程序的网关。 此方法要求编写可将 HTTP 请求代理到后端服务的 Web 服务，如下图所示：

随着应用程序的复杂性的增长，必须在无数后端服务前提供 API 的网关也是如此。 Azure API 管理旨在通过路由规则、访问控制、速率限制、监视、事件日志记录和响应缓存来处理复杂的 API，同时在一定程度上只需少量工作。 Azure API 管理支持 Service Fabric 服务发现、分区解析和副本选择，以便将请求直接路由到 Service Fabric 中的后端服务，因此无需编写自己的无状态 API 网关。

在此方案中，Web UI 仍通过 Web 服务提供，而 HTTP API 调用通过 Azure API 管理进行管理和路由，如下图所示：

应用场景

Service Fabric 中的服务可以是无状态服务或有状态服务，并且可以使用以下三种方案之一进行分区：singleton、int-64 范围和命名。 服务终结点解析需要标识特定服务实例的特定分区。 解析服务的终结点时，必须指定服务实例名称（例如 fabric:/myapp/myservice），以及服务的特定分区，但单一实例分区除外。

Azure API 管理可与无状态服务、有状态服务和任何分区方案的任何组合一起使用。

将流量发送到无状态服务

最简单的情况是将流量转发到无状态服务实例。 为此，API 管理操作设有与 Service Fabric 后端特定无状态服务实例直接关联的入站处理策略。 发送到该服务的请求将发送到服务的随机实例。

示例

在以下方案中，Service Fabric 应用程序包含一个名为 fabric:/app/fooservice 公开内部 HTTP API 的无状态服务。 服务实例名称是众所周知的，可以直接在 API 管理入站处理策略中硬编码。

将流量发送到有状态服务

与无状态服务方案类似，流量可以转发到有状态服务实例。 在这种情况下，一个 API 管理操作包含一个具有 Service Fabric 后端的入站处理策略，用于将请求映射到特定 有状态 服务实例的特定分区。 要映射每个请求的分区是使用传入 HTTP 请求中的一些输入（例如 URL 路径中的值）通过 lambda 方法计算的。 可将策略配置为仅将请求发送到主副本，或将请求发送到随机副本进行读取作。

示例

在以下场景中，Service Fabric 应用程序包含一个名为fabric:/app/userservice的分区有状态服务，其公开了内部 HTTP API。 服务实例名称是众所周知的，可以直接在 API 管理入站处理策略中硬编码。

该服务使用 Int64 分区方案对服务进行分区，其中包含两个分区和一个跨越 Int64.MinValue 到 Int64.MaxValue的键范围。 后端策略通过将 URL 请求路径中提供的值转换为 id 64 位整数来计算该范围内的分区键，尽管此处可以使用任何算法来计算分区键。

将流量发送到多个无状态服务

在更高级的方案中，可以定义将请求映射到多个服务实例的 API 管理作。 在这种情况下，每个作都包含一个策略，该策略根据传入 HTTP 请求中的值（例如 URL 路径或查询字符串）以及有状态服务实例中的分区将请求映射到特定服务实例。

为此，API 管理操作包含一个入站处理策略，该策略具有一个 Service Fabric 后端，该后端根据从传入 HTTP 请求检索到的值映射到 Service Fabric 后端中的无状态服务实例。 向服务发出的请求将发送到服务的随机实例。

示例

在此示例中，将使用以下公式为应用程序的每个用户创建一个新的无状态服务实例，该实例具有动态生成的名称：

• fabric:/app/users/<username>

  每个服务都有唯一的名称，但名称在前期并不已知，因为服务是在响应用户或管理员输入时创建的，因此无法硬编码为 APIM 策略或路由规则。 而是从 name URL 请求路径中提供的值在后端策略定义中生成要向其发送请求的服务的名称。 例如：

  • /api/users/foo 的请求被路由到服务实例 fabric:/app/users/foo
  • 请求被路由到服务实例 /api/users/bar 的 fabric:/app/users/bar

将流量发送到多个有状态服务

与无状态服务示例类似，API 管理作可以将请求映射到多个 有状态 服务实例，在这种情况下，可能还需要为每个有状态服务实例执行分区解析。

为此，API 管理操作包含一个入站处理策略，该策略利用 Service Fabric 后端，该后端根据从传入 HTTP 请求中检索到的值映射到 Service Fabric 后端中的有状态服务实例。 除了将请求映射到特定服务实例外，还可以将请求映射到服务实例中的特定分区，还可以选择映射到分区中的主副本或随机次要副本。

示例

在此示例中，将使用以下公式为应用程序的每个用户创建一个新的有状态服务实例，该实例具有动态生成的名称：

• fabric:/app/users/<username>

  每个服务都有唯一的名称，但名称在前期并不已知，因为服务是在响应用户或管理员输入时创建的，因此无法硬编码为 APIM 策略或路由规则。 而是从 name 用于 URL 请求路径的值中，在后端策略定义中生成要发送请求的服务名称。 例如：

  • 要 /api/users/foo 路由到服务实例的请求 fabric:/app/users/foo
  • 请求被路由到服务实例 fabric:/app/users/bar 的 /api/users/bar

每个服务实例还使用 Int64 分区方案进行分区，其中包含两个分区，以及一个范围跨越 Int64.MinValue 到 Int64.MaxValue的键范围。 后端策略通过将 URL 请求路径中提供的值转换为 id 64 位整数来计算该范围内的分区键，尽管此处可以使用任何算法来计算分区键。

后续步骤

按照 本教程 作，使用 API 管理设置第一个 Service Fabric 群集，并通过 API 管理将请求流向服务。