istio中的mixer架构进化

自 Istio 1.5 起，Istio 标准指标由 Envoy 代理直接导出。 在先前的 Istio 版本中，Mixer 生成了这些指标。

Mixer 提供三个核心功能：

前提条件检查。允许服务在响应来自服务消费者的传入请求之前验证一些前提条件。前提条件包括认证，黑白名单，ACL检查等等。
配额管理。使服务能够在多个维度上分配和释放配额。典型例子如限速。
遥测报告。使服务能够上报日志和监控。
在Istio内，由于Envoy只是个干活的小兵，因此它也重度依赖Mixer。

一，Istio遥测指标

1，代理级别

代理级指标是Envoy代理本身提供的有关所有直通流量的标准指标，以及有关代理管理功能的详细统计信息，包括配置和运行状况信息。

Envoy生成的度量标准存在于Envoy资源（例如侦听器和集群）的粒度级别上。

2，服务级别

除了代理级别的度量标准之外，Istio还提供了一组面向服务的度量标准，用于监控服务通信。这些指标涵盖了四个基本的服务监视需求：延迟，流量，错误和饱和。

Istio附带了一组默认的仪表板，用于根据这些指标监视服务行为。

二，Istio telemetry 进化

1，Istio telemetry with Mixer（1.4之前）

3131854764-5e951aca17c22.png

现有的 Istio 提供了名为 Mixer 插件模型用于扩展 Envoy 数据面功能，具体来说，在 Envoy 内部，Istio 开发了一个原生 C++ 插件用于收集和获取运行时请求信息并通过 gRPC 将信息上报给 Mixer，外部 Mixer 则调用各个 Mixer Adapter 用于监控、授权控制、限流等等操作，相关处理结果如有必要再返回给 Envoy 中 C++ 插件用于做相关控制。
Mixer 模型虽然提高了极高的灵活性，且对 Envoy 侵入性极低，但是引入了大量的额外的外部调用和数据交互，带来了巨大的性能开销（相关的测试结果很多，按照 istio 社区的数据：移除 Mixer 可以使整体 CPU 消耗减少 50%）。而且 Istio 插件扩展模型和 Envoy 插件模型整体是割裂的，Istio 插件在 out-of-process 中执行，通过 gRPC 进行插件与 Envoy 主体的数据交互，而 Envoy 原生插件则是 in-proxy 模式，在同一个进程中通过虚函数接口进行调用和执行。

2，Mixerless的实现—Istio Telemetry V2（1.5之后）

2159864391-5e951b79c2395.png

因此在 Istio 1.5 中，Istio 提供了全新的插件扩展模型：WASM in proxy。使用 Envoy 支持的WASM机制来扩展插件：兼顾性能、多语言支持、动态下发动态载入、以及安全性。唯一的缺点就是现有的支持还不够完善。

为了提升性能，Istio 社区在 1.5 发布中，已经将几个扩展使用 in-proxy 模型（基于 WASM API 而非原生 Envoy C++ HTTP 插件 API）进行实现。但是目前考虑到 WASM 还不够稳定，所以相关扩展默认不会执行在 WSAM 沙箱之中（在所谓 NullVM 中执行）。虽然 istio 也支持将相关扩展编译为 WASM 模块，并在沙箱中执行，但是不是默认选项。

所谓 Mixer V2 其最终目标就是将现有的 out-of-process 的插件模型最终用基于 WASM 的 in-proxy 扩展模型来替代。但是目前举例目标仍旧有较长一段路要走，毕竟即使 Istio 社区本身的插件，也未能完全在 WASM 沙箱中落地。但从 Istio 1.5 开始，Istio 社区应该会快速推动 WASM 的发展。

WASM

天下合久必分，分久必合，既然分开不好，那么很自然的就想要把Mixer的功能合并到Sidecar做，将遥测和服务鉴权能力下沉到每个服务的代理Proxy Envoy中。
这机智的大脑，那问题来了，Envoy是C++写的，Mixer是Go的，怎么把功能加进去？直接撸袖子再写一把C++吗？
纠结了很久，Envoy开始提供Web Assembly(WASM)的支持，成了扩展Envoy解药。那什么是Web Assembly，我的理解也不是很深刻，摘抄一下：

WebAssembly不是一门编程语言，而是一份字节码标准。WebAssembly字节码是一种抹平了不同CPU架构的机器码，WebAssembly字节码不能直接在任何一种CPU架构上运行，但由于非常接近机器码，可以非常快的被翻译为对应架构的机器码，因此WebAssembly运行速度和机器码接近。（类比Java bytecode）

Envoy支持了WASM后，无论用哪种高级语言写的各路Adapter，都可以编译成WASM，然后被Envoy加载，这样就避免了修改Envoy，也不再需要远程调用了。
也是被逼到没办法了，开了如此拍案叫绝的脑洞呀。

定制Metrics

大致分两步：

• 第一步，配置EnvoyFilter。
• 第二步，在pod中添加annotations。不难理解，由于遥测下沉到Envoy了，因此每一个pod都需要将想要让Prometheus监控的指标声明出来。

参考URL

https://www.jianshu.com/p/66b15778d9b5

https://blog.csdn.net/weixin_38754564/article/details/105803639

https://www.cnblogs.com/MinZhou/p/13129614.html

https://blog.51cto.com/12974849/2483218?source=dra

https://segmentfault.com/a/1190000022364575