API网关正在经历身份危机

这些年来，API网关正在经历一些身份危机。

它们是否是集中的共享资源，以促进对外部实体的API公开和治理？
它们是集群入口哨兵，可以严格控制哪些用户流量进入或离开集群吗？
还是他们根据自己拥有的客户端类型，使用某种API结合胶来更简洁地表达API？
当然，房间里的大象和我经常听到的一个问题：“服务网格会使API网关过时吗？”

一些背景

随着技术的发展日新月异，以及整个行业通过技术和架构模式进行快速洗牌，您会被认为是“所有这些都使我旋转”。在本文中，我希望归纳出“ API网关”的不同身份，阐明组织中的哪些群体可以使用API网关（他们正在尝试解决的问题），并重新关注第一原理。理想情况下，到本文结尾，您将更好地了解API基础结构在不同级别上对不同团队的作用，以及如何从每个级别中获得最大价值。

在深入探讨之前，让我们非常清楚地了解API一词。

我对API的定义：

一个明确定义的目的明确的接口，旨在通过网络调用，该接口使软件开发人员能够以受控且舒适的方式对组织内的数据和功能进行编程访问。

这些接口抽象了实现它们的技术基础结构的细节。对于这些设计的网络端点，我们希望获得一定程度的文档，使用指南，稳定性和向后兼容性。

相反，仅因为我们可以通过网络与另一软件进行通信，并不一定意味着远程端点就是此定义的API。许多系统相互通信，但是通信更加随意发生，并且在耦合和其他因素的即时性之间进行权衡。

我们创建API来为业务的各个部分提供周到的抽象，以实现新的业务功能以及偶然的创新。

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

API管理

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

借助API Management ，我们正在寻求解决“何时我们希望公开现有的API供其他人使用”的问题，我们如何跟踪谁使用这些API，实施关于允许谁使用它们的策略，建立安全性流程以进行身份验证和授权许可使用，并建立可在设计时使用的服务目录，以促进API使用并为有效治理奠定基础。

我们要解决“我们拥有要与他人共享但要按我们的条款共享这些现有的，经过精心设计的API”的问题。

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

利用API网关的API管理软件示例：

Google Cloud Apigee
红帽3Scale
Mulesoft
Kong

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

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

需要注意的一件事：我们要小心，不允许任何业务逻辑进入这一层。如前一段所述，API管理是共享的基础结构，但是由于我们的API流量经过了它，因此它倾向于重新创建“全知全能”（认为是企业服务总线）治理门，必须所有人协调以更改我们的服务。从理论上讲，这听起来不错。在实践中，这最终可能成为组织瓶颈。有关更多信息，请参见这篇文章：具有ESB，API管理和Now…Service Mesh的应用程序网络功能？

集群入口

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

在这种环境下，我们可能会构建和维护多个群集来承载我们的应用程序，并且需要某种方式来访问这些群集中的应用程序和服务。以Kubernetes为例思考。我们可能使用Kubernetes Ingress控制器来允许访问Kubernetes集群（集群中的其他所有内容都无法从外部访问）。这样，我们就可以通过定义明确的入口点（例如域/虚拟主机，端口，协议等），严格控制哪些流量可以进入（甚至离开）我们的集群。等

在这个级别上，我们可能希望某种“入口网关”成为允许请求和消息进入群集的流量哨兵。在这个级别上，您的思考更多是“我的集群中有此服务，我需要集群外的人才能调用它”。这可能是服务（公开API），现有的整体组件，gRPC服务，缓存，消息队列，数据库等。有些人选择将其称为API网关，而其中有些人实际上可能会做更多比流量的入口/出口要大，但重点是在集群操作级别存在此级别的问题。随着我们倾向于部署更多集群（相对于一个单一的，高度多租户的集群），我们最终将拥有更多的入口点，并且需要这些入口点之间进行交互。

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

Envoy代理及其基础上的项目包括：
- 数据线大使
HAProxy
- 包括OpenShift的路由器
NGINX
特拉菲克

此级别的集群入口控制器由平台团队操作，但是，这部分基础架构通常与更分散的自助服务工作流相关联（正如您对云原生平台所期望的那样）。参见Weaveworks的好伙伴介绍的“ GitOps”工作流程

API网关模式

关于“ API网关”一词的另一种扩展是我在听到该术语时通常想到的扩展，它与API网关模式最相似。克里斯·理查森（Chris Richardson）在第8章的“微服务模式”一书中做了很好的介绍。可以在他的microservices.io网站上的API Gatway Pattern上找到更快速的浏览信息。简而言之，API-gateway模式是管理API，以使不同类别的消费者更好地使用。此策展涉及一个API间接级别。您可能会听到的另一个代表API网关模式的术语是“后端的后端”，其中“前端”可以是文字前端（UI），移动客户端，IoT客户端甚至其他服务/应用程序开发人员。

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

与上一节中的Ingress控制器不同，此API网关更接近开发人员的世界观，而不是集中在暴露给集群外使用的端口或服务上。这个“ API网关”也不同于我们管理现有API的API管理世界观。该API网关将对后端的调用混搭在一起，这些调用可能会暴露API，但也可能会与未描述为API的事物进行对话，例如对旧系统的RPC调用，协议与“ REST”的外观不符，例如被黑通过HTTP，gRPC，SOAP，GraphQL，websocket和消息队列的JSON。也可以调用这种类型的网关来进行消息级转换，复杂的路由，网络弹性/后备以及响应的聚合。

如果您熟悉REST API的Richardson Maturity模型，则将调用实现API网关模式的API网关来集成比1-3级实现更多的0级请求（及其之间的所有内容）。

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

此类API网关的示例包括：

Spring Cloud Gateway
格洛
Netflix Zuul
IBM-Strongloop回送/微网关

也可以使用更多通用的编程或集成语言/框架来构建此类网关，例如：

阿帕奇骆驼
Spring整合
Ballerina
Eclipse Vert.x
节点JS

由于这种类型的API网关与应用程序和服务的开发密切相关，我们希望开发人员能够参与帮助指定API网关公开的API，了解所涉及的任何mashup逻辑以及需求快速测试和更改此API基础结构的能力。我们还希望操作或SRE对API网关的安全性，弹性和可观察性配置有一些意见。这种级别的基础结构还必须适应不断发展的按需自助服务开发人员工作流。再次查看GitOps模型以获取更多信息。

启用服务网格

在云基础架构上运行服务体系结构的一部分包括难以在网络中构建正确级别的可观察性和控制。在解决此问题的先前迭代中，我们使用了应用程序库和有希望的开发人员治理来实现此目的。但是，在大规模和跨多种环境的情况下，服务网格技术的出现提供了更好的解决方案。服务网格通过透明地实现，为平台及其组成服务带来以下功能

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

精明的读者会认识到， API网关和服务网格在功能上似乎有所重叠。服务网格的目标是通过在L7透明地解决所有服务/应用程序的这些问题。换句话说，服务网格希望融合到服务中（实际上并没有被编码为服务的代码）。另一方面，API网关位于服务网格上方并与应用程序一起使用（L8？）。服务网格为服务，主机，端口，协议等（东西方流量）之间的请求流带来了价值。它们还可以提供基本的群集入口功能，以将某些功能引入南北交通。但是，这不应与API网关可以带来北/南通信量的功能（如在集群的北/南和应用程序或一组应用程序的北/南）相混淆。

Service Mesh和API网关在某些方面在功能上重叠，但是是互补的，因为它们位于不同的级别并解决不同的问题。理想的解决方案是将每个组件（API管理，API网关，服务网格）插入并播放到您的解决方案中，并根据需要在组件之间建立良好的边界（或在不需要时排除它们）。同样重要的是找到适合分散式开发人员和运营工作流程的这些工具的实现。即使这些不同组件的术语和标识存在混淆，我们也应该依靠基本原理，并了解这些组件在我们的体系结构中带来了价值，以及它们如何独立存在和互补并存。

我们很乐意为您服务！

也许有些人知道我非常热衷于帮助人们，尤其是在云，微服务，事件驱动的体系结构和服务网格领域。在我的公司Solo.io中，我们正在帮助组织消除混乱，并以适当的级别以及成功使用它们的步伐（如果需要，更重要的是，成功地）采用网关和服务网格之类的API技术。！）。我们正在建设的工具，如GLOO ，东张西望，并SuperGloo技术类似的顶部特使代理， GraphQL和Istio以帮助实现API网关和服务网格管理。请直接与我们联系（ @soloio_inc ， http : //solo.io ）或与我联系（ @christianposta ， blog ），以深入了解我们的愿景以及我们的技术如何为您的组织提供帮助。在接下来的系列博客中，我们将更深入地探讨API网关模式，多个集群的困难，多服务网格的困难等等！敬请关注！

还相关阅读：

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