第1章 服务网格的历史

要讨论服务网格（Service Mesh），就必须提到微服务。微服务（Microservices）自2012年被提出以来，就继承了传统SOA架构的基础，并在理论和工程实践中形成新的标准，热度不断攀升，甚至有成为默认软件架构的趋势。2014年，马丁·福勒在Microservices一文中，对微服务做出了纲领性的定义，总结了微服务应该具备的特点，如下所述。

◎ 在结构上，将原有的从技术角度拆分的组件，升级为从业务角度拆分的独立运行的服务，这些服务具备各自的实现平台，并且独占自有数据，在服务之间以智能端点和哑管道的方式通信。

◎ 在工程上，从产品而非项目的角度进行设计，强调迭代、自动化和面向故障的设计方法。

微服务架构在很大程度上提高了应用的伸缩性，方便了部门或业务之间的协作，使技术岗位能够更好地引入新技术并提高自动化程度，最终达到减耗增效的目的。然而和所有新方法一样，微服务架构在解决老问题的同时，也带来了一些新问题，例如：

◎ 实例数量急剧增长，对部署和运维的自动化要求更高；

◎ 用网络调用代替内部API，对网络这一不可靠的基础设施依赖增强；

◎ 调用链路变长，分布式跟踪成为必选项目；

◎ 日志分散严重，跟踪和分析难度加大；

◎ 服务分散，受攻击面积更大；

◎ 在不同的服务之间存在协作关系，需要有更好的跨服务控制协调能力；

◎ 自动伸缩、路由管理、故障控制、存储共享，等等。

David Wheeler曾说过：“Any problem in computer science can be solved by another layer of indirection.”可将其理解为：计算机科学中的所有问题都可以在新的层次里间接地解决。微服务架构产生的新问题，同样可以在微服务之外的新的层次里间接地解决。

为了解决微服务架构产生的一些问题，以Kubernetes为代表的容器云系统出现了。这类容器云系统以容器技术为基础，在进程级别为微服务提供了一致的部署、调度、伸缩、监控、日志等功能。

然而，除了进程本身的问题，微服务之间的通信和联系更加复杂，其中的观测、控制和服务质量保障等都成为微服务方案的短板，因此随着Kubernetes成为事实标准，Service Mesh顺势登场。

自Service Mesh技术诞生以来，国内外出现了很多产品，下面选择其中几个重要的产品和事件，大概理理Service Mesh相关产品的发展情况。