文章目录
- Service Mesh 诞生
- Service Mesh 定义
- Service Mesh 形态
- service mesh 解决了什么痛点？
- 回头看，不曾走远
Service Mesh 诞生
先来个文献：https://philcalcado.com/2017/08/03/pattern_service_mesh.html
Service Mesh 定义
“别废话了，我没工夫听你说这么多，请用一句话跟我解释 Service Mesh 是什么。好的。 A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.”
这就是上面那位又帅又能写的CEO，对Service Mesh的权威定义：
“dedicated infrastructure layer”：Service Mesh 不是用来解决业务领域问题的，而是一层专门的基础设施（中间件）。
“service-to-service communication”：Service Mesh 的定位很简单也很清晰，就是用来处理服务与服务之间的通讯。
“reliable delivery of requests”：服务间通讯为什么需要特殊处理？因为网络是不可靠的，Service Mesh 的愿景就是让服务间的请求传递变得可靠。
“cloud native application”：Service Mesh 从一开始就是为现代化的云原生应用而生，瞄准了未来的技术发展趋势。
“network proxies”：具体 Service Mesh 应该怎么实现？典型方式都是通过一组轻量级的网络代理，在应用无感知的情况下偷偷就把这事给干了。
“deployed alongside application code”：这些网络代理一定是跟应用部署在一起，一对一近距离贴心服务（比房产中介专一得多）；否则，如果应用与代理之间也还是远程不靠谱通讯，这事儿就没完了。
一言以蔽之：Service Mesh 是微服务时代的 TCP/IP 协议。
Service Mesh 形态
左边这张图是Linkerd的部署示意图，其中每个微服务所处的主机（host）或容器组（pod）中都会部署一个Linkerd代理软件，用于代理微服务应用实例之间的RPC调用。对于应用而言，这一切都是无感知的：它还是照常发起自己的RPC调用，只是不再需要关心对端服务方的地址，因为服务发现都由代理节点给cover了。
右边是一张更高维和抽象的大图，可以更形象地理解 Service Mesh 的逻辑形态 —— 想象这就是一个生产级的大规模微服务集群，其中部署了上百个服务实例以及对应的 Service Mesh 代理节点；所有微服务之间的通讯都会流经这些密密麻麻的代理节点，它们共同组成了一张川流不息的现代化交通网格。
service mesh 解决了什么痛点？
可能很多人不知道 service mesh，如果你觉得很多人都知道，那是“幸存者偏差”。但是相比于 service mesh，微服务的知名度就相对大一些了。
但是：
有图我就不想说话了哈哈。
因此以Linkerd，Envoy，NginxMesh为代表的代理模式（边车模式）应运而生，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样上边所说的问题也迎刃而解。 （对于业务层来说，网络层确实是剥离出来了，上面的问题确实得到了解决，至于 service mesh 怎么落地，已经不归业务层管了）
第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。
Istio，后面再说咯。
回头看，不曾走远
现在，我们再回过头来看Buoyant的CEO William Morgan，也就是Service Mesh这个词的发明人，对Service Mesh的定义：
服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。
这个定义中，有四个关键词：
基础设施层 请求在这些拓扑中可靠穿梭：这两个词加起来描述了Service Mesh的定位和功能，是不是似曾相识？没错，你一定想到了TCP；
网络代理：这描述了Service Mesh的实现形态；
对应用透明：这描述了Service Mesh的关键特点，正是由于这个特点，Service Mesh能够解决以Spring Cloud为代表的第二代微服务框架所面临的三个本质问题；
总结一下，Service Mesh具有如下优点：
- 屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑；真正的语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；对应用透明，Service Mesh组件可以单独升级；
当然，Service Mesh目前也面临一些挑战：
- 新技术如何平滑演进？
- 发展的过程中如何协调好技术和业务的平衡？
- 技术向前演进时如何处置历史包袱？
- 如何克服超大规模所带来的问题？
- Sidecar 的规模化运维？
- …
历史总是惊人的相似，我辈应该深思。
