API 网关与服务网格的异同

API 网关

API网关模式描述了网络中的一个附加跃点，每个请求都必须经过该跃点才能到达底层API。在这种情况下，有些人将API网关称为集中式部署。
API 网关作为一个数据面板接受所有客户端的请求、控制流量、执行策略。
API 网关可以有内置的控制面板由于关于和配置数据面板的行为。
API 网关单独部署，和客户端以及 API 相互独立，所以部署简单。
通常用于一下三种 API 使用场景。

1. API 作为产品

把 API 打包成产品供别的开发者、合作商或团队使用。
客户端应运行在产品外部，比如移动应用或者公司其他团队开打的产品。

这种情况下，通过网关暴露的 API 通常使用 HTTP 协议 （REST， SOAP，GraphQL，gRPC），流量既可以是外部流量也可以是内部流量。
API 网关也被用作一个抽象层，它允许我们随着时间的推移更改底层API，而不必更新使用它们的客户端。

2. 服务连接

第二个用例是关于强制实施网络策略，以连接、保护、加密、保护和观察客户端和API网关之间以及API网关和API之间的网络流量。
一旦API网关处理了一个请求，网关本身就必须向底层API发出请求才能得到响应（网关毕竟是一个反向代理）。通常我们希望通过相互TLS来保护请求，记录请求，并对网络通信进行全面的保护和观察。网关还充当负载均衡，并将实现HTTP路由等功能，支持将请求代理到不同版本的API（在这种情况下，它还可以启用蓝绿部署和金丝雀部署用例），以及故障注入等。
我们通过API网关公开的底层API可以在任何体系结构（单片或微服务）中构建，因为API网关公开暴露的接口，就不需要知道里面的实现细节。

3. API 全生命周期管理

API 网关是 API 管理中最重要的部分。
管理API、它们的用户和客户端应用程序以及它们在运行时的通信量只是运行成功的API策略所涉及的许多步骤中的一部分。这些api必须被创建、记录、测试和模拟。运行起来后，API 必须被监控和观察以检测其使用中的异常情况。而API 作为产品暴露时，必须为用户提供一个门户，以便他们注册应用程序、检索凭证并开始使用api。
这种更广泛的体验，是端到端的，涉及API生命周期的各个点（很可能不同的角色将负责生命周期的不同部分），称为全生命周期API管理，实际上，大多数APIM解决方案都提供了一个捆绑解决方案，以在一个或多个产品中实现上述所有问题，这些产品将连接到API网关以执行策略实施。

服务网格

服务网格用于构建一种模式，它从根本上改进了服务之间的连接。每当一个服务想要向另一个服务发出网络请求时（例如，一个使用数据库的整体或一个使用另一个微服务的微服务），我们都希望通过更安全、可观察的模式来处理该网络请求。
服务网格作为一种模式，可以应用于任意结构和任意平台。
所以，服务网格用于管理已有的服务，在引入服务网格之前，系统应该已经有一些流量策略用于安全、观测以及错误处理等方面。
在每个服务应用旁放置一个代理应用实例，实现双向TLS加密和观测，不需要服务开发团队做太多的工作。

因为数据面板代理将与每个服务的每个副本一起运行，所以有些人将服务网格称为分散部署（与API网关模式相反，API网关模式是集中部署）。
因为代理增加了额外的跃点，为了降低延迟，我们把数据面板代理和服务应用部署在一台机器上。

代理应用即充当向内请求的正向代理，也充当向外请求的方向代理。因为每个服务旁都有一个代理实例，所以我们需要一个控制面板管理这些代理实力。控制面板只连接代理，服务间的请求不会经过它。

因此，服务网格模式比API网关模式更具侵入性，因为它要求我们在每个服务的每个实例旁边部署一个数据平面代理，在部署应用程序时需要我们大量地更新CI/CD作业。尽管服务网格还有其他部署模式，但上面描述的部署模式（每个服务副本一个代理）被认为是行业标准，因为它保证了最佳、最高的可用性，并允许我们为每个服务的每个副本分配唯一的标识（通过mTLS证书）。
服务网格主要处理一种使用场景。

1.服务连接

通过吧网络管理交给第三方代理服务， 开发团队可以避免自己实现相关功能。代理服务可以实现很多能力，比如双向TLS加密，身份识别，路由，日志，追踪，负载均衡等等。这些功能可以赋予所有的服务。
服务网格还可以支持HTTP之外的TCP流量。所以服务网格支持更广泛的服务范围，实现L4/L7的流量策略，而API 网关更聚焦于L7的策略。
从概念的角度来看，服务网格对系统中运行的工作负载有一个非常简单的视图：一切都是一个服务，服务可以相互通信。因为API网关也是一个接收请求和发出请求的服务，所以API网关只是网格管理的诸多服务中的一个服务。

因为每个服务的每个副本都要有一个数据面板做代理，并接数据面板的对客户端的代理必须高效，所以控制面板必须知道每个代理的地址。地址可以通过元数据获取，比如服务名。因此，服务网格本质上提供了内建的服务发现。

API 网关 vs. 服务网格

通过对比使用场景可以看到两者有所重叠。

有如下选用建议