【翻译】对于API网关的一些质疑和思考

翻译：Eolinker——国内流行的高效API网关
来源：Medium
这些年来，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的其余基础组件一块儿生效。
须要注意的一件事：咱们要当心千万别让任何业务逻辑进入这一层。
如前一段所述，API管理是共享的基础架构，可是因为咱们的API流量通过了它，所以它倾向于从新建立“大包大揽的全能型”（认为是企业服务总线）网关，这会致使咱们必须与之协调来更改咱们的服务。从理论上讲，这听起来不错。实际上，这最终可能成为组织的瓶颈。

# 集群入口
为了构建和实现API，咱们将重点放在代码、数据、生产力框架等方面。可是，要想使这些事情中的任何一个产生价值，就必须对其进行测试，部署到生产中并进行监控。当咱们开始部署到云平台时，咱们开始考虑部署、容器、服务、主机、端口等，并构建可在此环境中运行的应用程序。咱们可能正在设计工做流（CI）和管道（CD），以利用云平台快速迁移、更改的特色，将其快速展现在客户面前等等。
在这种环境中，咱们可能会构建和维护多个集群来承载咱们的应用程序，而且须要某种方式直接来访问这些集群中的应用程序和服务。以Kubernetes为例思考。咱们可能会经过一个Kubernetes 入口控制器来访问Kubernetes集群（集群中的其它全部内容都没法从外部访问）。这样，咱们就能够经过定义明确的规则（例如域/虚拟主机、端口、协议等），严格控制哪些内容能够进入（甚至离开）咱们的集群。
在这个层级，咱们可能但愿某种“入口网关”成为容许请求和消息进入集群的流量监控人。在这个层级，思考更多的是“个人集群中有此服务，我须要集群外的人可以调用它”。这多是服务（公开API）、现有的总体组件、gRPC服务，缓存、消息队列、数据库等。有些人选择将其称为API网关，并且实际上可能会作比控制流量进/出而言更多的事情，但重点是这个层级的问题是属于集群操做级别的。

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

# API网关模式
关于“ API网关”一词的另外一种扩展是我在听到该术语时一般想到的，它是与API网关模式最类似的。简而言之，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网关与应用和服务的开发紧密相关，所以咱们但愿开发人员可以参与帮助指定API网关公开的API，了解所涉及的任何聚合逻辑以及可以快速测试和更改此API基础架构的能力。咱们还但愿运维人员或工程师对API网关的安全性、弹性和可观察性配置有一些想法。这种层级的基础架构还必须适应不断发展的、按需的、自主服务开发人员的工做流。能够经过查看GitOps模型获取更多这方面信息。

# 进入服务网格(Service Mesh)
在云基础架构上运行服务架构的一部分难点是，如何在网络中构建正确级别的可观察性和控制。在解决此问题的先前迭代中，咱们使用了应用程序库和一些专业的开发人员治理来实现此目的。可是，在大规模和多种开发语言环境下，服务网格技术的出现提供了更好的解决方案。服务网格经过透明地实现为平台及其组成服务带来如下功能：
• 服务到服务（即东西向流量）的弹性
• 安全性包括最终用户身份验证、相互TLS、服务到服务RBAC / ABAC
• 黑盒服务的可观察性（专一于网络通讯），例如请求/秒、请求延迟、请求失败、熔断事件、分布式跟踪等
• 服务到服务速率限制，配额执行等
精明的读者会认识到，API网关和服务网格在功能上彷佛有所重叠。服务网格的目的是经过在L7透明地解决全部服务/应用程序的这些问题。换句话说，服务网格但愿融合到服务中（实际上它的代码并无嵌入到服务中）。另外一方面，API网关位于服务网格之上，和应用程序一块儿（L8？）。服务网格为服务、主机、端口、协议等（东西向流量）之间的请求流带来了价值。它们还能够提供基本的集群入口功能，以将某些此功能引入南北向。可是，这不该与API网关能够带来北/南流量的功能相混淆。（一个在集群的南北向和一个是在一组应用程序的南北向）
服务网格和API网关在某些方面在功能上重叠，可是在它们在不一样层面互补，分别负责解决不一样的问题。理想的解决方案是将每一个组件（API管理、API网关、服务网格）合适的安置到您的解决方案中，并根据须要在各组件间创建良好的边界（或在不须要时排除它们）。一样重要的是找到适合的办法去分布式的处理这些组件，给到相应的开发人员和运营工做流。即便这些不一样组件的术语和标识存在混淆，咱们也应该依靠基本原理，并了解这些组件在咱们的体系结构中带来的价值，从而来肯定它们如何独立存在和互补并存。