东西流量和南北流量&Service Mesh和API Gateway的关系

服务网格中的南北流量和东西流量
参考网上是这么说的：
在Service Mesh微服务架构中，我们常常会听到东西流量和南北流量两个术语。
南北流量（NORTH-SOUTH traffic）和东西流量（EAST-WEST traffic）是数据中心环境中的网络流量模式。

假设我们尝试通过浏览器访问某些Web应用。Web应用部署在位于某个数据中心的应用服务器中。在多层体系结构中，典型的数据中心不仅包含应用服务器，还包含其他服务器，如负载均衡器、数据库等，以及路由器和交换机等网络组件。假设应用服务器是负载均衡器的前端。

当我们访问web应用时，会发生以下类型的网络流量：

客户端（位于数据中心一侧的浏览器）与负载均衡器（位于数据中心）之间的网络流量
负载均衡器、应用服务器、数据库等之间的网络流量，它们都位于数据中心。

南北流量：
在上面例子中，前者即即客户端和服务器之间的流量被称为南北流量。简而言之，南北流量是server-client流量。

东西流量：
第二种流量即不同服务器之间的流量与数据中心或不同数据中心之间的网络流被称为东西流量。简而言之，东西流量是server-server流量。

当下，东西流量远超南北流量，尤其是在当今的大数据生态系统中，比如Hadoop生态系统（大量server驻留在数据中心中，用map reduce处理），server-server流量远大于server-client流量。

好奇点，东西南北，为什么这么命名？
该命名来自于绘制典型network diagrams的习惯。在图表中，通常核心网络组件绘制在顶部（NORTH），客户端绘制在底部（SOUTH），而数据中心内的不同服务器水平（EAST-WEST）绘制。

Service Mesh和API Gateway关系

关于Service Mesh和API Gateway之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理和汇总，结合个人的理解给出一些看法。另外在本文最后，介绍蚂蚁金服在Service Mesh和API Gateway融合的这个最新领域的一些开创性的实践和探索，希望给大家一个更有体感的认知。

备注1：为了节约篇幅，我们将直奔主题，假定读者对Service Mesh和API Gateway已有基本的了解。

备注2: 这边文章更关注于梳理整个脉络，内容不会展开的特别细，尤其是其他文章已经详细阐述的部分。如果您在浏览本文之后，还想更深入的了解细节，请继续阅读文章最后的参考资料和推荐阅读。

原本清晰的界限：定位和职责
首先，Service Mesh和API Gateway在功能定位和承担的职责上有非常清晰的界限：
Service Mesh：微服务的网络通信基础设施，负责（系统内部的）服务间的通讯
API Gateway： 负责将服务以API的形式暴露（给系统外部），以实现业务功能

如上图所示：

从功能和职责上说：

位于最底层的是拆分好的原子微服务，以服务的形式提供各种能力
在原子微服务上是（可选的）组合服务，某些场景下需要将若干微服务的能力组合起来形成新的服务
原子微服务和组合服务部署于 系统内部，在采用Service Mesh的情况下，由Service Mesh提供服务间通讯的能力
API Gateway用于将系统内部的这些服务暴露给 系统外部，以API的形式接受外部请求。
从部署上说：

Service Mesh部署在系统内部：因为原子微服务和组合服务通常不会直接暴露给外部系统
API Gateway部署在系统的边缘：一方面暴露在系统之外，对外提供API供外部系统访问；一方面部署在系统内部，以访问内部的各种服务。
在这里引入两个使用非常广泛的术语：

东西向通讯：指服务间的相互访问，其通讯流量在服务间流转，流量都位于系统内部
南北向通讯：指服务对外部提供访问，通常是通过API Gateway提供的API对外部保罗，其通讯流量是从系统外部进入系统内部。
解释一下“东西南北”的由来：如上图所示，通常在地图上习惯性的遵循“上北下南，左西右东”的原则。
参考连接：
https://www.servicemesher.com/blog/service-mesh-and-api-gateway/
GitHub：https://github.com/mosn/mosn
官网：https://mosn.io