ServiceMesh-Istio：2. Istio架构和原理
文章目录
认识Istio
Istio 中文文档： https://istio.io./zh/
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Tm6MVsbE-1581645538909)(/Users/zck/Library/Application Support/typora-user-images/image-20200206141255635.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YcLB4gr9-1581645538909)(/Users/zck/Library/Application Support/typora-user-images/image-20200206141312545.png)]
Istio 架构
Istio的核心就是一个代理，不过跟我们熟悉的Nginx代理不一样，这个代理是针对每个服务，在kubernetes里面针对的是每个pod,一个pod 一个网络代理，利用了pod中容器共享网络的机制，通过某种手段完全接管pod的网络，让服务的进出流量都经过代理。这样就可以做很多事情。
有了代理，还需要一个对这些代理统一管理的组件，毕竟手动更新每个代理的配置是不现实的。kub ernetes集群的情况如下：每个pod 的网络都被上面的控制中心管理起来。
再看Istio更细致的架构看图说话，上面是数据平面，下面是控制平面，
数据平面
数据平面就是由一系列的代理组成。这些代理控制微服务之间所有的网络通信以及各种策略。ServiceA和ServiceB通信的时候，这个两个pod的里面都有一个Proxy组件，他们之间的通信会通过Poxy进行转发通信。并且Porxy通信支持很多协议：http/1.1、http/2,grpc tcp,覆盖了主流的网络通信协议。
控制平面
控制层面由很多模块组成：管理流量、管理路由策略、搜集检测数据的、校验配置、负责通信安全功能非常多。
组件解释
Proxy
Istio的Proxy选择使用Envoy (c++开发的开源代理组件)作为网络代理。来管理出口流量和入口流量。Envoy有非常多的功能动态服务发现 、负载均衡、多种协议的支持、断路器、流量分割、健康检查、故障模拟、健康指标等，Envoy以sidecar( 边车模式)的形式部署在每个pod中，负责完成Istio的核心功能-代理转发。
如果把Istio比作一个公司，Envoy就是这个公司的一线员工，所有的具体工作都是他们干的
Pilot
不可获取模块Pilot,好比Envoy的直接领导，Pilot会给你Envoy提供一些帮助，告诉Envoy怎么干活。
上面说到Envoy有很多功能服务发现 、负载均衡…但是它自己是跑在一个容器里面的什么信息也不知道，就没办法工作。Pilot就是给他提供信息的。告诉它集群都有什么服务，他就可以做服务发现了。告诉它哪些pod需要多少流量，它就可以做AB测试蓝绿部署，告诉它多长时间算是超时，应该重试几次。这些功能它就能很好的完成。
用户可以通过客户端通过Pilot配置流量管理，Pilot根据用户的配置和服务信息转换成 Envoy可以识别的格式，然后分发给它们，最后由Envoy实现用户期望的行为。
Pilot和Envoy有了，Istio就可以转起来了，其他的不需要也行。他俩是核心。
Mixer
Mixer独立组件，两大功能：策略和遥测。
策略：为整个集群提供访问控制，哪些用户访问哪些服务，还有策略的管理。比如像对服务的访问限制，一个服务最多接收100QPS，超过就拒绝。策略都是通过kubernetes的配置描述的，策略不是必须的没有策略就没有策略约束。
遥测：负责数据的搜集和汇报。可以看图中的箭头是从Proxy搜集服务之间流转的数据。汇报给的对象非常多，每个对象有一个Adapter(适配器)：把数据转成后端认识的格式；常见的Adapter有Prometheus、circonus、cloudwatch、statsd、stdio。汇报的数据为：请求哪里发出，发给谁，使用什么协议，请求的延时响应状态码等。
Mixer不是必须的，不需要它也能跑起来Istio。
Gally
最开始负责验证配置，Istio1.1之后升级为控制平面的配置管理中心。主要目的其他所有的Istio组件与具体的底层平台比如kubernetes 配置细节隔离开来，相当于一个后勤的工作。
Citadel
负责安全的相关的工作，可以为服务之间通过安全的通信，可以让http服务无感知升级成https,还有访问授权r bac 的访问控制。Citadel也不是必须的，网络是安全的业务上也不需要网络的控制就完全可以忽略这个功能。
Istio解决的问题
架构和产品的都是要解决具体的问题。Istio主要解决微服务问题而生的。
故障排查
- 原来的单个服务才分出多个微服务，它们之间相互调用才能完成一个任务，而一旦某个过程出错，出错越多出错概率越大，就会难以排查。
- 用户请求：两种错误，一个是请求错误，和慢响应。如果请求错误我们得知道哪个步骤出错了，这么多的微服务怎么确定哪个成功哪个没有调用成功。
- 响应慢，哪个地方响应慢，整个链路的耗时是多少，哪些是并发执行的，哪些是穿行执行的，我们必须清楚整个集群的调用和流量情况。
应用容错性
- 没有设置timeout；微服务才分成多个组件之后如果单个组件出现概率不变，那么整体出错的概率就会增加。服务调用如果没有错误处理机制，就会导致非常多的问题，比如应用没配置超时参数，就导致请求的调用链超时叠加。对于用户来说就是请求卡住了。
- 没有重试机制，因为某种原因导致一些偶尔出现的故障，会知道导致把错误返回给用户页面，造成非常不好用户体验。
- 某些节点异常，比如网络中断，负载很高，也会导致整体的响应时间变长，这就需要我们的服务自动避开这些节点上的应用。
应用升级发布
- 当我们应用增多，对于日常发布就是一个难题，应用的发布需要我们非常谨慎，如果应用一次性升级的，一旦出错影响范围非常大。
- 无法进行AB测试，根据用户属性访问不通版本。
- 服务版本的依赖关系处理不当导致服务不可用。服务升级改动了API，并且服务之间有相互依赖。那么还想希望自动控制发布期间不同的版本访问不同应用，这些问题都需智能的流量控制机制。
系统安全
- 为了保证系统安全，每个应用都要实现一套相似的认证授权,https,限流等等这样的功能。
- 没有流量控制，任何人都可以对服务发起攻击。
如果把上面的问题和Istio 的功能做一个映射，它们会非常匹配。
