Service Mesh是当今比较火的一种微服务架构，许多公司已经开始采用该服务模式。什么是service mesh呢？
说到service mesh之前，我们得先说说传统的微服务是如何工作的。
Figure1
微服务说白了，就是客户端要知道将要访问的服务端在哪，也就是要做到服务发现。
先看图Figure1，这是一种十分简单的模式，我们叫它反向代理。客户端的请求会通过一层代理，通过代理实施负载均衡，将客户端的请求转发到服务集群中的某个实例上。这种模式十分简单，当然，也有很大的弊端。我们看到，所有的请求都会有一层代理进行转发，那么，性能瓶颈就非常明显了，因为代理的性能会限制住服务的吞吐量。所有的请求由于经过了一次转发，时延也相应的会多个几毫秒。最头疼的还有个单点问题，啥叫单点问题呢？想象一下，这个代理服务器挂了会发生啥？当然是这个服务就不可用了，因为请求到代理这层已经无法转发了。
那么，是否可以让客户端自己去发现要请求的服务端呢？不强依赖于代理呢？看图Figure2。
Figure2
客户端代码里面内嵌了一个模块专门用于服务发现，我们叫他Service Discovery（SD）。请求服务端之前，客户端先去注册中心，根据服务标识，寻找到服务实例的地址，然后发送请求到服务端；当服务端启动的时候，会先去注册中心进行注册，也就是填入自己的服务标识以及集群所有实例的地址。这也是目前常用的一种微服务模式。较上文中提到的代理模式，这种模式不再存在诸如单点故障，代理性能瓶颈等问题。不过，依旧存在着弊端。我们提到，服务发现模块是嵌入在业务代码里面的，业务代码使用的编程语言千奇百怪，有些是Golang，有些是C++啥的；为了使所有的客户端都能用得上，就不得不用多种语言来实现这个服务发现模块。对于运维来说，着实是一件十分头疼的事情。
针对这种模式，我们不难想到一种解决方案，那就是在客户端机器上，把业务代码和服务发现代码拆分开不就好了。什么意思呢？就是业务代码和服务发现代码是两个相互独立的进程，这样不就没有语言的问题了吗？如图Figure3，这便是service mesh的雏形。
Figure3
这个负责服务发现的进程，我们叫它sidecar（边车）。为啥这么叫呢？看图Figure4。
Figure4
这种摩托车可以坐两个人，一个人负责驾驶，另一个人负责观察。那个负责观察的座位，便是sidecar，在service mesh中，它就是那个负责服务发现的进程。
下面说说真正的service mesh，看图Figure5，引用了一张来自CSDN的图片，描绘了service mesh的结构。
Figure5
在这里，不再具体区分谁是客户端，谁是服务端了。在一张网（mesh）中，一个服务就是一个网格，这张网中的每个网格之间可以相互通信，通信通过sidecar作为代理进行。如图Figure6，引用一张CSDN的图。所有的sidecar会编织成一张网，也就是一张连通图，从一个节点可以连通到任何节点，这让笔者联想到了路由器。
Figure6
每个网格中，有一个业务代码进程和一个sidecar进程，在service mesh中，sidecar又叫data plane（数据面板），与之相对应的还有一个全局的控制面板（control plane）。控制面板的作用是配置，可以配置服务发现的策略，流量控制，熔断机制等等。
Service Mesh是一个新生的架构，也发展得迅速，也有可能取代当前其它的微服务架构。
閱讀更多 碼農一隻 的文章
