ServiceMesh的前世今生

背景

在谈ServiceMesh前，先来看看微服务架构是如何演进的。如下图：

（图1）

单体架构：所有功能放在一个项目工程，虽然实现很快，但维护成本很高，扩展困难。

垂直架构：将原来的大项目拆成一个个单体结构的项目。项目的复杂度有所降低，且单个项目的技术可单独发展，但项目之间的接口比较单一（多为数据库同步），扩展仍困难。

SOA架构：将重复公共的功能抽取为组件，以服务的方式给各个系统提供服务，企业服务总线（ESB）实现了不同服务之间的通信与整合。提高了开发效率以及系统的可重用性，可维护性。但是服务之间的接口协议不固定，繁琐，系统与服务的边界也比较模糊，不利于维护。

微服务架构：服务拆分的更细，可以更精确的针对服务做方案，服务之间一般采取Restful进行通讯，比中心化的企业服务总线（ESB）更容易维护，产品迭代周期短，能快速适应和验证市场。但同时，微服务的数量变多，服务治理的成本陡增，给团队带来很大挑战。

服务治理的几个阶段

微服务架构带来的好处确实是很多，但服务之间高度依靠网络通信来进行基本的数据交换。而众所周知，网络通信的特点是不可靠，不安全，带宽有限，网络有延迟，传输也有成本。微服务架构带来趋势的必然是服务数量的大幅度上升（如图2），那么这么多微服务，服务间的网络通信该如何管理？

（图2）

服务间的网络通信管理，也即我们常说的服务治理，通常意义上包含服务注册/发现，服务路由，弹性能力（如熔断，限流，超时），访问安全（如https，网络策略），可观察性（如监控，日志，调用链追踪）等。服务治理也经历了几个阶段。

第一阶段：控制逻辑和业务逻辑高度耦合

特点：控制服务间通信的逻辑和业务本身的逻辑耦合在一起，且各个服务都需要重复实现。

第二阶段：控制逻辑抽取成公共库

特点：控制服务间通信的逻辑单独抽取成一个公共库，避免了各个服务重复造轮子，但这个公共库还是和各业务逻辑耦合在一起。

第三阶段：代理模式

特点：控制逻辑不仅独立出来，而且成为了一个单独的代理。如现在常见的nginx等，自带熔断，限流和安全访问等功能。但都相对比较简单，针对更复杂的场景难以支持，如流量镜像，双向https，复杂的灰度等，且这些代理本身又是集中式，与微服务本身推崇的分布式的理念是相违背的。

第四阶段：sidecar模式

特点：控制逻辑不仅成为了一个单独的代理，而且是分布式，每个微服务旁边都会对应一个代理，代理接管了进出该微服务的所有流量。

第五阶段：servicemesh出现

servicemesh的出现也经历了2个阶段，第一代只有数据面，也就是只有代理（典型的如envoy，linkerd）。第二代servicemesh在数据面的基础上，加入了控制面，典型的如istio，控制面用来下发规则给数据面，数据面用来干具体的活（istio里面的数据面就是envoy）。

servicemesh定义

根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层。

通俗一点讲，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控等等。

servicemesh主要功能

包括4部分：流量控制，策略，网络安全，可观察性。

流量控制：路由，流量转移，超时重试，熔断，故障注入，流量镜像。

策略：限流，黑白名单。

网络安全：授权和身份认证。

可观察性：监控指标，日志，调用链追踪。

详细的描述，以后会在istio技术分享中逐一介绍。

servicemesh与k8s的关系

kubernetes