第八章 Mixer 适配器的应用

概述： Mixer “知晓”每一次服务间的调用过程，这些调用过程会为Mixer提供丰富的相关信息，Mixer通过接入的适配器对这些信息进行处理，能够在调用的预检（执行前）和报告（执行后）阶段执行多种任务；并且Mixer的适配器模型是可以扩充的，这也赋予了Mixer更大的扩展能力。

1 Mixer的Service和Pod

　　三个service ： statsd、Policy、Telemetry。Mixer分为Policy和Telemetry两个子模块。Policy用于向Envoy提供准入策略控制，黑白名单控制，速率限制等相关策略；Telemetry为Envoy提供了数据上报和日志搜集服务，以用于监控告警和日志查询。

　　Mixer Policy和Mixer Telemetry很容易成为整个集群的性能短板，因为Envoy发起每个请求前都需要对Policy服务进行Check请求，一方面增加了业务请求本身的延迟，一方面也给作为单点的Policy增大了负载压力。如果追求性能，可以裁剪一些功能如速率限制，全局配额等，禁用Mixer的Policy。

• istio-policy：

　　       与envoy交互，Envoy会在每次请求发送前向Mixer Policy发送Check请求检查该请求是否收策略限制或者配额限制；不能直接关闭或者说禁能这个策略组   

         件，因为默认请求都是要去policy pods进行check检测的，如果失败则会导致请求失败；如果要禁能所有的policy策略检查，需要重新编辑整个服务网格的配                   置，并且重启pilot 容器。

• istio-telemetry：

               采集envoy上报的遥测数据，该组件挂掉将导致各监控运维插件无法采集到数据，同时，该组件在高并发情境下，会承受较大负荷，建议设置为多实例，增强           可靠性。Envoy每次请求接收后会向Mixer Telemetry上报本次请求的基本信息，如调用是否成功、返回状态码、耗时数据

• istio-statsd-prom-bridge：

              这个 statsd是一个转换为prometheus的组件，用来统计envoy 生成的数据，这个是必须的。

2 Mixer的check和report

• check：

　　envoy的每个前置请求都要到mixer中进行check，这个check必然会导致一些性能的降低。

        那么有些什么策略可以check，check完会如何？

　　首先要说明的是，这些策略的检测，是人为控制的，也就是并非是istio自带就有会这些策略需要检测，而是需要人为去配置一些策略。

　　envoy发起check请求的时候，会根据收到的请求生成指定的attributes，然后attributes作为参数之一向Mixer发起Check rpc请求。Mixer中如果有对应的adapter，则会进行处理然后返回响应结果，然后envoy根据结果决定是否执行请求或拒绝请求。

　　一些常见的check策略如：白名单检查、ACL检查、速率限制等，其实这些功能都是相对来说对业务更为友好的一些功能，所以，如果性能问题不是一个大的瓶颈下的话，这个组件最好还是保留较好。

• Report的Telemetry遥测数据

　　Envoy会向Mixer上报日志、监控（log、metrics）等数据，Envoy上报的原始数据都是一些属性词汇，然后Mixer会转换，最终会分发到logentry 和 Metric，Mixer后端的adapter（如prometheus）会基于遥测数据做进一步处理。

　　Proxy代理（Envoy sidecar）是在执行请求之后才需要Report，调用Mixer进行上报，这个属于后置上报，是异步的处理流程，模式是fire-and-forget，当然如果后端adapter处理不过来，无法Response给Envoy的话同样还是会影响到Envoy的性能。

　　遥测相关的后端包含：

• Tracing
• prometheus
• grafana
• serviceGraph
• Metrics
• Fluentd

      当然，prometheus、grafana、Tracing等可以直接通过envoy，而不经过Mixer；经过Mixer可以查询到更丰富的数据，当然缺陷就在于多了一层降低性能。

3 概念介绍：

　属性（Attribute）：

        大部分attributes由Envoy提供。attributes是有名称和类型的元数据，用来描述入口和出口流量和流量产生时的环境。attributes携带了一些具体信息，比如：API请求状态码、请求响应时间、TCP连接的原始地址等。

　　 为防止每次请求时Envoy都向Mixer中发送Check请求，Mixer中建立了一套复杂的缓存机制，使得大部分请求不需要向Mixer发送Check请求。

request.path: xyz/abc
request.size: 234
request.time: 12:34:56.789 04/17/2017
source.ip: 192.168.0.1
destination.service: example

　　https://preliminary.istio.io/docs/reference/config/policy-and-telemetry/attribute-vocabulary/

       https://github.com/istio/api/blob/master/policy/v1beta1/value_type.proto

　Adapter（适配器）：

　　adapters基于这些attributes来实现日志记录、监控指标采集展示、配额管理、ACL检查等功能。Istio内置的部分adapters举例如下：

• circonus：一个微服务监控分析平台。
• cloudwatch：一个针对AWS云资源监控的工具。
• fluentd：一款开源的日志采集工具。
• prometheus：一款开源的时序数据库，非常适合用来存储监控指标数据。
• statsd：一款采集汇总应用指标的工具。
• stdio：stdio适配器使Istio能将日志和metrics输出到本地，结合内置的ES、Grafana就可以查看相应的日志或指标了。

Template（模板）:　

　　对于一个网络请求，Mixer通常会调用两个rpc：Check和Report。不同的adapter需要不同的attributes，template定义了attributes到adapter输入数据映射的schema，一个适配器可以支持多个template。一个上报metric数据的模板如下所示：

 

Mixer的配置模型

　　Mixer的yaml配置可以抽象成三种模型：Handler、Instance、Rule

　　这三种模型主要通过yaml中的kind字段做区分，kind值有如下几种：

　　　　adapter:    参考adapter类型https://preliminary.istio.io/docs/reference/config/policy-and-telemetry/adapters/

　　　　template:  参考https://preliminary.istio.io/docs/reference/config/policy-and-telemetry/templates/

　　　　rule:  参考 https://istio.io/docs/reference/config/policy-and-telemetry/attribute-vocabulary/

　Handler：

　　一个Handler是配置好的Adpater的实例。

 　　{metadata.name}.{kind}.{metadata.namespace}是其完全限定名；

　　 每个adapter的配置信息格式是都有区别的， 可以参考： https://istio.io/docs/reference/config/policy-and-telemetry/adapters/， 查看配置格式。

     Instance：

　　Instance定义了attributes到adapter输入的映射　 

     Rule：

        Rule定义了一个特定的Instance何时调用一个特定的Handler

  一个配置的例子：　

　　 下面的例子定义的Rule为：对目标服务为service1.ns.svc.cluster.local且request.headers["x-user"] 为user1的请求，Instance: requestduration.metric.istio-system才调用Handler: handler.prometheus。

　　adapter:

apiVersion: config.istio.io/v1alpha2
kind: prometheus
metadata:
  name: handler
  namespace: istio-system
spec:
  metrics:
  - name: request_count
    instance_name: requestcount.metric.istio-system
    kind: COUNTER
    label_names:
    - destination_service
    - destination_version
    - response_code

　　instance:

apiVersion: config.istio.io/v1alpha2
kind: metric
metadata:
  name: requestduration
  namespace: istio-system
spec:
  value: response.duration | "0ms"
  dimensions:
    destination_service: destination.service | "unknown"
    destination_version: destination.labels["version"] | "unknown"
    response_code: response.code | 200
  monitored_resource_type: '"UNSPECIFIED"'

   rule:

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: promhttp
  namespace: istio-system
spec:
  match: destination.service == "service1.ns.svc.cluster.local" && request.headers["x-user"] == "user1"
  actions:
  - handler: handler.prometheus
    instances:
    - requestduration.metric.istio-system

Mixer工作流程源码分析：

 

转载于:https://www.cnblogs.com/liufei1983/p/10464032.html