API网关与服务网格的区别

By Marco Palladino Feb 26, 2020

为何称API管理和服务网格是不同应用场景的互补模式

备注：本文的目标是提供一个备忘便签，指导架构师决定何时使用API网关，何时使用服务网格。如果你想直接进入“备忘便签”部分，请跳到最后。

多年来，采用API管理(APIM)以及API网关是数据中心内外部现代API用例的主要实现技术。API网关技术在过去十年中有了很大的发展，在业界所谓的“全生命周期API管理”中适用了更大、更全的应用环境。不仅在网络请求的数据平面提供连接,保护和管理API流量的运行时，同时还在更广泛的上下文中提供一系列的功能，如创建、测试、文档、计费、监测和API整体暴露等。在请求从开始到结束的过程中，API网关还在寻求更广泛的应用。换而言之，不仅仅是公开和使用API (RESTful或非RESTful)时的网络运行时管理，API网关在力争以产品的形式向用户和客户提供API创建到服务提供的完整生命周期能力。

然后在2017年前后，行业内出现了另一种模式:服务网格。几乎在同时，业界都无法理解这种模式如何与API网关模式相互协同，导致了很大的混乱。这在一定程度上是由于现有APIM提供商完全没有思想领导力，他们没能对服务网格如何补充到现有APIM应用场景中做出充分的响应。也有部分原因是由于服务网格被云服务供应商(首先是谷歌,其次是亚马逊,最后是微软) 推向了更广泛的行业应用场景。在此过程中,这种新模式的市场影响力超出了实际主流用户的应用,因此在业界形成了一个误解：服务网格是软件开发商的营销口号，而非技术实现。使得它几乎成为了每个人都在谈论但很少人掌握的神秘模型。

随着时间的推移，服务网格的技术实现慢慢追上了它的最初设想，越来越多的用户实现了该模式并讲述他们的案例故事。这使我们可以从服务网格的视角更加客观地理解服务网格和API网关(和APIM)的定义和区别。业界已经有人尝试着描述API网关和服务网格之间的区别，他们通常认为API网关用于南北向通信，而服务网格用于东西向通信。但我认为这种理解并不准确，它在根本上误解了这2种模式。在本文中，我将阐述API网关和服务网格之间的区别，以及用一种务实和客观的方式来决定在何时使用这2种模式。

API网关

API网关模式被描述为网络中的一个额外端点，每个请求都必须经过这个端点才能使用底层的API。因此有人认为API网关是集中式部署模式。

API网关位于每个API请求的执行路径上，它属于数据平面，接收来自客户端的请求，将请求反向代理到底层API，并在此之前执行流量控制和用户策略。在将请求代理回原始客户端之前，它还可以响应底层API的指令，再次执行相应的策略。

API网关可包括一个内置的控制平面来管理和配置数据平面的工作。网关支持将数据平面和控制平面绑定到同一个进程中，但具有单独的控制平面显然会更好一些。有些API网关与DP + CP绑定在同一进程中，随着已有的CI / CD管道执行情况的变化，所关联部署API网关的节点数量通常具备弹性扩展和更新的能力，这种架构取得了不错的应用效果。

API网关部署在它自己的实例中(自有的VM、主机或pod)，独立于客户端和API。由于完全独立于系统的其它模块运行，API网关部署非常简单。

API网关通常覆盖API的3种主要应用场景，适用于内部和外部服务连接，数据中心外部的南北向通信和数据中心内部的东西向通信。

第一种情况是将API打包成产品，供其他的开发人员、合作伙伴或其他团队调用消费。客户端应用从企业外部(如移动应用)或企业内部(如其他产品，其他团队开发或其他的产品线)发起请求。但无论哪种方式，客户端应用都运行在所调用开放API产品的范围之外。

当我们将API打包成产品来开放时，API网关将对来自客户端到API服务之间的请求，提供通用功能的封装和管理。这些功能包括AuthN/AuthZ认证、速率限制、在线开发、计费或客户端应用治理等。这些由L7层用户策略实现的高级功能，已经超越了底层协议的管理范围，将决定用户如何使用API产品。

API网关开放的大多数API运行是以HTTP协议为主。根据客户端应用所处在数据中心内部或外部的位置，请求的流量即可以是南北向，也可以是东西向的。通常情况下，外部的移动应用到API网关的流量是南北向，而组织内相同数据中心的其他产品到API网关的流程基本是东西向流量。从这个角度看，其实流量的方向根本无关紧要。

API网关还具备抽象层的用途，允许我们随时更改底层API，而不必更新对应的的客户端。对于那些由外部开发人员构建的客户端应用，每次决定更新API时，都不太能强制要求对方更新到最稳定或最新的API接口，在这种情况下，可以使用API网关来保持与客户端应用的向后兼容性，可以随时调整底层的API，抽象层的优势自然就非常明显。

2.服务连接性

第二个应用场景是客户端到API网关，API网关到底层API之间流量的网络策略执行策略包括连接、保护、加密、保护和监控等。因为对底层网络流量进行操作，而不是控制用户体验，因此被称为L7层流量策略。

API网关收到并处理某个请求后，网关本身会向底层API发送请求以获得对请求的响应(网关本质就是反向代理)。通常我们倾向于采用双向TLS来保护请求，记录请求，并全面保护和监控网络通信。网关还充当负载均衡器的角色，提供HTTP路由、支持将请求分发到不同版本API(支持蓝/绿和金丝雀部署的使用场景)，以及故障注入等功能。

API网关并不关心底层API的构建和接口暴露，因此无论是单体架构或微服务架构的系统都可以通过API网关开放底层API。大多数的API接口都是基于HTTP协议，如REST、SOAP、GraphQL或gRPC等。

3.API全生命周期管理

关于API网关的第三种应用场景是API的全生命周期管理。

我们都知道，运行时状态下，管理API、用户、客户端应用以及接口流量只是成功运行一个API所需涉及众多步骤的一部分而已。其他的部分还包括API接口的创建、记录、测试和模拟等。API运行起来后，还必须监视和观察，以检测是否存在异常情况。此外，将API以产品的方式对外提供时，还必须为最终用户提供门户来注册应用、获取身份凭据和消费API等等。

基于端到端的过程，API生命周期中的各个环节相互交织的（准确讲是不同角色负责不同的节点)经验看,上述内容可称为全生命周期的API管理。大多数高效的APIM解决方案都会提供一个解决方案集，通过一个或多个产品落实每个概念环节,从而全面实现API网关上的策略执行。

服务网格

我们所运行系统，在包含两个及以上的服务环境下，服务网格从根本上为我们展示了构建服务到服务的连接性模式。每当一个服务希望向另外的服务发送如读写数据库或微服务间访问的请求时，我们都希望能让这些请求更安全、更可观察等等。

服务网格作为一种模式可以应用于包括单体架构或微服务在内的任何架构和包括虚拟机，容器，Kubernetes在内的任何平台。

服务网格在网络请求管理上，其实并没有引入新的技术应用，但它把我们之前已经采用的方法应用得更好。甚至在采用服务网格模式之前，有些开发团队就已经在应用程序中实现了诸如安全性、可观察性和错误处理等流量策略。他们可以通过在服务中编写额外的代码来实现这些策略，从而加固应用所收发的任何出站或入站网络请求的连接性。但这也意味着不同的开发团队要采用各自的编程语言重复造轮子，并因此创建额外的模块和带来管理安全风险。

在服务网格之前，开发人员需编写代码和维护管理到第三方服务的网络连接，为支持对端不同的语言/框架而采用不同的实现方法。

在服务网格模式里, 我们将任何入站或出站请求的网络管理，不管是我们创建的，还是第3方创建我们部署的，都剥离出去，交给独立的应用代理处理。由于应用代理是独立部署的，因此，它默认就具备便携性和应用无关性，能够支持不同开发语言/框架的服务。代理运行在每个请求的执行路径上，属于数据平面处理过程。鉴于端到端mTLS加密和可观察性的情况,服务网格设计为每个服务伴随部署一个代理实例，来无缝地满足这些需求特性，而无需应用开发团队自己做特例处理。

由于这个数据平面级代理与服务的每个副本一起运行。因此有人将服务网格称为去中心化部署(对应集中式部署的API网关)。此外，由于代理在网络中增加了额外的跃点，为了能保持最小的网络延迟，需要与服务部署在相同的机器上(如VM、主机、pod)。理想情况下，如果代理的优势应用得当，延迟足够低，那么在管理服务间的网络连接方面，大家就会倾向于使用代理，而不是自有组件。

由于为服务的每个副本都运行一个应用代理实例，所以应用代理扮演了出站请求代理和入站请求反向代理的双重角色。也因此在系统中运行着许多代理。为了对它们进行配置管理，就需要一个控制平面作为执行配置和动作执行的可信源，并能够动态地对代理做配置广播。且控制平面只能连接代理，所以它不能处于服务间请求的执行路径上。

服务网格模式比API网关模式更具侵入性。因为它要求在数据平面为每个服务实例伴随部署一个代理，在部署应用程序时需大量更新CI/CD作业。虽然服务网格还有其他的部署模式，但是每个服务副本一个代理的模式被认为是行业标准，因为它保证了最好的、最高的可用性，并允许我们为每个服务的每个副本分配唯一的身份凭证(mTLS证书)。

综上所述，我们通过使用服务网格，在根本上解决了服务间调用的主要问题。

服务连接性

通过将网络管理剥离给第三方代理应用程序，免去了开发团队在自有服务内实现网络管理的开发量。代理可以为我们部署的每个服务、工作负载、数据库及第三方服务提供双向TLS加密、凭证、路由、日志记录、跟踪、负载平衡等功能。

由于组织内的服务连接运行了大量的协议类型，因此理想情况下，一个完整的服务网格不仅支持HTTP协议，还需支持其他任意的TCP流量，无论它是南北向还是东西向的流量。因此服务网格需支持更广泛的服务，并实现L4/L7流量策略，而API网关向来只是关注L7层策略。

从概念上看，对于系统中运行的工作负载，服务网格具有一个非常简单的视图:任何对象都是一个服务，且服务之间可以相互通信。因为API网关也是接收请求和发出请求的服务，所以API网关也可称为是网格中的一个服务。

因为每个服务的每个副本都需要一个与之相伴的数据平面代理，且这个数据平面代理是一个非常有效的客户端负载均衡,他们将出站请求路由到其他代理。服务网格的控制平面必须知道每个代理的地址,以便可以执行L4 /L7层的请求路由功能，代理地址还可以与服务名之类的任何元数据相关联。通过这样做，服务网格原生内置了一个服务发现工具，而无需借助第三方解决方案。服务发现 工具 还可以用于与网格外部进行通信，但通常不会用于指向网格内部的通信。

API 网关 vs. 服务网格

通过使用场景，可以清楚地发现API网关和服务网格在服务连接性的应用区域是重叠的。

服务网格提供的服务连接性功能与API网关提供的API连接性功能相冲突。但服务网格提供的服务更具有包容性，覆盖了L4 和 L7层，支持所有的TCP流量，包涵且不限于HTTP协议和API类型等，所以它在某种程度上更为完整。然而，正如我们从上图表中可以看到的，服务网格也有不具备的能力，即API网关模式的“产品形态API”和API全生命周期管理。

由于服务网格为更广泛的使用场景(L4+L7)满足了所有的服务连接性需求，所以。我们很自然地会认为它将在这个领域取代仅支持L7层的API网关。这个结论有效的前提是我们能够利用好服务网格部署模型。恰如我们所探讨的内容，但情况并不总是如此。

这两种模式之间的一个主要不同点实际上是部署模型:在服务网格模式中，我们必须在每个服务的每个副本旁边部署一个数据平面代理。当团队想要在自己的产品范围内或者自己的业务范围内部署服务网格时，这很容易做到，但是当我们想要在这个范围之外部署代理时，实现起来就会困难很多，原因有如下四点:

1. 将应用代理部署到组织中每个产品的每个服务旁边可能会遇到阻力，因为不同的产品、团队和业务线可能在应用构建、运行和部署存在根本上的差异。
2. 每个数据平面代理须发起一个到控制平面的请求,这在某些情况下,是我们不希望或者做不到的，因为这需要在组织内为产品，团队和业务范围外的服务提供到控制平面的访问授权。
3. 不可能在每个服务的旁边部署代理数据平面，首先是因为我们不能控制所有的服务，例如由开发人员、客户或组织外部的合作伙伴所构建的第三方应用程序。
4. 在相同服务网格中部署的服务必须使用相同的CA(证书颁发机构)，这样才能获得相互验证的有效TLS证书。而在不同产品或团队的服务之间共享CA几乎是不可能，且不可取的。在这种情况下，可以考虑创建两个独立的服务网格，每个服务网格采用各自的CA，然后通过中间API网关相互通信。

鉴于API网关和服务网格关注不同的使用情况,我推荐一个备忘便签可以确定何时使用API网关或服务网格。这个便签假定在大多数组织中,会因产品、用户场景和服务连接性的不同，而用到2种模式中的一种。

备忘便签

我们将提供产品化API作为流向判断的中心点入口，在此之后，我们按向/外部的客户端或用户区分，提供API网关。通过全生命周期APIM平台，来管理和控制API的暴露、服务运营、以及建立客户端与底层API之间的抽象层。

在用户的系统内的所有服务之间，我们将使用服务网格建立可靠、安全和可观察的L4/L7流量连接。服务网格采用了适配任何服务的去中心化sidecar部署模型，可在所有服务之间创建点对点连接。企业很大可能是同时拥有这两个使用场景，因此将同时使用API网关和服务网格。

案例:金融机构

根据上面的便签图表，我们可以提供以下案例。

对于一个组织来说，由不同的团队构建不同的产品，而这些产品必须相互通信的情况是很常见的。例如，金融机构需要有一个处理银行事务的“银行产品”和一个从事股票市场交易的“交易产品”，这两个产品必须通过通信来共享信息。

开发团队将在产品路线图中的某点上决定实现服务网格，以优化最终产品内服务之间的服务连接性。因为不同的团队，进展速度不同，他们将采用两个独立的服务网格:“服务网格A”和“服务网格B”。

假设为了获得高可用性，这两个产品都部署在两个数据中心“DC1”和“DC2”中。银行产品团队希望将其服务作为产品提供给内部客户，即交易团队。因此，他们考虑通过策略配置，将交易团队视同于采用内部API网关的用户。移动团队也必须消费这两种产品，他们将通过edge API网关入口做到请求访问的可达。整个架构大致如下:

值得注意的是API网关也是网格的一部分，否则它们就没有身份(TLS证书)来合法访问所属网格中其他的服务。如前所述，API网关本质上也是可以发出和接收网络请求的一种服务。

原文链接： https://konghq.com/blog/the-di ... mesh/ （翻译：易理林）