API管理也做得很好，它允许用户（潜在的API使用者）进行自助服务，签署不同的API使用计划（请考虑：在给定时间范围内，在指定价格点上，每个端点每个用户的调用次数）。有能力完成这些管理功能的基础架构就是网关（API流量所经过的）。在网关层，我们可以执行身份验证，速率限制，指标收集，其它策略执行等操作。

API Management Gateway

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

Google Cloud Apigee
Red Hat 3Scale
Mulesoft
Kong

在这个级别上，我们考虑的是API（如上定义）是如何最好地管理和允许对其进行访问。我们不是在考虑服务器，主机、端口、容器甚至服务（另一个定义不明确的词）。

API管理（以及它们相应的网关）通常被作为由“平台团队”、“集成团队”或其它API基础架构团队所拥有的、严格控制的共享基础架构。

需要注意的一件事：我们要小心，别让任何业务逻辑进入这一层。如前一段所述，API管理是共享的基础结构，但是由于我们的API流量经过了它，因此它倾向于重新创建“大包大揽的全能型”（认为是企业服务总线）网关，这会导致我们必须与之协调来更改我们的服务。

从理论上讲，这听起来不错。实际上，这最终可能成为组织的瓶颈。有关更多信息，请参见这篇文章：

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

集群入口

为了构建和实现API，我们将重点放在代码、数据、生产力框架等方面。但是，要想使这些事情中的任何一个产生价值，就必须对其进行测试，部署到生产中并进行监控。当我们开始部署到云原生平台时，我们开始考虑部署、容器、服务、主机、端口等，并构建可在此环境中运行的应用程序。我们可能正在设计工作流（CI）和管道（CD），以利用云平台快速迁移、更改、将其展示在客户面前等等。

在这种环境中，我们可能会构建和维护多个集群来承载我们的应用程序，并且需要某种方式来访问这些群集中的应用程序和服务。以Kubernetes为例思考。我们可能会通过Kubernetes Ingress来访问Kubernetes集群（集群中的其它所有内容都无法从外部访问）。

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

在这个级别上，我们可能希望某种“ingress网关”成为允许请求和消息进入群集的流量哨兵。在这个级别上，您的思考更多是“我的集群中有此服务，我需要集群外的人能够调用它”。

这可能是服务（公开API）、现有的整体组件、gRPC服务，缓存、消息队列、数据库等。有些人选择将其称为API网关，而且实际上可能会做比流量的入口/出口更多的事情，但重点是这个层级的问题是属于集群操作级别的。

Cluster Ingress Gateway

这些类型的ingress实现的示例包括：
Envoy Proxy 及其基础上的项目包括：

Datawire Ambassador
Solo.io Gloo
Heptio Contour

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

HAProxy
OpenShift’s Router (based on HAProxy)
NGINX
Traefik
Kong

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

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

API网关模式

关于“ API网关”一词的另一种扩展是我在听到该术语时通常想到的，它是与API网关模式最相似的。Chris Richardson在其“微服务模式”一书第8章很好地介绍了这种用法。

我强烈建议您将此书用于此模式和其他微服务模式学习资料。可在他的microservices.io网站API Gatway Pattern可以进行快速浏览。简而言之，API网关模式是针对不同类别的消费者来优化API的使用。

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

在API网关模式中，我们明显简化了一组API的调用，以模拟针对特定用户、客户端或使用者的“应用程序”内聚API。回想一下，当我们使用微服务构建系统时，“应用程序”的概念就消失了。API网关模式有助于恢复此概念。这里的关键是API网关，一旦实现，它将成为客户端和应用程序的API，并负责与任何后端API和其他应用程序网络端点（不满足上述API定义的端点）进行通信。

与上一节中的Ingress控制器不同，此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请求（及其之间的所有内容）。

https://martinfowler.com/articles/richardsonMaturityModel.html

这些类型的网关实现仍需要解决速率限制、身份验证/授权、断路、度量收集、流量路由等问题。这些类型的网关可以在集群边缘用作集群入口控制器，也可以在集群内部用作应用程序网关。

API Gateway Pattern

此类API网关的示例包括：

Spring Cloud Gateway
Solo.io Gloo
Netflix Zuul
IBM-Strongloop Loopback/Microgateway

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

Apache Camel
Spring Integration
Ballerina.io
Eclipse Vert.x
NodeJS

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

我们还希望运维人员或SRE对API网关的安全性、弹性和可观察性配置有一些意见。这种层级的基础架构还必须适应不断发展的、按需的、自助服务开发人员工作流。可以通过查看GitOps模型获取更多这方面信息。

进入服务网格(Service Mesh)

在云基础架构上运行服务架构的一部分难点是，如何在网络中构建正确级别的可观察性和控制。在解决此问题的先前迭代中，我们使用了应用程序库和希望的开发人员治理来实现此目的。

但是，在大规模和多种开发语言环境下，服务网格技术的出现提供了更好的解决方案。服务网格通过透明地实现为平台及其组成服务带来以下功能：

服务到服务（即东西向流量）的弹性
安全性包括最终用户身份验证、相互TLS、服务到服务RBAC / ABAC
黑盒服务的可观察性（专注于网络通信），例如请求/秒、请求延迟、请求失败、熔断事件、分布式跟踪等
服务到服务速率限制，配额执行等

精明的读者会认识到，API网关和服务网格在功能上似乎有所重叠。服务网格的目的是通过在L7透明地解决所有服务/应用程序的这些问题。换句话说，服务网格希望融合到服务中（实际上它的代码并没有嵌入到服务中）。

另一方面，API网关位于服务网格以及应用程序之上（L8？）。服务网格为服务、主机、端口、协议等（东西向流量）之间的请求流带来了价值。它们还可以提供基本的集群入口功能，以将某些此功能引入南北向。但是，这不应与API网关可以带来北/南流量的功能相混淆。（一个在集群的南北向和一个是在一组应用程序的南北向）

Service Mesh和API网关在某些方面在功能上重叠，但是在它们在不同层面互补，分别负责解决不同的问题。理想的解决方案是将每个组件（API管理、API网关、服务网格）合适的安置到您的解决方案中，并根据需要在各组件间建立良好的边界（或在不需要时排除它们）。

同样重要的是找到适合去中心化开发人员和运营工作流程的这些工具实现。即使这些不同组件的术语和标识存在混淆，我们也应该依靠基本原理，并了解这些组件在我们的体系结构中带来的价值，从而来确定它们如何独立存在和互补并存。