Istio基础之服务网格历史

Istio基础之服务网格历史

一 服务网格历史

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

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

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

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

2. 微服务的好处与坏处

提高应用的伸缩性

方便部门或业务之间的协作

提高自动化程度，减少增耗

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

使用网络调用API，因此对网络依赖更强

调用链路变长，分布式跟踪成为必选（当然你不选，谁也没有办法）

日志分散，跟踪和分析难度加大

服务分散，易受攻击

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

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

3. SerivceMesh相关发展历程

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

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

用户需要学习和熟悉各组件的“语言”并分别运维，增加了应用门槛。

需要在代码给别对组件进行控制，不能够多语言协作。

自身没有对调度、资源、Devops的相关支持。

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的支持，当然还支持其它底层平台。

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

二 服务网格历史

1. 服务网格定义

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

服务网格特点如下：

轻量级的网络代理

应用无感知

应用之间的流量由服务网格接管

服务间的调用可能出现的超时、重试、监控、追踪等工作下沉到服务网格层处理。

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

2. 服务网格优势

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

Kubernetes 微服务

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。