到底什么是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网关的API管理软件示例：


在这个层面上，我们考虑API是如何最好地管理和允许访问它们。我们没有考虑服务器，主机，端口，容器甚至服务。
API管理（以及它们相应的网关）通常实现为由“平台团队”，“集成团队”或其他API基础架构团队拥有的严格控制的共享基础架构。通常这样做是为了强制执行一定级别的治理，变更管理和策略。在某些情况下，即使这些基础架构集中部署和管理，它们也可能支持更分散的物理部署。例如，Kong的首席技术官Marco Palladino在评论中指出，Kong可以选择部署的组件来支持集中式或分散式模型。
有一点需要注意：我们要注意不要让任何业务逻辑进入这一层。如前一段所述，API管理是共享基础架构，但由于我们的API流量遍历它，它倾向于重新创建“全知全能”（像企业服务总线）治理门户，我们通过它必须全部协调以改变我们的服务。理论上这听起来很棒。实际上，这可能最终成为组织瓶颈。有关更多信息，请参阅此文章：使用ESB，API管理和现在的应用程序网络功能...服务网格？

集群入口
为了构建和实现API，我们专注于代码，数据，生产力框架等方面。但是，要为这些提供价值的东西，必须对它们进行测试，部署到生产中并进行监控。当我们开始部署到云原生平台时，我们开始考虑部署，容器，服务，主机，端口等，并构建我们的应用程序以在此环境中生活。我们可能正在制作工作流程（CI）和管道（CD），以利用云平台快速移动，进行更改，将其置于客户面前等等。
在这种环境中，我们可以构建和维护多个集群来托管我们的应用程序，并且需要某种方式来访问这些集群内的应用程序和服务。以Kubernetes为例。我们可以使用Kubernetes Ingress控制器来允许访问Kubernetes集群（集群中的其他所有内容都无法从外部访问）。通过这种方式，我们可以非常严格地控制流量可能进入（甚至离开）我们的群集，具有明确定义的入口点，如域/虚拟主机，端口，协议等。
在这个级别，我们可能希望某种“入口网关”成为允许请求和消息进入集群的流量哨兵。在这个级别，你在考虑“我在我的集​​群中有这项服务，我需要集群外部的人才能调用它”。这可能是一个服务（暴露API），现有的整体，gRPC服务，缓存，消息队列，数据库等。有些人选择将其称为API网关，其中一些可能实际上做得更多比流量入口/出口，但重点是群集操作级别存在此级别的问题。由于我们倾向于部署更多集群（相对于单个高度多租户集群），因此我们最终会有更多的入口点以及彼此交互的需求。
这些类型的入口实现的示例包括：


此级别的集群入口控制器由平台团队操作，但是这个基础架构通常与更分散的自助服务工作流程相关联（正如您期望从云原生平台那样）。请参阅Weaveworks的优秀人员所描述的“GitOps”工作流程

API网关模式​​​​​​​
API网关”这一术语的另一个扩展是我听到这个术语时通常会想到的是，而且是最接近的：API网关模式。Chris Richardson在第8章的“微服务模式”一书中做了很好的工作。我强烈建议将这本书和其他微服务模式教育用于本书。可以在他关于API Gatway Pattern的microservices.io网站上看到更快的游览简而言之，API网关模式是为了策划API，以便不同类别的消费者更好地使用它。此策展涉及API间接级别。您可能听到的代表API网关模式的另一个术语是“前端后端”，其中“前端”可以是文字前端（UI），移动客户端，物联网客户端，甚至是其他服务/应用程序开发人员。
在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模型，那么实现API网关模式的API网关将被要求集成更多的Level 0请求（以及介于两者之间的所有内容）而不是Level 1-3实现。
这些类型的网关实现仍然需要解决诸如速率限制，认证/授权，电路中断，度量收集，流量路由等之类的事情。这些类型的网关可以在群集的边缘用作群集入口控制器，也可以在群集的深处用作应用程序网关。
此类API网关的示例包括：


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

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

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

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

精明的读者会认识到，API网关和服务网格的功能似乎有些重叠。服务网格的目标是通过在L7上透明地解决任何服务/应用程序来解决这些问题。换句话说，服务网格希望融入服务（实际上没有被编码到服务的代码中）。另一方面，API网关位于服务网格和应用程序（L8？）上方。
服务网格为服务，主机，端口，协议等（东/西流量）之间的请求流带来价值。它们还可以提供基本的群集入口功能，以便为进/出流量带来一些此功能。但是，这不应与API网关可以为进/出流量带来的功能相混淆（如在群集的进/出和向应用程序或应用程序组的进/出）。
服务网格和API网关在某些领域的功能上重叠，但它们是互补的，因为它们生活在不同的层次并解决不同的问题。理想的解决方案是将每个组件（API Management，API Gateway，Service Mesh）即插即用，并在需要时在组件之间保持良好的界限（或者在不需要它们时将其排除）。
同样重要的是找到适合您的分散开发人员和运营工作流程的这些工具的实现。尽管这些不同组成部分的术语和身份存在混淆，但我们应该依赖于第一原则并理解我们的架构中这些组件在何处带来价值以及它们如何独立存在并共存互补性。