Istio简介
Istio提供了完整的非侵入式的微服务治理解决方案，解决微服务的管理、网络连接以及安全管理等应用网络治理问题
无需修改代码就能够实现微服务的负载均衡，服务与服务之间的认证授权以及流量的监控和治理。从整个基础设施角度上看，可以将它理解为PaaS平台上的一个面向微服务管理平台的补充。
Istio与Kubernetes
Kubernetes提供了部署、升级和有限的运行流量管理能力，利用service的机制来做服务注册和发现，转发，通过kubeproxy有一定的转发和负载均衡能力。但并不具备上层如熔断、限流、降级、调用链治理等能力。
Istio则很好的补齐了Kubernetes在微服务治理上的这部分能力，同时是基于Kubernetes构建的，但不是像SpringCloud Netflix等完全重新做一套。
Istio流量管理能力介绍
Istio，用于连接、保护、控制和观测服务
1、 服务连接
如上图所示的Istio架构图，让我们关注控制面的Pilot，它是Istio实现流量管理的核心组件。
而在数据面，每个Pod，都会被注入1个Proxy。Istio通过Pilot下发配置信息给数据面每1个Pod的Proxy，从而通过这些Proxy，间接地控制每1个Pod之间以及和外部的连接。Proxy通常采用另一个知名的开源项目Envoy来实现。
1个Pilot和(N+N)个(Service+Proxy)组合，便形成了Service Mesh，即服务网格。有了这一套服务网格系统，对服务之间的流量进行管理，便不在话下。
2、流量管理
从服务间的流量管理角度而言，Istio可以实现这4项功能：请求路由、服务发现和负载均衡、故障处理和故障注入。
A.请求路由
Istio引入了Version的概念，可以通过(Current Version，Canary Version)对服务进行进一步细分。基于这种划分，通过Pilot，可以下发配置到Service A的Proxy，使得其95%的流量路由至Service B的Current版本，5%的流量路由至Service B的Canary版本。当然也可以选择雨露均沾，各分50%流量，或者霸道总裁，让Canary版本占有100%的流量。
除了按照百分比在不同版本之间分发流量，你还可以按照请求内容，将请求路由至不同的版本。
这一切改变，都只需要你改动一个叫VirtualService的配置文件，眨个眼的功夫，Istio就已经通过Pilot帮你把新的配置下发下去了。
** B.****服务发现和负载均衡**
服务网格存在3个生命周期的动态循环：服务注册、服务发现、负载均衡。
kubernetes容器管理平台已经提供了服务注册表，以跟踪服务的负载实例，所以Pilot能轻而易举地获知服务网格内的所有服务注册信息，并将这些信息告知所有服务里的Proxy，Proxy根据这些信息执行服务发现，动态更新其负载均衡池。一个服务通常有多个负载实例，Service A请求Service B时，可以配置不同的负载均衡模式：轮询、随机和带权重的最少请求。
假设此时Service B的某个负载实例出现故障，因为Service A中的Proxy会定期地执行服务发现，从而能及时将故障实例从其负载均衡池里排出。
C.故障处理
Envoy 提供了一套开箱即用，可选的故障处理功能，对应用中的服务大有裨益。这些功能包括：
- 超时机制
- 具备超时预算，并进行有限重试，重试之间的时长可抖动
- 并发连接数和上游服务请求数限制
- 对负载均衡池中的每个成员进行主动（定期）运行健康检查
- 细粒度熔断器（被动健康检查）- 适用于负载均衡池中的每个实例
以Service A请求调用Service B为例。
对于功能1。若Service B明确地知道10s以后的超时，必定会带来失败，那将超时时长缩短，使得Service A可以更快得知结果并作出应对，不失为一个明智之举。
对于功能2。对超载的Service B来说，重试之间的抖动极大的降低了重试造成的影响，而超时预算确保Service A在可预测的时间范围内获得响应（成功/失败）。
对于功能3。限制Service A或其他服务对Service B的连接数和请求数，可以使得Service B免于遭遇DDOS攻击，或承受过重的流量负担而崩溃。
对于功能4和5。主动和被动健康检查的组合最大限度地减少了在负载平衡池中访问不健康实例的机会。当与平台级健康检查（例如由 Kubernetes 或 Mesos 支持的检查）相结合时，应用程序可以确保将不健康的负载实例快速地从服务网格中去除，从而最小化请求失败和延迟产生影响。
总之，这些功能使得服务网格能够耐受故障节点，并防止本地故障导致的其他节点的稳定性下降。
D.故障注入
虽然Proxy为在Istio上运行的服务提供了上节所言的大量故障处理机制，但测试整个服务网格所组成应用的端到端的故障恢复能力依然是必须的。错误配置的故障恢复策略（例如，跨服务调用的不兼容/限制性超时）可能导致应用程序中的关键服务持续不可用，从而破坏用户体验。
Istio 能在不杀死负载实例的情况下，将协议特定的故障注入到网络中，在 TCP 层制造数据包的延迟或损坏。我们的理由是，无论网络级别的故障如何，应用层观察到的故障都是一样的，并且可以在应用层注入更有意义的故障（例如，HTTP经典的4xx和5xx错误代码），以检验和改善应用的韧性。
运维人员可以为符合特定条件的请求配置故障，还可以进一步限制遭受故障的请求的百分比。可以注入两种类型的故障：延迟和中断。延迟是计时故障，模拟网络延迟上升或上游服务超载的情况。中断是模拟上游服务的崩溃故障。中断通常以 HTTP 错误代码或 TCP 连接失败的形式表现。
依旧以Service A请求调用Service B为例。
若给Service B设定了10s的延时或503中断，则Service A将至少10s后才能得到请求的响应或请求的响应为503错误，通过多种场景覆盖测试，可以得到Service A面对这些场景时的综合表现情况，从而做出针对性的改良，增加其韧性。
3、Istio实践
Istio有4个配置文件，帮我们全方位地定制以上所有流量管理需求: VirtualService, DestinationRule, ServiceEntry和 Gateway:
- 通过配置VirtualService，可以实现请求路由的功能；
- 通过配置DestinationRule，可以实现服务发现和负载均衡、故障处理和故障注入的功能；
- 通过配置ServiceEntry，让服务网格内的服务，可以看到外面的世界；
- 通过配置Gateway，让服务网格的服务，可以被全世界看到；
有了以上4大法宝，我们对服务网格进行流量管理的所有需求，都可以被满足了。
75%的概率走向helloworld的v1版本，以25%走向v2版本
apiVersion:networking.Istio.io/v1alpha3
kind:VirtualService
metadata:
name:helloworld
spec:
hosts:
- helloworld
http:
- route:
- destination:
host:helloworld
subset:v1
weight:75
- destination:
host: helloworld
subset: v2
weight: 25
apiVersion:networking.Istio.io/v1alpha3
kind:DestinationRule
metadata:
name: helloworld
spec:
host: helloworld
subsets:
- name:v1
labels:
version: v1
- name: v2
labels:
version: v2
访问www.baidu.com来获取一些信息
apiVersion:networking.Istio.io/v1alpha3
kind:ServiceEntry
metadata:
name: baiduapis
spec:
hosts:
- "*.baidu.com"
ports:
- number:443
name:https
protocol:http
apiVersion:networking.Istio.io/v1alpha3
kind:DestinationRule
metadata:
name: baiduapis
spec:
host: "*.baidu.com"
提供外部路由
apiVersion:networking.Istio.io/v1alpha3
kind:Gateway
metadata:
name: helloworld-gateway
spec:
selector:
Istio:ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- 'helloworld.com'
apiVersion:networking.Istio.io/v1alpha3
kind:VirtualService
metadata:
name: bookinfo
spec:
hosts:
- 'helloworld.com'
gateways:
- helloworld-gateway
http:
- route:
- destination:
host: helloworld
port:
number: 9080
