序

早在2013年，我供职的阿里巴巴集团（以下简称阿里）中间件软负载团队就受运维部门之托，开始着手研究新一代的内部服务调度与治理系统。那个时候微服务概念还没有提出，但阿里在服务化方式上已经走在前列了——强壮的业务由拥有数量庞大的服务群及复杂的调用关系支撑着。运维的需求集中于希望能提供一种“更加灵活、响应更快速且更低成本”的方案来连接、控制、配置整套线上服务系统；因为在当时的LVS负载体系下，由于硬件的限制，是不可能做到快速响应的，而独立部署的LVS集群在配置与多环境下都又略显得有心无力。

当时我的领导蒋江伟（花名小邪）将这一重任交予了我并预示了SDN（Software Defined Network，即软件定义的网络）的发展方向，我很荣幸能拥有这样的机会，当然也没有辜负他的期望。一年后，VIPServer系统诞生，第一次在阿里内部以纯软路由的形式调度各大系统间的请求，并在两年内完全主宰了内部的服务调用需求。

软路由的好处在于“软”，不与实体布线、交换机配置或硬件绑定，对于不同的流量流向什么样的地方可以任意且随时地变更，此即灵活。例如我们可以将来自Android客户端的流量指定到链路中拥有Test标记的服务器，这样可以实现诸如灰度发布的功能。分布式系统发布至今，系统数量空前爆炸，业务的关系与配置越来越复杂，因此对环境治理与隔离的要求也越来越高。回顾应用容器的发展，从纯硬件到硬件虚拟化、容器化再到弹性编排，无不都是走向“软件定义”这个方向，因此软负载领域也应该如此。

2017年我加入挖财，发现对较大型企业而言，中小规模企业更加饱受服务环境治理之苦，因为中小规模的企业通常没有过多精力自行研发属于自己的软负载体系，大多通过修改开源的组件来实现目的。这样的问题在于无法组成一个平台体系，虽然基本功能（如配置、服务发现）能够满足，一旦涉及多级协调功能（如链路压测、故障注入体系）的时候，便捉襟见肘了。虽然阿里早些年已经拥有这样的能力了，但想要将其直接复制到外部的企业却是一项几乎不可能完成的任务。阿里的关键技术都是定制的（如RPC服务HSF），设计所针对的场景不一定适合中小企业，即关注的点不同；所以对于中小企业而言，需要的就是一个能够连接各软负载开源产品的平面，而且这个平面应该与主流的服务编排、RPC、配置及服务发现完美兼容，并最大限度地支持链路功能扩展。

带着上述问题，我一直在思考这个产品的存在形式；而在Istio问世以后，我便相信这就是它的最佳形态。我个人看好服务网格（Service Mesh）在服务架构上的影响力，并且相信这是微服务架构的下一个阶段，因为对多数企业而言架构本身的复杂度已经开始超越业务逻辑本身，如果不加以统一管理与规划，那么只是维护成本就已经很高了。

服务网格的思想就像是分布式服务本身下沉到技术栈中，只对业务提供接口供其调用。Istio很巧妙地将其分成了“控制平面”与“数据平面”两部分，使得接口本身更加清晰。接口清晰的好处在于更加容易地定义边界与职能，例如“数据平面”部分，Istio便可以直接依托于开源Envoy来实现，而且这并不是唯一的选择；而“控制平面”则为运维人员提供了统一的接口来操作整个链路，相较之前的零散的配置，仅这一点就可以节省不少的人力成本。

2018年，阿里顺势推出了自己的Naco 来争夺这一领域，蚂蚁金服也公布了SOFAMesh项目。这说明软负载仍然是大型分布式系统基础的重点，只有将环境与调用梳理清楚、高效利用起来，上层的业务及周边的扩展基础才能快速地推进。未来的分布式架构只会愈加专注，职能划分愈加精细，计算愈加弹性灵活。

虽然在本书编写过程中已经尽力反复去论证、实践每一处，但难免遗误，希望大家积极批评指正。最后我要感谢下面这些在编写本书时一直支持我的朋友们，无论是帮忙订正还是写序，感谢你们！同时本书第6章得到了蚂蚁金服团队的大力支持，特别感谢你们！当然还有在背后一直支持我的家人们，谢谢！

（以下排名不分先后）

孙虹陈霞光蒋云鹏吕献军徐伟杰李华刚周文瑾杨卓荦马连志

宋越月王伟杨凯蒋江伟刘清富黄挺罗毅许令波李云