4.1 Istio策略和遥测的原理
4.1.1 应用场景
想知道服务运行得怎么样、有没有问题、哪里有问题，涉及采集数据、存储数据和检索数据。
在Istio中，基于Mixer的遥测数据收集方式：有一个服务端组件Mixer, 在逻辑上将Envoy和各种遥测数据的收集解耦，并将Envoy和真正的遥测后端解耦。
4.1.2 工作原理
（1）Envoy生成数据并将数据上报给Mixer,比如生成一条服务A访问服务B的数据，包括时间、服务A的IP、服务B的IP等。
（2）Mixer调用对应服务后端处理收到的数据，例Mixer调用一个APM（Application Perfromance Monitor）的Adapter,将数据上报到APM后端。
在Mixer的Adapter里封装了对数据的处理逻辑和对后端服务的调用接口，Adatper的存在实体就是一个处理数据的二进制加一个配置的定义。Adapter提供通用接口供Mixer调用，然后将调用转到对应的后端服务。
4.1.3 属性
1 Istio属性定义: Envoy上报的数据在Istio中被称为属性，描述服务请求或者运行环境。比如，目标地址，请求应答码。每个属性包含属性名和属性类型：
source.ip : 173.456.567
Istio中有固定的属性词汇表。
2 Istio支持的属性表达式：如下表示把右边的属性赋值给左边的字段。
source_workload: source.workload.name
response_code: response.code | 200 // 如果没有取到值，可以使用默认值
source.labels["app"] == "forecast" && source.labels["version"] == "v2" // 是不是forecast服务V2版本的负载实例发起的请求。
reporter: conditional((context.reporter.kind | "inbound") == "outbound", "source", "destionation") // 看数据是从source还是destination上报的。
4.1.4 Mixer的配置模型
Istio主要通过Handler(业务处理)、Instance(数据定义)和Rule(关联规则)这三个资源对象来描述对Adapter的配置。
在Rule中定义了基于满足match条件的请求构造的Instance对象，并将Instance对象发送给配置的handler处理。
1 Handler：描述定义的adatper及其配置。不同的Adapter有不同的配置。
Handler是Adapter定义的这个模板的一个实现，通过给模板上的参数赋值来实例化。
Adapter是一种静态定义，handler是动态的实现，一个adapter可以有任意多个实现（也就是说一个adapter可以有多个Handler, handler中可以定义不同的属性，取不同的值）。
2 Instance：定义了Adapter要处理的数据对象，通过模板为Adapter提供对元数据的定义。
Mixer通过instance把来自代理的属性拆分并分发给不同的适配器。
3 Rule：配置一组规则，告诉Mixer有哪个Instance在什么时候被发送给哪个Handler来处理。
4.2 Istio遥测适配器配置
4.2.1 Prometheus适配器: Prometheus是应用最广泛的开源系统监控和报警平台。
4.2.2 Fluetd适配器： 开源日志数据收集器。
4.2.3 StatsD适配器：处理Metric的开源系统。
4.2.4 Stdio适配器：日志通过标准输出打印出来。
4.2.5 Zipkin适配器： 开源实时分布式调用链跟踪系统。
4.2.6 厂商适配器：主流的云厂商和性能运维监控厂商一般用Mixer提供的Adapter机制对接其后端专业系统。
4.3 Istio策略适配器配置
4.3.1 List适配器
黑名单 白名单
4.3.2 Denier适配器
满足条件的拒绝
4.3.3 Memory Quota适配器
设置一个时间段内的访问配额。
4.3.4 Redis Quota适配器
4.4 Kubernetes Env适配器配置
4.5 本章总结