Service Mesh扫盲

原文：http://www.infoq.com/cn/news/2017/12/why-service-mesh

摘要：

对 Service Mesh 的理解？它的出现最终是为了解决什么问题？

Service Mesh 这个词本身出现的时间确实不长，但是它所描绘的事情存在的时间可不短，其本质就是分布式系统的动态链接过程，眼下最大众化的分布式系统就是微服务，所以可以简单地说，Service Mesh 就是微服务的动态链接器（Dynamic Linker）。

让我们回忆一下单机程序的运作方式，源代码被编译器编译为一系列目标文件，然后交由链接器将这些目标文件组装成一个可执行文件，链接过程就是将各个目标文件之间对符号（方法、变量、函数、接口等）的引用转化为对内存地址的引用，由于这个过程在生成可执行文件时就完成了，所以被称为静态链接。

后来为了程序的模块化和功能上的解耦与共用，开始把一些常见的公共程序剥离出来，制作成库文件供其他程序使用，在引用这些库文件的程序运行时，操作系统上的动态链接器会在库文件中查询到被引用的符号，然后将这些符号的内存地址映射到该程序的虚拟内存空间之中，由于这个过程是在程序运行时完成的，所以被称为动态链接。

再后来出现了分布式系统，程序被散布在网络中的不同主机上，那么如何链接这些程序呢？业界走过了和链接单机程序类似，但是却艰难得多的一段历程。因为这个访谈是在微服务的大背景下进行的，为了叙述方便，我们从现在开始把这些程序称为服务。业界最开始是把这些服务的网络地址写在配置文件中，这个方案显然问题太多、很不靠谱。所以接下来自然而然地出现了服务注册中心来统一记录这些服务的网络地址并维护这些地址的变化，服务通过注册中心提供的客户端 SDK 与注册中心通信并获得它们所依赖的服务的网络地址。由于网络通信远没有内存通信稳定，为了保证可靠的服务调用，又出现了用于流量控制的 SDK，提供流量监控、限流、熔断等能力。

在大型系统中，被依赖的服务往往以多实例的方式运行在多个主机上，有多个网络地址，所以又出现了用于负载均衡的SDK。现在问题貌似是解决了，但是我们手里多了一堆 SDK，我们手上已有的应用，必须用这些 SDK 重新开发，这显然可行度不高，而对于新开发的应用，我们又发现这些 SDK 体积过大，以 Netflix OSS 提供的 SDK 为例，依赖包动辄上百兆，在做微服务开发时，经常发现 SDK 的体积比程序本身还大很多倍，如果你使用容器技术，你会发现你的程序和基础容器的体积加起来还没 SDK 大，所以经常有人吐槽说现在的这些所谓的微服务框架实际上不是为微服务设计的。另外，SDK 还会带来性能伸缩性的问题，在性能要求较高的系统中，SDK 往往成为了性能瓶颈。再回头看一下单机上动态链接过程的顺畅，这种基于 SDK 的微服务动态链接方案简直是难用的不得了。

这时业界才开始关注已经存在了一段时间的 Service Mesh 方案，Service Mesh 的基础是一个网络代理，这个网络代理会接管微服务的网络流量，通过一个中央控制面板进行管理，将这些流量转发到该去的地方，并在这个代理的基础之上，扩展出一系列的流量监控、限流、熔断甚至是灰度发布、分布式跟踪等能力，而不需要应用本身做出任何修改，让开发者摆脱了SDK 之苦，也避免了由于 SDK 使用不当造成的一系列问题，同时这个代理工作在网络层，一般情况下也不会成为性能瓶颈。怎么样，是不是有一些单机上动态链接过程的感觉了？

Service Mesh 的开源解决方案

主要就是由 Buoyant 公司推出的 Linkerd 和 Google、IBM 等厂商牵头的 Istio。Linkerd 更加成熟稳定些，Istio 功能更加丰富、设计上更为强大，社区相对也更加强大一些。

未来展望

在我看来，在三到五年之后，Kubernetes 会成为服务器端的标准环境，就像现在的 Linux，而 Service Mesh 就是运行在 Kubernetes 上的分布式应用的动态链接器，届时开发一个分布式应用将会像开发单机程序一样简单，业界在分布式操作系统上长达三十多年的努力将以这种方式告一段落。