Adapter与mixer代码需要一起打包编译，最终生成 一个可执行文件。 Adapter作为grpc服务端，运行在独立的pod当中， Mixer通过通过rpc调用，将属性与日志发送给Adapter。基于Mixer的二次开发的流程 • 编写grpc服务端程序，接收来自mixer的数据，并实现自身业务逻辑 • 编写handler、instance、rule配置文件 • 编译打包adapter，上传至docker仓库 Handlers 。为适配器提供配置。例如，到后端的 URL 、证书、缓存选项等等。基于Mixer的二次开发Instances Instances。属性映射。基于Mixer的二次开发Rules Rules。将数据交付给适配器。 定义了一个特定的 Instance 何时调用一个特定的 Handler插件编译和镜像打包 插件的编译 CGO_ENABLED=0 GOOS=linux GOARCH=amd64

io/docs/envoy/latest/configuration/http/http_filters/http_fi lters ○ …. ● 自定义开发： ○ 静态预编译： ■ 将其他过滤器集成到Envoy的源代码中，并编译新的Envoy版本。 ■ 这种方法的缺点是您需要维护Envoy版本，并不断使其与官方发行版保持同步。 ■ 此外，由于Envoy是用C++实现的，因此新开发的过滤器也必须用C++实现。 6 使用Wasm for Proxy ● Pros ○ 敏捷性：过滤器可以动态加载到正在运行的Envoy进程中，而无需停止或重新编译。 ○ 可维护性：不必更改Envoy自身基础代码库即可扩展其功能。 ○ 多样性：可以将流行的编程语言（例如C/C++和Rust）编译为WASM，因此开发人员可 以选择实现过滤器的编程语言。 ○ 可靠性和隔离性：过滤器会被部署到VM沙箱中，因此与Envoy进程本身是隔离的；即使 Filter出现问题导致崩溃时，它也不会影响Envoy进程。 ○ 安全性：过滤器通过预定义API与Envoy代理进行通信，因此它们可以访问并只能修改有 限数量的连接或请求属性。 ● Cons ○ 性能约为C++编写的原生静态编译的Filter的70％; ○ 由于需要启动一个或多个WASM虚拟机，因此会消耗一定的内存使用量; ○ The WebAssembly ecosystem is still young; 7 Wasm

Envoy原始项目的clone，在 https://github.com/istio/envoy.git • Istio中适配所使用的的插件 https://github.com/istio/proxy.git • 编译时由proxy项目作为入口，自动引用envoy项目 • 主要框架代码位于envoy项目，包含进程启动，线程 及网络、主要过滤器框架，观测数据处理等。 • 启动入口点位于envoy项目 source/exe目录下 out.perf; stackcollapse-perf.pl out.perf > out.folded; flamegraph.pl out.folded > cpu.svg • 镜像修改 • 编译pilot-agent, envoy二进制后替换现有envoy镜像并配置到自定义deployment的image中， • Dockerfile: • From istio/proxyv2:1.9