概述： 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遥测数据