观点 | Opinion
为什么说Service Mesh是微服务发展到今天的必然产物？
过去三年里，架构领域最火的方向非微服务莫属。
微服务的好处显而易见，它本身所具备的可扩展性、可升级性、易维护性、故障和资源的隔离性等诸多特性使得产品的生产研发效率大大提高。同时，基于微服务架构设计风格，研发人员可以构建出原生对于“云”具备超高友好度的系统，让产品的持续集成与发布变得更为便捷。
但是，世界上没有完美无缺的事物，微服务也是一样。著名软件大师，被认为是十大软件架构师之一的Chris Richardson曾一针见血地指出：“微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。此外，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。”
在云原生模型里，一个应用可以由数百个服务组成，每个服务可能有数千个实例，而每个实例可能会持续地发生变化。这种情况下，服务间通信不仅异常复杂，而且也是运行时行为的基础。管理好服务间通信对于保证端到端的性能和可靠性来说是无疑是非常重要的。
以上种种复杂局面便催生了服务间通信层的出现，这个层既不会与应用程序的代码耦合，又能捕捉到底层环境高度动态的特点，让业务开发者只关注自己的业务代码，并将应用云化后带来的诸多问题以不侵入业务代码的方式提供给开发者。
这个服务间通信层就是Service Mesh，它可以提供安全、快速、可靠的服务间通讯（service-to-service）。
在过去的一年中，Service Mesh已经成为云原生技术栈里的一个关键组件。很多拥有高负载业务流量的公司都在他们的生产应用里加入了Service Mesh，如PayPal、Lyft、Ticketmaster和Credit Karma等。
那么，对于Service Mesh这种新兴事物，它有哪些显而易见的优点？现在是否是企业落地Service Mesh的好时机？市面上有哪些好用的开源解决方案？InfoQ记者就这些问题采访了普元云计算架构师、微服务专家宋潇男。
InfoQ：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使用不当造成的一系列问题，同时这个代理工作在网络层，一般情况下也不会成为性能瓶颈。怎么样，是不是有一些单机上动态链接过程的感觉了？
InfoQ：那在Service Mesh没有出现之前，微服务架构之间的通信是用什么方式解决的？都有哪些解决方案？
宋潇男：之前的方案也不少，比如刚刚提到的Netflix OSS的SDK方案，一些大型互联网公司在解决自身内部遇到的问题后，也开源出了一些方案，还有一些规模不太大、不太复杂的系统通过Nginx反向代理做了一些服务发现方案，值得注意的是，现在Nginx官方也推出了基于Nginx的Service Mesh方案。
InfoQ：采用Service Mesh是否需要对正在使用的一些微服务框架作出改动？企业落地Service Mesh有哪些难点？现在是开始转向Service Mesh的好时机吗？
宋潇男：目前成熟的微服务框架大多是SDK方案，如果你的应用已经用了这些SDK进行开发，那么引入Service Mesh肯定要做出很多改动的，简单地说，就是改回去。
目前企业要落地Service Mesh，我觉得并不是一个好时机，先不说落地的难点，首先要面对的问题是Service Mesh框架的选型难题，目前最多生产部署的Service Mesh方案是Linkerd，但是由Google和IBM牵头、众多新老IT厂商支持的Istio方案似乎又更有前景，可惜Istio现在刚刚0.3版本，还不能生产使用。所以与其在两种方案间摇摆不定，不如再等等看。而近期Linkerd又发布了一个新的Service Mesh方案Conduit，使得局势进一步扑朔迷离。所以我的建议是，再等等看。
InfoQ：目前社区都有哪些Service Mesh的开源解决方案呢？（可否介绍下？Linkerd、Envoy、Istio）
宋潇男：主要就是由Buoyant公司推出的Linkerd和Google、IBM等厂商牵头的Istio。Linkerd更加成熟稳定些，Istio功能更加丰富、设计上更为强大，社区相对也更加强大一些。所以普遍认为Istio的前景会更好，但是毕竟还处于项目的早期，问题还很多。
InfoQ：Istio是目前最为流行的开源解决方案，也有大厂加持，可否解释下Istio的架构设计？以及它的社区发展情况？
宋潇男：Istio的架构并不复杂，其核心组件只有四个。首先是名为Envoy的网络代理，用来协调服务网格中所有服务的出入站流量，并提供服务发现、负载均衡、限流熔断等能力，还可以收集大量与流量相关的性能指标；其次是名为Mixer收集器，用来从Envoy代理收集流量特征和性能指标；然后是名为Pilot的控制器，用来将流量协调的策略和规则发送到Envoy代理；最后是名为Istio-Auth的身份认证组件，用来做服务间访问的安全控制。
详见下图：
至于社区的发展，其实并不是特别火热，毕竟项目正式启动才半年多，而且与大多数开发者的距离比较远，所以关注者并不是很多。我想让大多数开发者不去关心它，也正是Service Mesh的意义所在吧。想想单机时代，有多少人会去关注动态链接器呢？我们总是说应该让开发人员更多的关心业务，可是看看现在的微服务、DevOps方案，把多少程序运行期的事情推给开发人员解决，这其实是不对的，而Service Mesh正是要逆转这个不好的趋势。
InfoQ：现在Service Mesh开始逐步成为一个大家“炒作”的新技术，那在你看来，Service Mesh的引入又会带来哪些新的问题呢？
宋潇男：我以前总是开玩笑说，新技术总是解决一个问题，再带来一堆问题，就好像汽车解决了出行问题，然后带来了修车、修路、建加油站、卖车险等一堆问题，世界就是在这个过程中进步的。可是到了Service Mesh这儿，确实想不出它会引入些什么问题，当然这是假设在Service Mesh成熟稳定之后。
在我看来，在三到五年之后，Kubernetes会成为服务器端的标准环境，就像现在的Linux，而Service Mesh就是运行在Kubernetes上的分布式应用的动态链接器，届时开发一个分布式应用将会像开发单机程序一样简单，业界在分布式操作系统上长达三十多年的努力将以这种方式告一段落。
受访嘉宾简介
宋潇男，普元信息云计算架构师。目前在普元负责容器相关的技术架构工作，曾在华为云计算部门负责分布式存储和超融合基础设施的产品与解决方案规划管理工作。曾负责国家电网第一代云资源管理平台和中国银联OpenStack金融云的技术方案、架构设计和技术原型工作。在云计算的萌芽期曾参与Globus、HPC等分布式系统的研究工作，拥有十余年的UNIX和分布式系统技术经验。