Istio系列学习(十二)----istio策略和遥测的原理

一、应用场景

除了需要具备服务治理功能，还需要知道服务运行的怎么样、有没有问题、以及哪里有问题等。
这一般是APM的职能，设计数据采集、存储、检索。

1. istio基于mixer的遥测数据收集

在遥测数据采集场景下，Istio更前进了一步，将Envoy里的这部分 功能提取出来，放到一个服务端组件Mixer上，在逻辑上将Envoy和各种遥测数据的收集解耦，并将Envoy 和真正的遥测后端解耦。
应用、代理、遥测后端的关系如下图：

上面三种场景下mixer的表现：
◎ 场景 1:当 APM协议改变时，只需修改 Mixer对接的 Adapter的对应接口即可，数据面代理无须随 之变更。
◎ 场景 2:当某个 APM上报的数据格式发生变化时，只需修改 Adapter的数据定义即可，数据面代 理无感知。
◎ 场景3:在对接一个新的后端时，只需基于Mixer的Adapter机制开发一个对应的Adapter即可，数据 面代理无感知。

2. 基于mixer遥测数据收集的工作原理

mixer的adapter机制，主要流程如图：

每个经过 Envoy的请求都会调用Mixer上报数据，流程主要有两步：
1）Envoy生成数据并将数据上报给Mixer，例如Envoy生成一条服务A访问服务B的数据，包括时 间、服务A的IP、服务B的IP等
2）Mixer调用对应的服务后端处理收到的数据，例如Mixer调用一个APM的Adapter，通过这个 Adapter将数据上报到APM后端

Adapter里封装了对数据的处理逻辑和和对后端服务的调用接口，提供通用接口供Mixer调用，然后将调用转到对应的后端服务

3. 属性及其表达式

1 istio属性的含义
envoy上报的数据在istio中被称为属性，描述服务请求或服务运行环境的信息。
每个属性都包括一个属性名和属性类型，如下图：

2. Istio支持的属性表达式

把右边的属性赋给左边的字段，比如在Metric的数据中 收集的 response_code就是 response.code这个属性在请求中的取值，具体属性包括：

除了直接使用上面的属性，在 Istio 中允许基于表达式描述属性。例如

例如，若response.code为空， response_code就会被赋默认值200。
这在Mixer中是简单的表达式，实际上，在Metric的定义中经常 有这样一个reporter字段，可以通过如下表达式描述Metric是从source还是destination端上报上去的:

3. mixer的配置模型

通过handler(业务处理)、Instance(数据定义)和 Rule(关联规则)这三个资源对象来描述对Adapter的配置。
在Rule中定义了基于满足match条件的请求构造的Instance对象，并 将Instance对象发送给配置的Handler处理。

1 handler
首先mixer中是支持多种adapter的，不同的adapter有不同的配置，也可以看成是不同的模板。
handler就是对某模板的一个具体实现。

mixer支持如下图所示的adapter：

下面是stdio对应的adapter模板定义

handler是adapter定义的模板的实现，通过给模板上的参数赋值来进行实例化。一个adapter可以有任意多个实现。
如下图：

Handler对outputAsJson参数的赋值为true，表示使用JSON的格式输出。

handler的定义规则;
◎ name:必选字段，为Handler的名称，在Rule中引用的正是这个字段定义的Handler名称。
◎ compiledAdapter:必选字段，为进程内Adapter的名称，匹配Mixer的一个Adapter，其实就是
Adapter代码中的常量定义。
◎ adapter:必选字段，非进程内的Adapte名称，是Adapter代码中的常量定义。
◎ params:在 Handler中配置的参数。例如，本节的配置示例在 Stdio的 Adapter中定义了多个参数，
在Handler的Manifest中对参数进行配置。
◎ connection:配置对一个进程外的 Adapter 的连接信息，主要是一个 Adapter 服务的地址。当然， 根据Adapter的要求，还包括相关认证的配置。

2 instance
定义了Adapter要处理的数据对象，通过模板为Adapter提供对元数据的定义。
mixer通过instance把来自代理的属性拆分并分发给不同的适配器。
日志的instance配置如下图

nstance包括如下几个重要字段。
◎ name:必选字段，指Instance的名称。在Rule的Action定义中引用该名称表示对该Instance的引用。
◎ compiledTemplate:必选字段，指模板名，匹配编译模板名。
◎ template:必选字段，指模板名，匹配非编译模板名。
◎ params:必选字段，真正的参数定义。不同的模板会有不同的参数定义及不同的参数赋值和配
置。
◎ attributeBindings:用来配置将Adapter生成的属性映射到属性列表中。

3 Rule
配置匹配规则，告诉 Mixer有哪个 Instance 在什么时候被发送给哪个 Handler来处理。

如下所示为给stdio配置一个规则:将协议是HTTP或者gRPC的请求转发到Stdio这个Handler上，并且 通过logentry这个Instance定义处理的数据格式:

rule的规则定义主要包括两个字段：
1)match:是一个必选字段，表示匹配条件。Mixer在收到请求时会根据该条件来决定是否执行在 下面的actions中定义的动作。
如果未定义条件，则判定为总是匹配。当然，最常见的是使用属性的操作表达式来描述条件，
例如match(source.workload.name，“forecast*”)或者一般的context.protocol==“http”||context.protocol=="grpc"这种。
(2)actions:是一个数组，表示在满足条件后执行的动作。主要包括如下信息。
◎ handler:必选字段，Handler名称，需要是全名。
◎ instances:Instance 的全名，通过解析字段的取值来构造 Instance，并将构造的对象传给定义的
handler。