微服务之后什么最火？毫无疑问ServiceMesh。 目前各个大厂都在Mesh化，Mesh的前身是Side Car模式，随着互联网时代/移动互联网时代以及未来IOT时代发展，互联网架构在数据量，高并发，高可用场景会面临几何倍数的增长，同时对于我们的系统也是几何倍数的挑战，我们需要在这个时间点到来之前将我们的系统提前进化，于是CNNF，Service Mesh成为了服务化的未来。

系统服务化之后，服务间通信需要关注什么：

• 服务发现
• 负载均衡
• 路由
• 流控
• 通信可靠性
• 弹性
• 安全
• 监控，日志

API 网关

API网关可以集中式的管理这些功能，但是会出现单点故障，并且实现起来网关会变得越来越臃肿。 并且网关是一个集中式的处理，Service Mesh是网络通信基础设施，可以将网络功能从代码中剥离出来。 通过Service Mesh不用在服务代码中实现用于可靠性通信的模式或断路，超时等控制。

Service Mesh是一个专门的软件基础设施层，和主进程独立，通过（HTTP，GRPC）进行代理通信，用于控制和监控微服务应用程序中服务到服务的内部通信，让服务到服务通信变得快速，安全，可靠。

通常分为：数据层和控制层。

服务开发者不会意识到Service Mesh的存在，平台工程师则通过这套新的工具，以确保可靠性，安全性和可见性。

我们可以将Service Mesh看成路由器和交换机互联的设备组成的（第七层）网络。

通常我们采用代理方式，拦截所有出入的流量来进行请求的安全，可靠，及时的处理。

Service Mesh架构中代理使用的是边车模式实现的。

边车模式：是附属在主应用程序，提供平台功能用以补充该主应用程序功能，比如路由，负载均衡，弹性，深度探测和访问控制。

Service Mesh不仅扩展了主应用的能力，还要监控和保护应用程序，是插在微服务和网络之间的一个透明的基础设施层，以便对服务进行插入，收集检测数据，而无需修改应用程序。

以Linkerd为例

当一个请求经过Linkerd时，会发生以下事件。

Linkerd根据动态路由规则确定请求是发送给哪个服务的，比如是发送给生产环境的还是staging环境的服务？ 是发给本地数据中心的还是云端数据中心的服务？ 是发送给新版的还是旧版的服务？这些路由规则是可以动态配置的，可以应用在全局的流量上，也可以应用在部分流量上。

在确定了请求的目标服务后，Linkerd从服务发现端点获取相应的服务实例。如果服务实例信息出现了偏差，Linkerd需要决定从哪个信息的来源更值得信任。

Linkerd根据某些因子，比如最近处理请求的延迟情况，选择更优秀的实例。

Linkerd向选中的实例发送请求，并把延迟情况和响应信息记录下来。

如果选中的实例发生宕机，无法响应请求，Linkerd会把请求转发给其他实例，当然服务实例需要做成幂等的。

如果一个实例持续返回错误，Linkerd就会将其从负载均衡池移除，并在稍后定时重试，重试成功重新放入负载均衡池。

如果请求超时，则不进行重试，进行记录，最终一致性。

Linkerd以度量指标和分布式日志的方式记录上述行为，然后将度量指标发送中心度量指标系统。

Service Mesh

大规模分布式系统又一个共性：局部故障累积到一定程度会造成系统层面的灾难。

Service Mesh作用是在底层系统的负载达到上限之前，通过流量分散和快速实效来防止这些故障破坏整个系统。

云原生应用的前身：应用层被拆分成多个服务，也就是微服务，这样的系统需要一个通信层，以客户端SDK的方式存在。

云原生应用在之前微服务模型中加入了两个额外的元素：容器和服务编排层。容器提供了资源隔离和依赖管理，服务编排层对底层的硬件进行抽象池化。

边车SDK，容器，服务编排框架让应用程序在云环境中具备了伸缩能力和处理故障的能力。但随着服务实例的数量增长，服务编排需要无时无刻的调度实例，请求在服务拓扑之间穿梭的轨迹变得越来越复杂，再加上不用语言开发的服务实例很多，之前的“胖客户端”方式行不通了。

于是催生了服务间通信层的出现，这个层不会与应用程序的代码耦合，又能捕获底层环境的高度动态的特点，就是Service Mesh。