13-1 什么是ServiceMesh？什么是Istio？

微服务好了，serviceMesh也火了。

过去(基于发布课程时)一年关于serviceMesh的评估、炒作的一年。

重视程度挺溜在评估阶段。

具体实际功能的serviceMesh在普及之后，有望在运行时，帮助运营人员更轻松的管理基于微服务架构的应用程序。

serviceMesh有望在此趋势来临之前，系统了解下。

一个概念、理论层面，随着微服务而来，微服务火了带来很多新问题，比如服务发现、负载均衡、路由、流量控制、服务之间的可用性、监控等需要解决的问题，出现了API网关，可以集中式的把服务配置管理起来，解决上述的一部分问题，但有个单点问题，容易成为系统的瓶颈，实现起来也会越来越臃肿。

慢慢出来了serviceMesh的概念。

上面说的问题，本质都是一个问题，网络问题。

所以想，能不能把网络从功能代码中抽离出来呢，让它自己去实现服务发现、负载均衡、路由、流量控制、熔断，去确保通信的安全，让应用开发者不再关注这些底层与业务无关的东西，甚至完全感知不到这一层的存在？这种东西叫做serviceMesh。

serviceMesh还是空中楼阁，需要去实现它。

目前，有两个非常知名的serviceMesh实现。

服务网格项目。

Linkerd基于rust和go开发。

目前支持K8S上部署的服务、consul、虚拟机。

在sidecar模式下，每个服务都会被分配一个单独的代理，服务间的通信并不是直接进行了，而是通过自身的代理进行转发，代理会将请求的数据路由到目标服务的代理，该代理再将请求转发到目标的微服务。

所有这些服务代理构成了数据层，有了数据层就要有一个负责管理数据的控制层，控制层用来对数据层进行配置和监控，控制层一般独立部署。

稳定性、功能丰富程度、社区支持。Istio更胜一筹。

13-2 Istio架构和原理

核心:代理

这个代理针对每一个服务。

K8S中的代理针对POD，一个POD一个网络代理，利用POD共享网络的机制，通过某种手段让代理能完全接管POD的网络，让服务的进出流量都经过代理，这就能做很多事情了。

有了代理之后，还需要对这些代理统一管理的组件，毕竟手工更新每个组件是不现实的。

这张图K8S的基本情况。每个POD的网络都被上面的控制中心管理起来了，这就是istio的简易模型。

上面是数据平面，下面是控制平面。

数据平面由一系列代理组成，这些代理控制微服务之间的所有网路通信以及各种的策略。

这俩POD通信时，每个POD都有一个proxy组件，它们之间的通讯根据proxy转发，并且在proxy之间支持很多的协议(http1/http2/grpc/tcp，覆盖了主流的通信协议)。

下面控制平面由很多模块组成。

管理流量、路由策略、搜集检测数据、校验配置、负责通信安全的等。

首先看proxy代理，默认，istio选择开源的envoy(c++高性能代理组件，用于管理所有服务的出入口流量)，envoy本质上并不属于istio，2016发布1.0还没istio，是istio选择了envoy作为istio的网络代理，因为envoy内置的功能，比如服务发现、负载均衡、多种协议支持、断路器、流量分隔、健康检查、模拟故障、监控指标等。envoy就会以sidercar的形式部署在每一个POD中，负责完成istio的核心功能。

如果把istio比作一个互联网公司，那么envoy就是互联网的一线员工，所有具体工作envoy干。

不可或缺的模块:pilot。pilot好比是envoy的直接领导，pilot会给envoy提供一些帮助，告诉其如何工作。envoy内置的很多功能，envoy自己是跑在一个容器中的，什么信息都不知道，没法工作。pilot就是给envoy提供信息的，告诉envoy什么样的服务可以做服务发现、哪些POD需要多少流量，就可以做A/B测试、蓝绿部署，多久超时，重试几次。

在客户端用户可以给pilot配置流量管理，pilot去根据用户的配置和它得到的服务信息转换成envoy可以识别的格式，然后分发给envoy。最终由envoy实现用户期望的行为。

pilot和envoy有了，istio就可以转起来了，别的组件也不需要。这俩是istio的核心。

Galley最开始只是负责验证配置。在istio1.1之后升级为整个控制平面的配置管理中心，配置验证功能依然在运行，主要是校验各种配置是否正确。

配置管理的目的就是将其他所有的istio组件与具体的底层平台，比如给K8S的配置细节隔离开来，相当于后勤的功能。

Citadel主要功能是安全相关的，可以为用户到服务，服务到服务之间，提供安全的通信，可以让HTTP服务无感知的升级成HTTPS，还有服务的访问授权，包括IP ACL(访问控制列表)的访问控制，这些功能也不是必须的，如果某网络是安全的，也不需要权限的控制，那么就可以完全忽略这个Citadel功能。

如果以前的单个应用拆分成了多个微服务，它们之间相关调用才能完成一个任务，而一旦某个过程出错，组件越多，出错概率就越大，就会非常的难以排查。

用户请求出现问题两种:

错误:请求错误要知道哪个节点出错了，服务如此错，怎么知道哪个调用成功/失败呢？

与

慢响应。

如果是请求响应太慢，就需要知道哪些地方比较慢，整个链路各个阶段的耗时是多少？哪些调用并发执行，哪些串行的？

需要非常清楚整个集群的调用及流量情况。

微服务拆分成多个组件之后，如果单个组件出错的概率不变，那么整体出错的概率就会增加，服务调用的时候，如果没有错误处理机制，那么会导致非常多的问题。

比如应用没有配置超时参数，或者配置的不正确，就会导致请求的调用链超时叠加，对用户来说就是请求卡住了。

没有重发机制，偶发性的故障，也会把错误返回给用户，造成非常不好的用户体验。

导致整体的响应时间变长。

那么，就需要服务能自动的避开这些有问题节点上的应用。

当应用数量增多，对于日常的发布很难，也需要很谨慎。

如果应用都是一次性升级的，出现错误就会导致整个线上应用不可用，影响范围非常大。

而且很多情况，需要同时存在不同的版本，使用A/B测试来尝试哪个版本更好。

如果版本升级，改动了API，并且服务之间有相互依赖，那么还希望自动的控制发布期间不同的版本访问不同的应用。

这些问题，都需要智能的流量控制机制。

为了保证系统的安全，每个应用都要实现一套相似的功能，比如认证授权、HTTPS、限流等相似功能。

大多数程序猿对安全并不擅长，但功能又相似，每次都要实现一遍，非常冗余。

所以需要一套能把安全管理起来的系统。

这些，就是istio尝试解决的问题/提供的功能，毕竟这些是istio为解决微服务的问题才出现的。