关于ServiceMesh和APIGateway的关系，这个问题这两年经常被问到，社区里有很多文章和资料可以回答问题。他们中的许多人，例如ChristianPosta，都进行了深入的介绍。我在这里整理和总结资料，并根据个人理解给出一些看法。另外，在本文的最后，我将介绍蚂蚁金服在ServiceMesh与APIGateway融合的最新领域的一些开创性实践和探索，希望能给大家一个更理智的认识。备注1：为了节省篇幅，我们将直奔主题，假设读者对ServiceMesh和APIGateway有基本的了解。备注2：这里的文章更侧重于梳理整个脉络，内容不会详细展开，尤其是其他文章已经阐述过的部分。如果你在浏览本文后还想深入了解细节，请继续阅读文末的参考资料和推荐阅读。1.原本明确的界限：定位和职责首先，ServiceMesh和APIGateway在功能定位和职责上有着非常明确的界限：ServiceMesh：微服务的网络通信基础设施，负责（内部）服务通信APIGateway：负责以API的形式（向系统外部）暴露服务，实现业务功能以原子微服务的形式提供各种能力，是一种（可选的）组合服务。在某些场景下，需要将几个微服务的能力结合起来形成新的服务。原子微服务和组合服务部署在系统内部。就服务网格而言，服务网格提供了服务之间进行通信的能力。APIGateway用于将系统内部的这些服务暴露给系统外部，以API的形式接受外部请求。在部署方面：ServiceMesh部署在系统内部：因为原子微服务和组合服务通常不会直接暴露给外部系统APIGateway部署在系统边缘：一方面暴露在系统外部，另一方面提供API供外部系统访问；一方面，它部署在系统内部，用于访问内部的各种服务。这里介绍两个使用非常广泛的术语：东西向通信：指服务之间的相互访问，其通信流量在服务之间流动，流量位于系统内部。南北通信：指对外提供访问的服务，通常通过APIGateway提供的API对外暴露，其通信流量从系统外部进入系统。解释“东、东、南、北”的由来：如上图所示，地图上通常习惯遵循“上北下南、左东右西”的原则。总结：ServiceMesh和APIGateway在功能和职责上分工明确，边界清晰。但如果事情就这样结束了，就没有关于ServiceMesh和APIGateway的关系的讨论，自然也就没有文章了。问题的根源在哪里？强烈推荐阅读：ChristianPosta的文章《DoINeedanAPIGatewayifIUseaServiceMesh?》在附录中有深入的分析和解释。2、哲学问题：访问内部服务的网关算东西向还是南北向？如下图，图中黄线表示APIGateway访问内部服务：问题来了，从流量的角度来看：这是外部流量进入系统后，开始访问对外暴露的服务，应该属于“南北”通信，典型的如上图所示。但是换个角度，如果我们把APIGateway逻辑上拆分成两部分，先忽略对外暴露的部分，只看APIGateway访问内部服务的部分，那么APIGateway可以看做是一个普通的客户端Service，它与内部服务的通信更像是“东西向”通信：因此，当APIGateway作为客户端访问内部服务时，是南北向还是东西向就成了一个哲学问题：完全取决于关于我们如何看待它APIGateway，作为一个整体，或者逻辑上分为两个部分，内部和外部。这个哲学问题不无道理。在APIGateway的各种产品中，如何实现“APIGateway作为客户端访问内部服务”通常分为两派：明确区分：将APIGateway和内部服务视为两个独立的事物services是自己实现的，兼容独立于服务间通信的机制：APIGateway作为一个公共的内部服务客户端，复用了它的服务间通信机制。最终的决定通常与产品定位有关：如果想保持APIGateway独立的产品定位，希望它能在不同的服务间通信方案下使用，通常选择前者，典型的是kong；如果要使用服务间通信的解决方案，如果有很深的渊源，通常会选择后者，比如springcloud生态中的zuul和springcloudgateway。但无论你选择哪种流派，都不会改变这样一个事实，即“API网关作为客户端访问内部服务”时，确实和普通的内部服务作为客户端访问其他服务没有区别：服务发现、负载均衡,流量路由,熔断,限流,服务降级,故障注入,日志记录,监控,链路跟踪,访问控制,加密,身份认证...当我们列出网关访问内部服务的功能时，我们发现几乎所有这些功能通过服务间调用重复。这也造成了一个普遍的现象：如果有成熟的服务间通信框架，再考虑实现APIGateway，复用这些重复的能力就成了自然而然的选择。典型的例子如前面提到的springcloud生态下的zuul，以及后来开发的springcloudgateway，都是通过类库的复用来实现这些能力的复用。这里还有一个类似的哲学问题：当“API网关作为客户端访问内部服务”时，通过类库的复用实现了代码级的能力复用，相当于自己实现了一个与普通服务通信的解决方案，客户端是一模一样的那么这个“客户端”发过来的流量是算东西向还是南北向呢？答案并不重要。3.Sidecar：真正的巧合点进入ServiceMesh时代后，ServiceMesh和API网关的关系开始变成这样：功能和职责分工明确。客户端访问服务的功能高度重叠。这个时候，两者的关系就很明确了，而且因为当时ServiceMesh和APIGateway是不同的产品，两者的重叠只是功能上的。随着时间的推移，当ServiceMesh产品和APIGateway产品开始相互渗透，两者之间的关系就变得暧昧起来。ServiceMesh出现后，如何为基于ServiceMesh的服务选择合适的APIGateway方案也慢慢开始提上日程，而能够选择复用ServiceMesh自然成为探索方向，新的API网关逐渐出现产品的思路很直白：**如何整合东西南北通信解决方案？**其中一种方法是基于ServiceMesh的Sidecar实现APIGateway，从而将ServiceMesh这种东西向通信的解决方案引入到南北向通信中。这里我们不展开细节，但是我引用一张图（感谢赵华兵）来说明这个方案的思路：这个时候ServiceMesh和APIGateway的关系就变得有趣了，因为引入了ServiceMesh中的sidecar，所以之前的“哲学问题”有了新的解决方案：这次APIGateway真的可以拆分成两个独立部署的物理实体，而不是逻辑上的两个部分：APIGateway本体：实现APIGatewayin除了访问内部服务之外的外部功能sidecar：按照ServiceMesh的标准做法，我们将APIGateway作为部署在ServiceMesh中的一个普通服务，并为这个服务1:1部署sidecar。在这个方案中，sidecar原本用于ServiceMesh被替换为APIGateway中使用，替换APIGateway中原有的客户端访问的各种功能，这种方案大大简化了APIGateway的实现，同时也实现了东西向和南北向通信能力的复用和集成，而APIGateway可以更专注于“API管理”的核心功能。这时候，ServiceMesh和APIGateway的关系已经从“一清二楚”变成了“兼容”。采用这种方案的企业通常先有ServiceMesh产品，然后基于ServiceMesh产品规划（或重新规划）APIGateway方案。蚂蚁金服典型的SOFAGateway产品是基于MOSN的，社区开源产品Ambassador和Gloo是基于Envoy的。上述方案的优点是APIGateway和Sidecar独立部署，职责明确，结构清晰。然而，正如ServiceMesh使用Sidecar被质疑多一跳会造成性能开销影响效率一样，APIGateway使用Sidecar也被质疑：多一跳……“多一跳”问题的解决方法很简单粗暴的，在sidecar的基础上，增加了APIGateway的功能。这样，APIGatewaybody和Sidecar又合二为一了：至于ServiceMesh和APIGateway这一步之后的关系：这个ServiceMesh/sidecar是集成了APIGateway，还是APIGateway集成了ServiceMesh/Sidecar？这个问题就像斑马是白色带黑色条纹还是黑色带白色条纹。不同的人有不同的看法。4.BFF：将整合进行到底BFF（BackendForFrontend）的引入，将使ServiceMesh和APIGateway更加贴近。我们来看看常规的BFF玩法：这里多加了一个BFF层，介于APIGateway和内部服务（包括组合服务和原子微服务）之间。注意BFF的工作模式和combinedservices很相似，就是把多个service组合起来。但不同的是，复合服务仍然属于服务的范畴，只是实现机制将多个服务组合在一起，对外暴露的仍然是一个完整的、标准化的服务。最好的朋友是不同的。BFF，顾名思义，BackendForFrontend，完全是为了前端。而存在，核心目标之一就是简化前端访问。对于我们今天的话题，最关键的一点：BFF完全关闭了从外部进入的流量，而复合服务却没有。APIGateway可以直接访问原子微服务“BFF完全封闭外部流量”，这一点在APIGateway和Sidecar整合后会变得很有想象力。我们先按照前面的集成方式来看BFF案例中APIGateway和Sidecar集成后的情况。:放大一点，分别看APIGateway和BFF：注意这个过程中，流量是通过APIGateway接收到的，进入BFF。在这个过程中，这个请求路径中有两个sidecar：用BFF部署，没有APIGateway功能普通SidecarAPIGateway和Sidecar集成后，这是一个“带APIGateway功能的大Sidecar”（或者“特殊APIGatewaywithSidecarfunction")：虽然起到了APIGateway的作用，但它仍然包含了一个功能齐全的sidecar，相当于BFF自带的sidecar。因此，问题就来了：为什么要在流程中放两个sidecar，缩减为一个会怎样？我们尝试将两个sidecar合二为一，去掉BFF自带的sidecar，直接使用sidecar作为BFF的APIGateway：此时的场景如下：BFF（BFF前面可能有其他流量网络组件提供负载均衡等功能）BFF的sidecar接收流量，完成APIGateway的功能，然后将流量中转给BFFBFF通过sidecar调用内部服务（同上）当没有合并时）。注意这里有一个关键点，就是前面特意提到的注解：“BFF完全关闭外部流量”。这是前提条件，因为原来的APIGateway集群已经不存在了。如果BFF无法关闭所有流量，无法关闭的流量将找不到API网关。当然，如果你愿意稍微麻烦一点，部署时明确定义需要对外暴露的服务，直接在这些服务上部署带有APIGateway功能的Sidecar也是可行的，但是管理会比BFF模式更复杂。另外，在部署方面，根据上面的方案，我们会发现：APIGateway“消失”了——不再有明确物理部署的APIGateway集群，常规的集中式网关集成到各个中BFF的一个实例，实现了另一个重要的特性：去中心化。上述ServiceMesh与APIGateway的融合并非纸上谈兵。在蚂蚁金服内部，我们基于ServiceMesh和APIGateway融合+去中心化的思想进行了开创性的实践和探索。以支付宝手机网关为例，十年来，网关经历了从单体到微服务，从集中到分散，从共享网关。变成了这样的方案：强烈推荐阅读：我同事贾导的文章《蚂蚁金服API网关Mesh思考与实践》在附录中有深入的介绍和详细的说明。五、总结本文总结了ServiceMesh和APIGateway的关系。整体来看，两者的定位和职责是“旗鼓相当”的，但在具体实现上却有融合的趋势：早期的传统方式是类库层面的代码复用，最新的趋势是结合API网关和边车。后者的发展才刚刚起步，包括在蚂蚁金服，我们也才开始探索这个方向，但我相信未来一两年，社区可能会出现更多类似的产品形态。补充介绍文中多次提到的“MOSN”：MOSN是ModularOpenSmartNetwork的缩写。它是一款用Go语言开发的网络代理软件。由蚂蚁金服开源，已通过数十万个容器的生产级验证。MOSN作为云原生网络数据平面，旨在为服务提供多协议、模块化、智能化、安全代理能力。MOSN可以与任何支持xDSAPI的ServiceMesh集成，也可以作为独立的四层或七层负载均衡器、APIGateway、云原生Ingress等。GitHub：https://github.com/mosn/mosn官网：https://mosn.io6.附录：参考资料及推荐阅读对阅读仍有兴趣的同学，欢迎继续阅读以下内容。按文章发表时间排序：TheDifferenceBetweenAPIGatewaysandServiceMesh:2020-02，指导架构师确定何时使用API??Gateway，何时使用服务网格，作者MarcoPalladino，来自kong。DoINeedanAPIGatewayifIUseaServiceMesh?:2020-01，作者ChristianPosta，中文翻译请参考马若飞关于ServiceMesh的【DoIstillneedanAPIGatewayafterusingServiceMesh】技术与API网关的对比，着重分析两者的功能重合点和分歧点，为技术选型和实现提供指导。蚂蚁金服APIGatewayMesh思考与实践：2019-12，作者贾岛，介绍了蚂蚁金服支付宝网关的发展历程和APIGatewayMesh的由来。强烈推荐阅读。这篇文章在ServiceMesh中很清楚地介绍了蚂蚁金服的服务网格。APIGateway集成实践。【API网关的身份危机】：2019-05，原作者ChristianPosta，译者周玉清，介绍了API网关的基本概念，如API的定义，API管理的含义，API网关模式，以及服务网格和API网关的关系。路漫漫其修远兮：蚂蚁金服ServiceMesh实践探索：2018-10，我在QCon的演讲，分享了当时蚂蚁金服服务间通信范围的探索，提出了在东西向通信中使用ServiceMesh的能力复用在南北通信中，当时基于Sidecar的SOFAGateway产品刚刚开始开发。APIGatewayvsServiceMesh：2018-09，作者RichardLi，DatawireCEO，正在开发AmbassadorAPIGateway。Ambassador是基于Envoy的APIGateway的开源产品。文章阐述了服务网格和API网关的观点、区别和融合。DreamMesh抛砖引玉（九）-API网关：2018-03，这篇文章也是我写的。在2018年初与ServiceMesh社区的一些朋友深入讨论后，将当时设想的方案记录在DreamMesh系列博文中，特别针对APIgateway和sidecar的区别进行了详细讨论。当时，想法还不够成熟，但大方向已经成型。感谢当时参与讨论的同学们！ServiceMeshvsAPIGateway：2017-10，原作者KasunIndrasiri，中文版由赵华兵翻译。文章不长。主要对比了ServiceMesh和APIGateway的产品功能，并提出了一种将两者融合的方式——在APIGateway中通过服务网格调用下游服务。应用程序网络功能与ESB、API管理和现在..服务网格？：2017-08，作者ChristianPosta，关于服务网格如何与ESB、消息代理和API管理等相关。内容很好，强烈推荐阅读（不得不吐槽：图片太辣眼睛）。
