Istio基础之服务网络

Istio基础之服务网格历史¶

一服务网格历史¶

要讨论服务网格（ Service Mesh ），就必须提到微服务。微服务（ Microservices )自2012年被提出以来，就继承了传统SOA 架构的基础，并在理论和工程实践中形成新的标准，热度不断攀升，甚至有成为默认软件架构的趋势。

1. 微服务应该具备的特点：¶

在结构上，将原有的从技术角度拆分的组件，升级为从业务角度拆分的独立运行的服务，这些服务具备各自的实现平台，并且独占自有数据，在服务之间以智能端点和哑管道的方式通信。
在工程上，从产品而非项目的角度进行设计，强调迭代、自动化和面向故障的设计方法。

2. 微服务的好处与坏处¶

2.1 好处¶

提高应用的伸缩性
方便部门或业务之间的协作
提高自动化程度，减少增耗

2.2 坏处¶

实例数量急剧增长，对部署和运维自动化要求更高
使用网络调用API，因此对网络依赖更强
调用链路变长，分布式跟踪成为必选（当然你不选，谁也没有办法）
日志分散，跟踪和分析难度加大
服务分散，易受攻击
自动伸缩、路由管理、故障控制、存储共享等。

[info]因此出现了kubernetes解决微服务架构产生的一些问题。在进程级别为微服务提供了部署、调度、伸缩、监控、日志等功能。但是通信和联系更加复杂了，其中的观测和服务质量保障成为微服务方案的短板，因此service mesh登场了。

3. SerivceMesh相关发展历程¶

3.1 Spring Cloud¶

2015年，Spring Cloud诞生。它定义了一系列的标准特性，如智能路由、熔断机制、服务注册与发现等。并提供了对应的库和组件来实现这些标准特性。

但Spring Cloud缺点也有，如下所示：

用户需要学习和熟悉各组件的“语言”并分别运维，增加了应用门槛。
需要在代码给别对组件进行控制，不能够多语言协作。
自身没有对调度、资源、Devops的相关支持。

3.2 Linkerd¶

2016年年初，由两位Twitter工程师开发了Linkerd项目，并打出了“The services must mesh”的口号，成为了Service Mesh的第一批布道者。

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

Linkerd相比先前说的Spring Cloud完成了以下：

无须侵入工作负载的代码，直接进行通信监视和管理。
提供了统一的配置方式，用于管理服务之间的通信和边缘通信。
对kubernetes的支持，当然还支持其它底层平台。

3.3 Istio¶

2017年5月，Goolge、IBM、Lyft宣布了Istio的诞生。Istio 以Envoy 为数据平面，通过S idecar 的方式让Envoy 同业务容器一起运行，并劫持其通信，接受控制平面的统一管理，在此基础上为服务之间的通信提供丰富的连接、控制、观察、安全等特性。

二服务网格历史¶

1. 服务网格定义¶

服务网格是一个专注于处理服务间通信的基础设施层，它负责在现代云原生应用组成的复杂服务拓扑中可靠地传递请求。

服务网格特点如下：
轻量级的网络代理
应用无感知
应用之间的流量由服务网格接管
服务间的调用可能出现的超时、重试、监控、追踪等工作下沉到服务网格层处理。

如下图所示：深色代表应用，清灰色代表网格中轻量级的网络代理。代理之间可以相互通信，而应用之间的通信完全由代理来进行。如果只看代理部分，可以看到一个网状结构，服务网格由此得名。网格一般由数据平面和控制平面组成，数据平面负责在服务中部署一个称为“边车”（sidecar）的请求代理，控制平面负责请求代理之间的交互，以及用户与请求代理的交互。

2. 服务网格优势

随着服务数量增长，每个服务都需要自己管理复杂的服务间的网络通信，也让开发人员头疼。也变得越来难以管理，这要求服务治理包含很多功能。例如：服务发现、负载均衡、故障转移、服务度量指标收集和监控等。