先定边界，再选工具
API 网关通常管理外部 API 边界；服务网格管理服务间流量。二者都会增加能力与运营复杂度，并非每个微服务应用都必需，较小工作负载也可能通过其他流量管理模式满足需求。
原文
过去十年 IT 经历 DevOps、云原生、单体拆分为微服务等重大转变。微服务带来收益，也引入复杂性与安全风险。初创团队初期看似轻松，但随着服务数量增长，内外部通信变得复杂，这正是 API 网关与服务网格的用武之地。
本文将详解二者的重要异同及适用场景。
API Gateway
API 管理与 API 网关曾是现代 API 用例、数据中心内外通信与微服务扩展的核心技术，并持续演进。
微服务规模扩大后，应用端
点数量激增，每个端点都需正确安全 与管理，否则将占用大量开发时间。 API 管理有助于妥善保护这些端点。API 网关用于管理、转换与安全化 API，位于公网与后端服务器之间，可配置
自定义策略、认证、日志与监控。 以银行应用为例：查看账户详情会触发不同微服务协同。需要中介确 保请求有序流转——API 网关作为守门人接收外部请求，转发至合适微服务并将结果返回用户。
Service Mesh
服务网格通过追踪、流量管理、监控等能力管理服务间通信，并为微服务架构提供可观测性。
可将其视为应用微服务的防护层，提供以往难以获得的流量管理与观测能力，使网络请求更健壮、安全、可观测。
在 mesh 出现前，团队常在各服务内编写类似代码实现策略、安全与错误处理，语言各异导致碎片化与安全风险。
服务网格将网络管理外置，降低这些风险。
API Gateway 与服务网格的主要相似点
从高层看，二者都促进服务通信并管理网络流量。
二者都有助于服务发现
二者都能提升系统可观测性。
API Gateway 与服务网格的主要差异
API 网关工作于应用层，服务网格 工作于基础设施层。
部署模型不同
：mesh 需在每个服务副本旁部署数据面代理，网关则不需要。 网关更聚
焦业 务逻辑，mesh 更聚焦服务间通信。网关管理内外部流量，mesh
仅用于内部服务与网络之间。 网关可适配单体与微服务，mesh 通常仅
适用于微服务。网关技术更成熟但可能伴随传统 安全挑战；mesh 采用较
新技术应对网络与安全问题。 网关指标反映整体应用健康，mesh 指标更
偏向单个微服务及其组件。是否需要网关或 mesh？ 表面功能相似，但关
注点根本不同。企业可同时使用：网关简化外部流量，mesh 安全化内部通
信。 例如网关将外部请求送入某微服务，mesh 再在内部安全转发至其他
服务。但并非必须同时使用，可按需求独立选型。 何时考虑 Servi ce
Mesh？常见方案包括 Istio、LinkerD、Consul Co
nnect、Kuma、Maesh、AWS App Mesh 等。 微服务
与容器普及使企业需要更高级的流量管理与安全通信，mesh 或其他平台模式
可满足。随着组织迈向云原生与微服务，服务网格有望成为技术栈中的常见组件。
服务网格变得非常重要，
当工作负载增多、项目中微服务数量持续增加时。
当在生产中广泛使用 Kubernetes 时
当 CI/CD 流水线已成熟，并频繁向生产环境发布时。
当应用使用多种语言与框架时
如何选择 Service Mesh？
虽 Istio 日益成为事实标准，但其他方案也可能更合适，没有唯一正确答案，应结合需求、挑战、技能与资源选型。
云原生格局快速变化，服务网格已成为现代栈的重要组件。企业应积极试验以解决新问题。大多数组织拥抱微服务走向云原生，mesh 也将逐步成为常态。