前言
Service Mesh：下一代微服务。 原文链接，这篇是我觉得把Service Mesh讲的最清楚的文章了。内容为QCon 2017年上海会议上的演讲实录。为了防止原链接的失效，还保存一份word。点击下载 提取码: tz6w。
我对Service Mesh的理解
传统的微服务中，拿dubbo来说，客户端想要远程调用服务端，这个过程肯定设计到网络通信。
先不讨论网络通信是否稳定，业务人员只是想要编写客户的CURD，可是远程调用会混杂大量非功能块的代码。如服务发现、负载均衡、熔断等。这对刚接触到业务的同事来说是比较难的。
那么我们要做的就是把这层网络通信抽象出来，我们称它为Sidecar。
Sidecar这个词中文翻译为边车，或者车斗，也有一个乡土气息浓重的翻译叫做边三轮。Sidecar这个东西出现的时间挺长的，它在原有的客户端和服务端之间加多了一个代理。
多个服务调用的情况，在这个图上我们可以看到Service Mesh在所有的服务的下面，这一层被称之为服务间通讯专用基础设施层。Service Mesh会接管整个网络，把所有的请求在服务之间做转发。在这种情况下，我们会看到上面的服务不再负责传递请求的具体逻辑，只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来，呈现出一个抽象层。
如果有大量的服务，就会表现出来网格。图中左边绿色方格是应用，右边蓝色的方框是Service Mesh，蓝色之间的线条是表示服务之间的调用关系。Sidecar之间的连接就会形成一个网络，这个就是服务网格名字的由来。这个时候代理体现出来的就和前面的sidecar不一样了，形成网状。
大家注意看，上面的图中，网络在这种情况下，可能不是特别明显。但是如果把左边的应用程序去掉，现在只呈现出来Service Mesh和他们之间的调用，这个时候关系就会特别清晰，就是一个完整的网络。这是Service Mesh定义当中一个非常重要的关键点，和Sidecar不相同的地方：不再将代理视为单独的组件，而是强调由这些代理连接而形成的网络。在Service Mesh里面非常强调代理连接组成的网络，而不像sidecar那样看待个体。