设计及开发工作。 Copyright © Huawei Technologies Co., Ltd. All rights reserved. Page 3 目录 1. Envoy启动及配置文件 2. Envoy流量拦截原理、常用部署方式 3. Envoy可扩展过滤器架构、可观测性 4. Envoy线程模型 5. 生产环境问题分析及解决方法 6. 针对Envoy做的一些优化及效果 reserved. Page 5 Envoy介绍 • Envoy采用C++实现，本身为四层及七层代理，可以根据用户应用请求内的数据进行高级服务治理 能力，包括服务发现、路由、高级负载均衡、动态配置、链路安全及证书更新、目标健康检查、 完整的可观测性等。 • 目前常见数据面主要有三种：Envoy、Linkerd、Traefic。Envoy由于高性能和扩展能力前在数据面遥 遥领先。 • I Virtual inbound -15006 kubelet 拦截指定命名空间 Pod创建请求 xDS Iptables 规则 ./etc/istio/proxy/SDS 证书 获取 配置 文件 可以修改全局注入参数 作用于所有目标空间的 pod 证书更新 Envoy启动流程 Envoy控制面流量 Envoy数据面流量 ./etc/istio/proxy/XDS SDS xDS

内部客户端 Service2 Service1 网格内部 定义网格入口 • 服务端口 • Host • TLS 配置 • 路由配置 • 根据 Host 路由 • 根据 Header • 根据 URI 路由 目的地流量策略配置 • LB 策略 • 连接池配置 • 断路器配置 • TLS 配置 Gateway External Service 统一网格出口 • 出口地址（Gateway Workload） 对外请求 对外请求（Passthrough/ServiceEntry） 缺省路由 （服务名） 5 Istio 流量管理 – 数据面 – Envoy配置模型和xDS协议 ADS Server LDS RDS CDS EDS Envoy 配置模型的主要概念： • Downstream：连接到 Envoy 的下游 Host，发送请求并接收响应。 • Upstream： 上游 Host 接收来自 Envoy 。 gRPC/REST: update config on the fly 6 Istio 流量管理 – 数据面 – Istio 中的 Envoy Sidecar 配置 Istio中的 Envoy Sidecar 配置： • Istio 通过 Listener、Route Config 和 Cluster 为 Mesh 中的 Envoy 生成了入向和出向两个不同方向的处理流程的配 置。 •

理，成为了微服务中的瓶颈，模 块流量会互相影响 • 大锅饭带来了复杂的配置管理， 渐渐难以为继 • Istio的架构和基本原理 • FreeWheel的Istio实践 • 未来工作 • FreeWheel的痛点 Istio架构 • Istio Proxy: 劫持Pod的所有通信， 是Mesh的基础 • Pilot: 为Proxy提供动态配置管理 • Citadel: 自动维护mTLS密钥 • Telemetry提供监控数据收集能力 基本原理 • Istio从架构上可以分为4个板块： • Istio Proxy: Mesh的基础 • 网络安全：兼容Spiffe标准实现 • 配置管理：为C++实现的Proxy接 入k8s的动态配置管理 • Attribute Machine: 授权，Quota ，Tracing，监控的基础 Istio管理下的微服务 • 右图是部署mock1.v1 Pod之后发生的事 这里实现的例子mymock会完全拒绝所有 被匹配到的流量，右图是mymock Handler的基本原理 • mymock handler 是 mymock adapter的初始化配置 • 完成初始化后rule将checknothing配置 与handler关联起来，其实就是做了流 量的匹配，满足一定条件的流量上应用 mymock handler • mymock adapter直接拒绝被匹配的请 求

u启动envoy u热重启envoy u监控envoy u优雅关闭envoy启动envoy ü监听/etc/certs目录 ü生成envoy静态配置文件envoy-rev0.json ü通过exec.Command启动 envoy并监听状态 • 文件配置文档 • 启动参数文档热重启envoy热重启涉及以下步骤 • Pilot-Agent只是负责启动S，其他步骤由envoy完成。 • 1. 启动另外一个S进程（Secondary 启动另外一个S进程（Secondary process） • 2. S通知P（Primary process）关闭其管理的端口，由S接管 • 3. S加载配置，开始绑定listen sockets，在这期间使用UDS从P获取合适的listen sockets • 4. S初始化成功，通知P停止监听新的链接并优雅关闭未完成的工作 • 5. 在P优雅关闭过程中，S会从共享内存中获取stats • 5 oy ü Envoy不支持优雅关闭，需要通过金丝雀或蓝绿部署方式实现 Envoy优雅关闭实现方式讨论：#3307 #2920Pilot-Discovery——配置中心（PD） uv1版本和v2版本之间的区别 u建立缓存配置 u触发配置生效方式v1版本和v2版本之间的区别 V1 HTTP1 REST JSON/YAML 弱类型 轮询 SDS/CDS/RDS/LDS 奠定控制平面基础

现 Demo 的演示3/23 为什么需要 Service Mesh 改造 /01 对比传统微服务架构和 Service Mesh 化之后有哪些优缺点4/23 微服务 模块 • 安全 • 配置中心 • 调用链监控 • 网关 • 监控告警 • 注册和发现 • 容错和限流 特点 • 独立部署 • 强化模块边界 • 技术多样性5/23 Service Mesh 优点 • 负责网格中的流量管理以及控制面和数据面之间的配置下发，在 Istio1.5 之后合并了 Galley、Citadel、Sidecar-Inject 和 Pilot 成为 Istiod。 功能 • 根据不同的平台（Kubernetes、Console） 获取一些资源（Kubernetes 中使用 Informer 机制获取 Node、Endpoint、 Service、Pod 变化） • 根据用户的配置（CR、MCP MOSN 可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡， API Gateway，云原生 Ingress 等使用。 配置文件 • mosn_config : MOSN 的配置信息 • listener : LDS • routers : RDS • cluster : CDS 和 EDS13/23 MOSN-listener14/23

运维人员设置请求路由规则，将不同来源的请求路由到不同的服务实例 组进行处理。 #IstioCon Aeraki Demo: 用户请求和批处理任务隔离(Dubbo) 1. 在 dubbo: application 配置中为 Provider 增加 service_group 自定义属性 2. 通过 Provider 的 deployment 设置 SERVICE_GROUP 环境变量 3. 在 consumer provider 的地域属性为provider实例配置 不同的LB优先级，优先级的判断顺序如下： 1. 最高：相同 region，相同zone 2. 其次：相同 region，不同zone 3. 再次：不同 region #IstioCon Aeraki Demo: 地域感知负载均衡(Dubbo) 1. 在 dubbo: application 配置中为 Provider 增加 aeraki_meata_locality 中获取 ServicEntry，通过端口命名判断 协议类型（如 tcp-metaprotocol-thrift） 2. 为 MetaProtocol 服务生成数据面所需的 Filter 配置 ，Filter 配置中将 RDS 指向 Aeraki 3. Istio 下发 LDS(Patch)/CDS/EDS 给 Envoy 4. Aeraki 根据缺省路由或者用户设置的路由规则下发 RDS 给

• Quota:访问次数 • Report: 日志。Mixer的二次开发流程Mixer插件工作模型 上述的过程中，Envoy所做的数据收集、上传是自动完成的，而Mixer生成模版实例则 可以通过配置来完成。因此，所谓的Mixer插件实际上就是Adapter，开发Mixer插件 也就是开发Adapter。两种开发模式 几种开发模式，以及写一下两种方式的区别 Compiled In Adapter 编写grpc服务端程序，接收来自mixer的数据，并实现自身业务逻辑 • 编写handler、instance、rule配置文件 • 编译打包adapter，上传至docker仓库 • 编写k8s的deployment和service配置文件 • 部署应用基于Mixer的二次开发Hanlder Handlers 。为适配器提供配置。例如，到后端的 URL 、证书、缓存选项等等。基于Mixer的二次开发Instances ADD eventadapter /usr/bin/eventadapter ENTRYPOINT ['./eventadapter']基于Mixer的二次开发的流程 Deployment配置 Service配置SOFAStack公众号 http://www.servicemesher.com ServiceMesher公众号

要求。 l 高级架构能力能否多语言、多框架支持？ l 运维架构能力是否具备可移植性？是否能低成本复制新的产品线？ l 可观测性不足，是否有通用机制提升产品线可观测性？ Ø 部分模块上下游超时配置不合理，超时倒挂，集中管理调整成本比较高。 Ø 多数模块对单点异常，慢节点等异常缺乏容忍能力，推动每个模块独立修复，成本高，上线周期长。 Ø 因重试导致雪崩，底层RPC框架需要重复建设来定制动态熔断能力。 技术方案 l 核心原则 Ø 务实、高稳定性、低迁移成本。 l 核心思路 Ø 先单跳，后双跳。 Ø 服务发现下沉到Envoy。 Ø 基于 RPC + 服务发现实现透明流量劫持。 Ø 自建配置中心，产品化封装。 l 关键技术 Ø 内核劫持，使用Loopback IP 与 服务发现一一对应。 Ø RPC劫持，构建可快速扩展标准方案。 Ø 自身稳定性，降级（兜底）、隔离、监控多种方式保证。 envoy离线或者被干预则立即通知bns-agent， fallback会使用原有治理策略。 #IstioCon 架构介绍 Ø Mesh控制中心： ü 运维中心：基于Mesh的统一运维操作中心。 ü 配置中心：维护模块上下游拓扑，管理路由配 置、通信策略。 ü 上线中心：管理Mesh组件版本，统一上线入口。 l 核心组件 Ø 控制面板：Istio-Pilot组件，路由管理、通信 策略等功能 Ø

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 ~10MB for V8 ● 事件驱动模型 ● 兼容native filter调用 方式 8 Example Wasm filter configuration ● 下发到Envoy Proxy侧的配置 9 OCI Registry As Storage ● OCI Artifacts项目的参考实现, 可显著简化OCI注册库中任意内容的存储; ● 可以使用ORAS API/SDK Library来构建自定义工具， Reconcile) Istio EnvoyFilter CR wasm filter二进 制文件 服务网格ASM Pod K8s集群 Proxy Service A Volume 挂载 Envoy配置 17 ASMFilterDeployment CR示例 ● 创建ASMFilterDeployment Custom Resource 18 生成的Istio Envoy Filter资源(1)

List/Watch KubeAPIserver上service、 endpoint等资源对象 3. DiscvoeryServer使用 ServcieDiscovery接口上的服务发 现方法和用户配置的规则构造xDS 4. Envoy从Discovery获取xDS，动态 更新 Kubernetes Service Instance Instance Service Endpoint code | 200 Istio & Kubernetes: 总结 对于云原生应用，采用Kubernetes构建微服务部署和集群管理能力，采用 Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布 灰度发布：蓝绿 灰度发布：A/B Testing 灰度发布：Canary