CTO问我，为什么需要API网关？

最近看到了一篇 API 网关的文章，介绍了其三种角色：API 管理、集群入口控制、API 网关模式，最后还讲了与服务网格的关系，通过此文可以更全面的理解 API 网关的作用。

图片来自 Pexels

这些年来，API 网关正在经历一些有关他们是否真的起到作用的质疑：

• 它们是否集中、共享了资源，从而促进了 API 对于外部调用的管理？

• 它们是否集群入口（ingress）的控制器，从而可以严格管理用户进入或离开集群吗？

• 或者它们是否某种 API 的链接器，从而让 API 在指定的客户端上更方便使用？

• 当然，房间里的大象和最常见的问题是：“服务网格会使 API 网关过时吗？

房间里的大象：英语习语，指的是一些虽然显而易见，但却由于可能造成尴尬、争执、触及敏感或禁忌等原因被人刻意忽视的事情。

一些背景

随着技术发展日新月异，整个行业通过技术和架构模式的推陈出新进行快速洗牌，如果你说“所有这些都使我头大”，也可以理解。

在本文中，我希望总结出“API 网关”的不同身份，阐明日常使用中，哪些群体可以使用 API 网关（或许一部人正碰到并在尝试解决这个问题），并再次强调那些基本原则。

理想情况下，在本文结束时，您将更好地了解 API 基础架构在不同层级、对不同对象的作用，同时明白如何从每个层级获得最大价值。

在深入探讨之前，让我们先明确 API 一词的含义。

我对 API 的定义：一个有着明确定义并且最终目的清晰的接口，通过网络调用，使软件开发人员能够方便安全的对目标数据和功能进行程序访问。

这些接口抽象了实现它们的技术架构细节。对于这些设计好了的网络节点，我们希望获得一定程度的使用指引、以及成熟的向下兼容性。

相反，如果仅仅是可以通过网络与另一软件进行交互，并不一定意味着那些远程节点就是符合此定义的 API。

许多系统相互交互，但是这些交互比较随意，并且因为系统之间耦合性和其他一些因素的关系，往往在即时性方面会受到影响。

我们创建 API 来为业务的各个部分提供完善的抽象服务，以实现新的业务功能以及偶然发现一两个创新之举。

在谈论 API 网关时，首先要提到的是 API 管理。

API 管理

许多人从 API 管理的角度考虑 API 网关。这是合理的。但是，让我们先快速看一下此类网关的功能。

通过 API 管理，我们尝试去解决“如何控制给其他人使用当前有的 API”的问题。

例如，如何跟踪谁在使用这些 API、对谁能使用这些 API 进行权限控制、建立一套完善的管理措施进行使用授权和认证，同时创建一个服务目录，可以在设计时使用，提升对 API 的理解并为以后的有效治理奠定基础。

我们想解决“我们有一些优秀的 API，并且我们希望别人来使用这些 API，但是希望他们按照我们的规则去使用”的问题。

API 管理当然也起到一些很好的用处，例如，它允许用户（潜在的 API 使用者）进行自助服务，签署不同的 API 使用计划（请考虑：在给定时间范围内，在指定价格点上，每个端点每个用户的调用次数）。

有能力完成这些管理功能的基础架构就是网关（API 流量所经过的）。在网关层，我们可以执行身份验证，速率限制，指标收集，其它策略执行等一系列操作。

API Management Gateway

基于 API 网关的 API 管理软件示例：

• Google Cloud Apigee

• Red Hat 3Scale

• Mulesoft

• Kong

在这个层级，我们考虑的是 API（如上定义）是如何最好地管理和允许对其进行访问。

我们没有考虑其他角度，例如服务器、主机、端口、容器甚至服务（这是另一个很难定义清楚的词）。

API 管理（以及它们相应的网关），通常会被严格把控，并作为一种“平台组件”、“一体化组件”和 API 的其他基础组件一起生效。

需要注意的一件事：我们要小心千万别让任何业务逻辑进入这一层。

如前一段所述，API 管理是共享的基础架构，但是由于我们的 API 流量经过了它，因此它倾向于重新创建“大包大揽的全能型”（认为是企业服务总线）网关，这会导致我们必须与之协调来更改我们的服务。

从理论上讲，这听起来不错。实际上，这最终可能成为组织的瓶颈。

有关更多信息，请参见这篇文章：具有 ESB，API 管理和 Now…Service Mesh 的应用程序网络功能？

https://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/

集群入口

为了构建和实现 API，我们将重点放在代码、数据、生产力框架等方面。

但是，要想使这些事情中的任何一个产生价值，就必须对其进行测试，部署到生产中并进行监控。

当我们开始部署到云平台时，我们开始考虑部署、容器、服务、主机、端口等，并构建可在此环境中运行的应用程序。

我们可能正在设计工作流（CI）和管道（CD），以利用云平台快速迁移、更改的特点，将其快速展示在客户面前等等。

在这种环境中，我们可能会构建和维护多个集群来承载我们的应用程序，并且需要某种方式直接来访问这些集群中的应用程序和服务。

以 Kubernetes 为例思考。我们可能会通过一个 Kubernetes 入口控制器来访问 Kubernetes 集群（集群中的其它所有内容都无法从外部访问）。

这样，我们就可以通过定义明确的规则（例如域/虚拟主机、端口、协议等），严格控制哪些内容可以进入（甚至离开）我们的集群。

在这个层级，我们可能希望某种“入口网关”成为允许请求和消息进入集群的流量监控人。

在这个层级，思考更多的是“我的集群中有此服务，我需要集群外的人能够调用它”。

这可能是服务（公开 API）、现有的整体组件、gRPC 服务，缓存、消息队列、数据库等。

有些人选择将其称为 API 网关，而且实际上可能会做比控制流量进/出而言更多的事情，但重点是这个层级的问题是属于集群操作级别的。

Cluster Ingress Gateway

这些类型的入口实现的示例包括如下：

Envoy Proxy 及其基础上的项目包括：

• Datawire Ambassador

• Solo.io Gloo

• Heptio Contour

基于其他反向代理/负载均衡器构建的其它组件：

• HAProxy

• OpenShift’s Router

• Nginx

• Traefik

• Kong

此层级的集群入口控制器由平台组件操作，但是，这部分基础架构通常与更加分布式、自助服务的工作流相关联（正如您对云平台所期望的那样）。

参见 The “GitOps” workflow as described by the good folks at Weaveworks：

https://www.weave.works/blog/gitops-operations-by-pull-request

API 网关模式

关于“ API 网关”一词的另一种扩展是我在听到该术语时通常想到的，它是与 API 网关模式最相似的。

Chris Richardson 在其“微服务模式”一书第 8 章很好地介绍了这种用法。简而言之，API 网关模式是针对不同类别的使用者来优化 API 的使用。

这个优化涉及一个 API 间接访问。您可能会听到另一个代表 API 网关模式的术语是“前端的后端”，其中“前端”可以是字符终端（UI）、移动客户端、IoT 客户端甚至其他服务/应用程序开发人员。

在 API 网关模式中，我们明显简化了对一组 API 的调用，以模拟针对特定用户、客户端或使用者的“应用程序”内聚 API。

回想一下，当我们使用微服务构建系统时，“应用程序”的概念就消失了。API 网关模式有助于恢复此概念。

这里的关键是 API 网关，一旦实现，它将成为客户端和应用程序的 API，并负责与任何后端 API 和其他应用程序网络节点（不满足上述 API 定义的节点）进行通信交互。

与上一节中的入口控制器不同，此 API 网关更接近开发人员的视角，而较少关注哪些端口或服务会公开以供集群外使用。

此“ API 网关”也不同于我们管理现有 API 的 API 管理视角。此 API 网关将对后端的调用聚合在一起。

这可能会公开 API，但也可能会涉及到一些 API 描述较少的东西，例如对旧系统的 RPC 调用，使用不符合“REST”的协议的调用（如通过 HTTP 但不使用JSON），gRPC，SOAP，GraphQL、WebSockets 和消息队列。

这种类型的网关也可用来进行消息级转换、复杂的路由、网络弹性/回退以及响应的聚合。

如果您熟悉 REST API 的 Richardson Maturity 模型，就会发现相比 Level 1–3，实现了 API 网关模式的 API 网关集成了更多的 Level 0 请求（及其之间的所有内容）。

这些类型的网关实现仍需要解决速率限制、身份验证/授权、电路断路、度量收集、流量路由等问题。

这些类型的网关可以在集群边缘用作集群入口控制器，也可以在集群内部用作应用程序网关。

API Gateway Pattern

此类 API 网关的示例包括：

• Spring Cloud Gateway

• Netflix Zuul

• IBM-Strongloop Loopback/Microgateway

也可以使用更通用的编程或集成语言/框架，例如：

• Apache Camel

• Spring Integration

• Ballerina.io

• Eclipse Vert.x

• NodeJS

由于这种类型的 API 网关与应用和服务的开发紧密相关，因此我们希望开发人员能够参与帮助指定 API 网关公开的 API，了解所涉及的任何聚合逻辑以及能够快速测试和更改此 API 基础架构的能力。

我们还希望运维人员或工程师对 API 网关的安全性、弹性和可观察性配置有一些想法。

这种层级的基础架构还必须适应不断发展的、按需的、自主服务开发人员的工作流。可以通过查看 GitOps 模型获取更多这方面信息。

进入服务网格（Service Mesh）

在云基础架构上运行服务架构的一部分难点是，如何在网络中构建正确级别的可观察性和控制。

在解决此问题的先前迭代中，我们使用了应用程序库和一些专业的开发人员治理来实现此目的。

但是，在大规模和多种开发语言环境下，服务网格技术的出现提供了更好的解决方案。

服务网格通过透明地实现为平台及其组成服务带来以下功能：

• 服务到服务（即东西向流量）的弹性。

• 安全性包括最终用户身份验证、相互 TLS、服务到服务 RBAC/ABAC。

• 黑盒服务的可观察性（专注于网络通信），例如请求/秒、请求延迟、请求失败、熔断事件、分布式跟踪等。

• 服务到服务速率限制，配额执行等。

精明的读者会认识到，API 网关和服务网格在功能上似乎有所重叠。服务网格的目的是通过在 L7 透明地解决所有服务/应用程序的这些问题。

换句话说，服务网格希望融合到服务中（实际上它的代码并没有嵌入到服务中）。

另一方面，API 网关位于服务网格之上，和应用程序一起（L8？）。服务网格为服务、主机、端口、协议等（东西向流量）之间的请求流带来了价值。

它们还可以提供基本的集群入口功能，以将某些此功能引入南北向。但是，这不应与 API 网关可以带来北/南流量的功能相混淆。（一个在集群的南北向和一个是在一组应用程序的南北向）

服务网格和 API 网关在某些方面在功能上重叠，但是在它们在不同层面互补，分别负责解决不同的问题。

理想的解决方案是将每个组件（API 管理、API 网关、服务网格）合适的安置到您的解决方案中，并根据需要在各组件间建立良好的边界（或在不需要时排除它们）。

同样重要的是找到适合的办法去分布式的处理这些组件，给到相应的开发人员和运营工作流。

即使这些不同组件的术语和标识存在混淆，我们也应该依靠基本原理，并了解这些组件在我们的体系结构中带来的价值，从而来确定它们如何独立存在和互补并存。