rights reserved. Page 5 Envoy介绍 • Envoy采用C++实现，本身为四层及七层代理，可以根据用户应用请求内的数据进行高级服务治理 能力，包括服务发现、路由、高级负载均衡、动态配置、链路安全及证书更新、目标健康检查、 完整的可观测性等。 • 目前常见数据面主要有三种：Envoy、Linkerd、Traefic。Envoy由于高性能和扩展能力前在数据面遥 遥领先。 • 。 • 2. 控制面通信 • Pilot-agent进程本身创建UDS接收Envoy连接，用于证书更新下发。并且与istiod建立证书更新通道。 • Envoy 通过pilot-agent转发机制与istiod建立长连接，通过xDS协议接收系统下发的监听器、路由、集群节点等更新信息。 • 3. 数据面通信 • 客户端请求进入容器网络，并被iptables规则拦截，经过DNAT后进入Envoy 定期将工作线程内监控数据stat进行合并 • 定期刷新DNS信息，加速域名解析。 • 目标cluster内主机列表健康状态判断。 • worker线程： • 通过启动配置参数concurrency指定，不支持动态调整。 • 启动virtualoutbound/virtualinbound网络监听，每个工作线程都对此监听端口进行监听。 由内核随机挑选监听线程处理新连接。 • 进行连接负载均衡处理后，选择最终的业务监听器处理新连接。

FreeWheel的Istio实践 • 未来工作 • FreeWheel的痛点 Istio架构 • Istio Proxy: 劫持Pod的所有通信， 是Mesh的基础 • Pilot: 为Proxy提供动态配置管理 • Citadel: 自动维护mTLS密钥 • Mixer: 在k8s中部署了两组Mixer • Policy提供授权、Quota等能力 • Telemetry提供监控数据收集能力 基本原理 • Istio从架构上可以分为4个板块： • Istio Proxy: Mesh的基础 • 网络安全：兼容Spiffe标准实现 • 配置管理：为C++实现的Proxy接 入k8s的动态配置管理 • Attribute Machine: 授权，Quota ，Tracing，监控的基础 Istio管理下的微服务 • 右图是部署mock1.v1 Pod之后发生的事 情： • Pilot: 和Sidecar建立连接，管理动态配 置 • Mixer: 和Sidecar建立连接，管理授权 、Quota和审计数据 • Istio的架构和基本原理 • FreeWheel的Istio实践 • 未来工作 • FreeWheel的痛点 FreeWheel的Istio实践 • 在FreeWheel，我们已经有一套复杂的自定义认证、授权机制，为了 充分利用Istio，我们通过

Listener Downstre am Filter Filter Filter Cluster Upstrea m Filter Chain 扩展自定义Filter, 并通过xDS API动态配置 L4 Network Filters L7 Http Filters 3 Listener & Filters before outbound services Listener Downst 的过滤器也必须用C++实现。 ○ 动态运行时加载： ■ 在运行时将新的过滤器动态加载到Envoy代理中。 ■ 简化了扩展Envoy的过程, 这种解决方案通常使用WebAssembly（WASM）的新技术， 它是一种有效的可移植二进制指令格式，提供了可嵌入和隔离的执行环境。 6 使用Wasm for Proxy ● Pros ○ 敏捷性：过滤器可以动态加载到正在运行的Envoy进程中，而无需停止或重新编译。 由于需要启动一个或多个WASM虚拟机，因此会消耗一定的内存使用量; ○ The WebAssembly ecosystem is still young; 7 Wasm in Envoy Proxy ● Wasm动态加载 ● 一致性校验: ○ https://github.com/pr oxy-wasm/spec ● 内置的Wasm runtime ○ ~20MB for WAVM ○ ~10MB for

运维架构能力是否具备可移植性？是否能低成本复制新的产品线？ l 可观测性不足，是否有通用机制提升产品线可观测性？ Ø 部分模块上下游超时配置不合理，超时倒挂，集中管理调整成本比较高。 Ø 多数模块对单点异常，慢节点等异常缺乏容忍能力，推动每个模块独立修复，成本高，上线周期长。 Ø 因重试导致雪崩，底层RPC框架需要重复建设来定制动态熔断能力。 Ø 升级一级服务建设中，发现很多模块单点、多点故障不能容忍，能否低成本解决？ 主要介绍如下几个方面： l 稳定性方面 （单点，多点，防雪崩，长尾优化，架构故障韧性能力） l 治理效率方面 （提升一级模块建成效率，二级模块预案能力） l 周边生态方面 （流量复制，稳定性工程，动态调参, 服务可观测性） l 覆盖率方面 （百度APP100%核心模块，流量占比>79.5% ） #IstioCon 收益介绍 – 防雪崩&长尾 长尾优化： LocalityAware负载均衡策略 业务价值 降低业务因Redis回退引发的雪崩问题。（业务层RPC 框架Retry策略托管到Mesh，通过平响分位值动态抑 制BP请求） Mesh价值 1. 业务无需代码改动即可开启，在线调整backup超时 分位值、熔断阈值。 2. 支持动态调整配置参数，对接智能调参系统。 防雪崩能力：动态BackupRequest #IstioCon 未来 l 强化稳定性工程。（Case覆盖、故障自动恢复）

Informer 机制获取 Node、Endpoint、 Service、Pod 变化） • 根据用户的配置（CR、MCP 推送，文件） 触发推送流程 推送流程 • 记录变化的资源类型 • 根据变化的资源类型整理本地数据 • 根据变化的资源类型判断需要下发的 xDS资源 • 构建 xDS 资源，下发到连接的 Sidecar10/23 xDS Sidecar 通过动态获取服务信息，对服务的发现

比如说黑白名单，权限。 • Quota:访问次数 • Report: 日志。Mixer的二次开发流程Mixer插件工作模型 上述的过程中，Envoy所做的数据收集、上传是自动完成的，而Mixer生成模版实例则 可以通过配置来完成。因此，所谓的Mixer插件实际上就是Adapter，开发Mixer插件 也就是开发Adapter。两种开发模式 几种开发模式，以及写一下两种方式的区别 Compiled In ances Instances。属性映射。基于Mixer的二次开发Rules Rules。将数据交付给适配器。 定义了一个特定的 Instance 何时调用一个特定的 Handler插件编译和镜像打包 插件的编译 CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build - a -installsuffix cgo -o eventadapter 镜像制作的dockerfile

现阶段协议扩展方案面临的挑战： ● 在 Mesh 中支持一个七层协议的工作量较大： ○ 数据面：编写一个 Envoy filter 插件——流量管理（RDS、 负载均衡、熔断、流量镜像、故障注入等）、编解码 ○ 控制面：编写一个 Aeraki 插件——运维/流量管理策略 ● 非 HTTP 协议缺少 RDS 支持： ○ Listener 内嵌路由 ○ 修改内嵌路由后，Envoy 会重建

S升级为P • 官方博客：Envoy hot restart什么时候会进行热重启？监控envoy ü获取非正常退出状态 ü抢救机制触发 ü抢救令牌减少一个（总共10个） ü在2(n-1) * 200毫秒后执行（为什么不立即执行） ü失败再次触发抢救机制 ü10个令牌用完，没有抢救成功，放弃退出优雅关闭envoy ü K8s发送SIGTERM信号让容器优雅关闭 ü Pilot-Ag

（header: user: ***) Pilot 代码改动 • 解析 CRD • 生成 xDS 配置下发 优点： • 控制面改动小，可以快速实现对新协议的支持 问题： • Pilot 目前缺少一个良好的协议扩展机制 • Pilot 需要理解 Envoy filter 中协议特定的知识 • Pilot 代码中维护众多七层协议的代价较大 12 Istio 协议扩展：常见七层协议的路由 Protocol Destination Redis Proxy https://github.com/zhaohuabing/istio-redis-culster EnvoyFilter 15 Istio 协议扩展：控制面扩展机制 优点： • 对 Istio 和 Envoy 无侵入 • 扩展性强，基本可以支持任何七层协议 问题： • 工作量较大，相当于实现了一个独立的 xDS 服务器 Aeraki: 为Istio提供七层协议扩展的开源项目，可以支持

Node 1 svc1 自身业务 SDK Sidecar 服务治理 Node 2 svc 2 自身业务 SDK Sidecar 服务治理 通信基础 服务发现 负载均衡 熔断容错 动态路由 … for (封装++) { 应用侵入--； 治理位置--； } 微服务角度看Istio: 服务网格 服务网格控制面 从基础设施(Kubernetes)看Istio: 服务访问 Node 基础设施(Kubernetes)看Istio: 能力增强 服务部署运 维 服务治理 • 调用链追踪 • 动态路由 • 熔断限流 • 负载均衡 • 服务发现 • 扩缩容 • 运维 • 部署 Kubernetes Istio Istio治理的不只是微服务，只要有访问的服务，都可以被治理。 Istio关键能力 流量管理 负载均衡 动态路由 灰度发布 可观察性 调用链 访问日志 监控 策略执行 限流 ACL endpoint等资源对象 3. DiscvoeryServer使用 ServcieDiscovery接口上的服务发 现方法和用户配置的规则构造xDS 4. Envoy从Discovery获取xDS，动态 更新 Kubernetes Service Instance Instance Service Endpoint Endpoint Istio Istio & Kubernetes：Mixer