一、Istio流量治理
目标:
以基础设施的方式提供给用户非侵入的流量治理能力,用户只需关注自己的业务逻辑开发,无须关注服务访问管理.
流量治理要解决的问题:
- 服务的负载均衡
2）同一个服务有两个版本在线，将一部分流量切到某个版本上
3）服务保护，如限制并发连接数、请求数、隔离有故障的服务实例等
4）动态修改服务中的内容
1、流量治理的流程：
控制面：
1）管理面创建流量规则
2）pilot将流量规则转换为envoy的标准格式
3）pilot将规则下发给envoy
数据面：
1）envoy拦截Pod上本地容器的Inbound和outbound流量
2）在流量经过envoy时执行对应的流量规则，对流量进行治理
二、负载均衡
定义:在服务发起方使用一个服务名发起访问的时候能找到一个合适的后端，把流量导过去。
1、传统的负载均衡方式
一般是在服务端进行。如浏览器访问一个web网站时，一般在网站的入口处有一个负载均衡器来做请求的汇聚和转发，如常用的nginx。
原理：服务的虚拟IP和后端实例通过一个静态配置文件来维护，负载均衡器通过健康检查保证客户端的请求被路由到健康的后端实例中。
2、微服务的负载均衡
主要流程：
1）服务注册：各服务将服务名和服务实例对应的信息注册到服务注册中心
2）服务发现：客户端发起服务访问前，以同步或异步的方式从服务注册中心获取服务对应的实例列表
3) 负载均衡：根据配置的负载均衡算法从实例列表中选择一个服务实例。
3、istio的负载均衡
跟微服务的方式类似，pilot就是服务注册中心，envoy执行负载均衡。
isito目前支持的负载均衡算法：轮询、随机、最小连接数算法
4、k8s中支持service的重要组件kube-proxy也是运行在工作节点的网络代理和负载均衡器。
三、服务熔断
非侵入，包括isito提供的连接池管理和异常点检测
1）连接池管理：限制某个客户端对目标服务的连接数、访问请求数，避免对一个服务过量访问，如果超过配置的阈值，则快速断路请求。限制重试次数，避免增加系统压力。
2）异常点检测：如果服务实例平凡超时或出错，则将该实例隔离，不再对外提供服务。一段时间后再尝试重新启用。但istio可以控制驱逐比例：
当有太多实例被驱逐时，就会进入恐慌模式，这时会忽略负载均衡池上实例的健康标记，仍然会向所有的实例发送请求，保证服务的整体可用。
如 通过istio的连接池管理控制fronted服务队forecast服务的请求
1）fronted服务对目标服务forecast的请求不超过配置的最大连接数时，放行
2）fronted服务对目标服务forecast的请求超过配置的最大连接数时，但小于配置的最大请求等待数时，进入连接池等待
3）fronted服务对目标服务forecast的请求超过配置的最大请求等待数时，直接拒绝。
四.故障注入
故意在待测试的系统中引入故障，从而测试其健壮性和应对故障的能力。
实现方式：
1）编译期故障注入，需要通过修改代码来模拟故障。
2）运行期故障注入，运行阶段触发。而在分布式系统中，最常用的方法就是在网络协议栈中注入故障。
istio就是采用该方式：在网格中对特定的应用层进行故障注入，虽然在网络访问阶段进行注入，但其作用于应用层。
httpcode注入实例：
慢响应注入实例
五.灰度发布
原因：技术上产品的稳定性或商业上考虑新版本被用户接受的程度，直接将老版本全部升级是有风险的。所以一般做法是，新老版本同时在线，新版本只接入少量流量。
典型场景包括蓝绿发布(新的替代老的)、ABtest(两个新对比)、金丝雀(只有新)。
三者的核心都是流量的管理，能否支持灵活的流量策略是核心。有如下几种方式：
1、基于负载均衡的灰度发布
该方式要求负载均衡器必须支持相应的流量策略，并且只能对入口的服务做灰度，不支持对后端的服务单独做灰度发布。
2、基于k8s的灰度发布
如：forecast服务的两个版本v2和v1分别有两个和3个实例，流量被均衡的分发到每个实例上时，v2得到40%流量，v1则60%。
问题：
1）要求分配的数量必须和pod的数量成比例
2）不支持根据请求的内容来分配流量，比如要求chrome和Ie的请求分别访问不同版本
3、基于istio的灰度发布
灰度发布是istio流量治理规则的一种典型应用。istio在每个pod中都注入了envoy，因此只要在控制面配置分流策略，对目标服务发起访问的每个envoy都会执行流量策略，完成会发布功能。
pilot中配置recommendation中80%流量到v1版本，20%到v1；pilot将规则下发到每个数据面的envoy。
istio也支持基于请求内容的灰度策略。如根据header中的内容将请求分发到不同的版本上。