背景
ISTIO 早期版本(1.4以前)的架构非常优雅， 模块之间解耦清晰，职责分明。 但现在看来有一定理想化，所有流量通过Mixer，通过Mixer 统一采集和上报所有的遥测数据和服务间访问鉴权，导致一旦规模上来，Mixer 非常容易成为性能瓶颈。
Telemetry V2介绍
在1.4中，ISTIO提出 Mixer-less telemetry 架构，将Mixer 从主流程抽离。 将遥测和服务鉴权能力下沉到每个服务的代理Proxy Envoy中。了解ISTIO 以前架构的同学应该都知道，Mixer 是一个热拔插组件，有极好的扩展性。 支持代码中注册编写Adapter并重新打包的方式更新遥测对接的配置，也支持配置 Out Of Process Adapter 这样的外部适配器，进行遥测的对接和动态配置。但提供灵活性同时，也成为了整个ISTIO 明显的性能瓶颈。
Istio 中Telemetry V2的实现
那么ISTIO 1.4 是如何实现 Mixerless 的呢？
在1.4中， 服务的遥测和访问鉴权从Mixer逐渐开始下沉到Envoy中， 从而经过我们应用的出入流量不必全部上报到Mixer，实现了Mixer 旁路。 服务遥测在Envoy中完成追踪服务之间的流量请求，并在Envoy所在Pod中监听相关端口，提供Prometheus采集指标。
那么在ISTIO 支持EnvoyFilter 这个CRD，它提供一种机制，可以帮助我们定制 Pilot 所生成并下发给Envoy 配置，在EnvoyFilter中我们能够定义生效的pod范围，注入的时机以及执行内容。 同样EnvoyFilter支持WebAssembly, 我们可以通过EnvoyFilter 配置WebAssembly的执行时机，实现Envoy 的流量管理策略的更新， 例如： https://istio.io/blog/2020/deploy-wasm-declarative/ 。
目前在ISTIO 维护的Envoy proxy中， 支持部分内置的WebAssembly 扩展， 目前有4个内置WebAssembly扩展（access_log_policy，stackdriver， stats，metadata_exchange）代码： https://github.com/istio/proxy/tree/master/extensions
- 其中access_log_policy，stackdriver 是用于往Google StackDriver推送数据
-
metadata_exchange和stats 用于遥测。
- metadata_exchange 会做reqeust和response的上下游标记，记录请求
- stats 采集请求相关监控指标，暴露Prometheus 可采集的接口。
阿里云服务网格
阿里云服务网格 目前已经通过Telemetry V2的方式支持Prometheus 监控遥测，您可以在控制台一键开启或者关闭遥测功能，并将监控数据采集到自建Prometheus 或者 阿里云ARMS 中。
阿里云服务网格动态配置遥测
查看请求数据的监控大盘
