我来讲一下-Service Mesh.

前言：

1、中文直翻译：Service Mesh叫服务网格，有一些讲课老师说什么把服务当成一个一个格子，一笔带过，没有经过深刻思考的讲诉，我真的bs.

一、我来讲一下

1、这里拆解分析一下，Service中的"Service"究竟是什么？
直接说结论这里的“Service”指的是 "Micro service"的"“Service” 就是常说的微服务的“Service”。

2、“Mesh”指的是什么？还是直接说结论：
想象一下“当你有一个微服务可观测平台，在上帝(俯视)视角-可视化观察一万个微服务的时候是不是就是一个非常大的网格，并且网格中彼此连接在一起.

3、那么“Service Mesh.”就不是一个“名词”，更像是一个“象形词”需要有想象力才能理解。

二、再说一下“在基础架构中怎么理解Service Mesh.”

1、在没有“Service Mesh”之前业务时如何实现的网络功能的？

1、在java语言的微服务架构中，有一个很经典的架构叫Spring,这门语言有很多好用的SpringCloud组件，比如阿里云的 “nacos”。

2、在使用“SpringCloud组件”做开发之前，比如你后端有三个服务。A和B服务，其中B服务需要弹性扩展，那么A服务在除了业务逻辑代码以外还需要写网络功能的代码（来实现服务B的LB的功能），还要实现服务发现。

3、在使用“SpringCloud组件”做开发之后，你的A服务和B服务会在启动时注册到你的"nacos"注册中心上，由他来管理网络功能，并且在把相应服务的路由信息同步给其他服务。

4、此时A服务需要访问B服务，只需要在配置文件中写上一个变量，Service_B = "SpringCloud_Service_B",后面的这个值“"SpringCloud_Service_B"”，是“SpringCloud组件”__"nacos"提供给他。那么此时在开发程序时，网络功能就交给了第三方“SpringCloud”组件来管理网络功能。

2、微服务框架好好的，为什么现在又要“Service Mesh”？

1、因为之前的基础架构是虚拟化平台，虚拟化平台适合需要独立内核和较高安全性场景使用，比如“云桌面”。

2、而对于现代应用程序，生产单位的需求是“今天的需求，明天就要上线”，“上线有问题，我希望立刻马上可以回退到正常版本”，“我还想我的程序能顶的住高并发！”，“我还希望我的微服务网络流量之间具备非常好的可观测性”，“我还希望我自己的HTTP程序不用自己管理配置和TLS证书”，很明显虚拟化平台要付出非常大的成本和代价才能勉强满足这些需求，但是容器平台天生就具备。

3、选择了容器平台后确实解决了上述的问题，但是人的欲望是无穷的，既然基础架构就可以满足我的网络需求，那么为什么还要把“SpringCloud”部署在容器平台中呢？这不是浪费资源，又不那么云原生。

   4、然后你把“SpringCloud”的组件和程序代码中关于“SpringCloud”的注册部分代码的删除，使用k8s原生的服务注册机制，“环境变量注入方式”，这样确实实现了东西向微服务的网络打通，但是问题又来了。原生的k8s的kubeproxy（服务注册机制）是一个4层LB，他无法满足你额外的欲望比如：“我希望我A服务访问B服务的时候可以实现7层的流量可观测性”“我希望我A服务访问B服务的时候可以实现流量权重”，“我希望我A服务访问B服务的时候可以实现URL冲重定向”等等，那么k8s本身平台不满足，那咋整呢？

   5、没错，就引入了“Service Mesh”，即“envoy”边车，让你的所有服务的pod都加一个"envoy"边车网络容器，来劫持直接到你容器的流量，让“envoy”来实现你pod的网络功能，而"envoy"本身就是一个可以实现7层网络功能的容器。

   6、此时你的微服务互相通信看似是几个微服务间的通信，其实是几个“envoy”边车容器之间的通信，你打开可视化监控平台，查看7层的可观测性，假设你有1万个微服务，此时他们看起来就是“Service Mesh（服务网格）”。