Service mesh介绍1

01 架构的发展历史

发展历史事件轴

 

 图1 架构发展时间轴

1.1 单机小型机时代

第一个计算机网络诞生于1969年，即美军的阿帕网，阿帕网能够实现与其他计算机的联机操作，但早期仅用于军事服务，2000年，中国网民大概60多万，很多人不知道物联网为何物，因此大多数服务业务单一且简单，采用典型的单机+数据库模式，所有功能都写在一个应用里进行集中部署。

 

图2 简单单机小型机图例

1.2垂直拆分

随着应用的日益复杂和与多样化，开发者对系统的容灾、伸缩以及业务响应能力有了更高的要去，如果小型机和数据库中任何一个出现故障，整个系统都会崩溃，若某个板块的功能需要更新，那么整个系统都需要重新发布，这已不适合当前计算机物联网的发展环境。如何保障可用性的同时快速响应业务的变化，需要将系统进行拆分，将单机小型机的应用拆分出多个子应用。

 

图3 垂直拆分架构示意图

垂直拆分的优点：应用跟应用解耦，系统容错提高了，也解决了独立应用发布的问题，应用垂直拆分解决了应用发布问题，但随着用户数量的增加，单机的计算能力依旧是杯水车薪。

 1.3 集群化负载均衡架构

用户量越来越大，意味着需要更多的小型机，但小型机价格昂贵，操作维护成本高。此时更优的选择是采用多台pc机部署同一个应用的方案，但此时就需要对这些应用做负载均衡，因为客户端不知道请求会落到哪一个后端pc应用上的。

负载均衡可以为分成硬件和软件两个层面：

硬件层面：FS

软件层面：LVS、Nginx、Haproxy

负载均衡的思想：对外暴露一个统一接口，根据用户的请求来进行对应规则转发，同时负载均衡还可以进行限流等等。有了负载均衡之后，后端应用可以根据流量的大小进行动态扩容，称为“水平扩展”。

 

 

图4 集群化负载均衡架构图

阿里巴巴在2008年提出去“IOE”，即IBM小型机、Oracle数据库、MEC存储，全部改成集群化负载均衡架构，2013年，支付宝最后一台小型机下线。

集群化负载均衡架构优点：应用跟应用解耦，系统容错性提高了，也解决了独立应用发布的问题，同时可以水平扩展来提供应用的并发量。

1.4服务化改造架构

虽然系统进行了垂直拆分，但拆分后发现子应用中依旧存在重复的功能，一旦项目大了，集群部署多了，这些重复的功能无疑会造成资源浪费，可以把重复功能抽取出来,名字叫“xx服务”。

 

图5 服务改造架构示意图

为了解决服务跟服务之间相互调用关系，需要一个程序之间的通讯协议，所以就有了远程调用（RPC），作用是让服务之间的程序调用变得像本地调用一样的简单。

优点:在集群化负载均衡架构之上解决了业务重用问题。

 1.5 服务治理

随着业务的增大，基础服务越来越多，调用网的关系由最初的几个增加到几十上百，造成调用链路错综复杂，需要对服务进行治理。

服务治理的要求：

1、当服务节点数几十上百的时候，需要对服务有动态的感知，引入了注册中心。

2、当服务链路调用很长的时候如何实现链路的监控。

3、单个服务的异常，如何能避免整条链路的异常（雪崩），需要考虑熔断、降级、限流。

4、服务高可用：负载均衡。

典型框架有：Dubbo默认采用的是Zookeeper作为注册中心。

1.6 微服务时代（分布式微服务时代）

微服务是在2012年提出的概念，微服务提出的重点是：一个服务只负责一个独立的功能。

拆分原则：任何一个需求不会因为发布或者维护而影响到不相关的服务，一切可以做到独立部署运维。比如传统的“用户中心”服务、对于微服务来说，需要根据业务再次拆分，可能需要拆分成“买家服务”、“卖家服务”、“商家服务”等。

典型代表：Spring Cloud，相对于传统分布式架构，Spring Cloud使用的是HTTP作为PRC远程调用，配合上注册中心Eureka和API网关Zuul，可以做到细分内部服务的同时又可以对外暴露唯一的接口，让外部对系统内部架构无感，此外Spring Cloud的config组件还可以把配置统一管理。

1.7 服务网格新时期（service mesh）

1.7.1 SideCar

SideCar 降低了与微服务架构相关的复杂性，并且提供了负载均衡、服务发现、流量管理、电路中断、遥测、故障注入等功能特性。

SideCar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式，该模式允许我们向应用无侵入式添加多种功能，避免了为满足第三方组件需求而面向应用添加额外的配置代码。

很多公司借鉴了Proxy模式，推出了SiderCar的产品，比如向Netflix的Prana，蚂蚁金服的SofaMesh

 

图6 SiderCar作用示意图

服务业务代码与SiderCar绑定在一起，每个服务配置了一个SiderCar代理，每个服务所有的流量都经过SiderCar，SiderCar屏蔽了所有的通信细节，让业务开发人员只需要关注业务，而通信由SiderCar负责。

SiderCar可以理解为代理，控制流服务的流量的进出，SiderCar是为了通用基础设施而设计，可以做到与公司框架技术无侵入性。

1.7.2 Linkerd

 2016年1月，离开Twitter的基础设施工程师打造的一个网络服务项目，第一个Service Mesh项目由此诞生，解决通用性。

Linkerd很好地结合了Kubernetes所提供的功能，并以此为基础，在每个kubernetes Node上都部署运行一个Linkerd实例，用代理的方法将加入Mesh的Pod通信转接给Linkerd，这样Linkerd就能在通信链路中完成对通信的控制和监控。

 

图7 Linkerd设计思想

 Linkerd优点

1、无需侵入业务代码的内部就能够管理流量；

2、兼容Kubernetes提供的所有功能；

 Linkerd缺点：

1、部署繁琐；

2、只解决了数据层面的问题，没有对数据层面进行管理；

1.7.3 istio

istio是由Google、IBM和Lyft共同发起的开源项目，由go语言编写的。

通过istio，可以轻松创建带有负载均衡、服务到服务的身份验证，监视等功能的已部署服务网格，使得服务的代码更改很少或者没有更改（不需要加依赖、），通过在整个环境中部署一个特殊的SiderCar代理来拦截微服务之间的所有网格通信，然后使用其控制平面功能配置和管理，以为服务添加istio支持。

istio既有数据平面，也有控制平面，即拥有了数据接管与集中控制能力；Linkerd只有数据平面。

1.7.4 什么是服务网格

服务网格：指的是微服务网络应用之间的交互，随着规模和复杂性的增加，服务跟服务调用错综复杂。

 

图8 服务网格示意图

 若每个格子都是一个SiderCar数据平面，然后SiderCar彼此通信，那么service mesh就是来管理每个格子的控制平面，这就是服务网格，从架构层面看起来跟网格很像。

Service mesh特点：基础设施、支持云原生、网络代理、对应用透明

1.7.5 CNCF云原生组织发展与介绍

云原生发展时间轴

 

图9 云原生发展时间轴

CNCF是一个开源软件基金会，致力于使云原生计算具有普遍性和可持续性，云原生计算使用开源软件技术栈将应用程序部署为微服务，将每个部分打包到自己的容器中，并动态编排这些容器以优化资源利用率，云原生技术使软件开发人员能够更快地构建出出色的产品。