2021 Cloud To Go 为什么我们需要服务网格 - 微服务化带来的问题 错综复杂的服务调度掩盖了 问题的源头 服务间交互的复杂性： Ø 难以可视化 Ø 难以全面测试 Ø 多服务联动时问题难以察觉 Ø ... 服务间通信的复杂性： Ø 网络延迟 Ø 消息序列化 Ø 不可靠的网络 Ø 异步机制 Ø ... 开发难 排错难 测试难 运维难 Ø 服务变得非常多 Ø 2021 Cloud To Go 为什么我们需要服务网格 - 服务网格带来了什么 服务网格是一个云原生的网络基础设施，它把微服务调度中有关网络的公共能力下沉，在无任何代码侵入的 情况下提供可观察性、流量管理和安全性等能力。 Copyright © 2021 Cloud To Go SolarMesh的定位 - 基于Istio构建的流量监管平台 Istio是目前服务网格领域最流行的开源项目，38%

Ltd. All rights reserved. Page 3 目录 1. Envoy启动及配置文件 2. Envoy流量拦截原理、常用部署方式 3. Envoy可扩展过滤器架构、可观测性 4. Envoy线程模型 5. 生产环境问题分析及解决方法 6. 针对Envoy做的一些优化及效果 7. 常用性能分析测试工具及使用方法 8. 华为ASM产品介绍 Copyright © • Envoy采用C++实现，本身为四层及七层代理，可以根据用户应用请求内的数据进行高级服务治理 能力，包括服务发现、路由、高级负载均衡、动态配置、链路安全及证书更新、目标健康检查、 完整的可观测性等。 • 目前常见数据面主要有三种：Envoy、Linkerd、Traefic。Envoy由于高性能和扩展能力前在数据面遥 遥领先。 • Iptables使Pod间出入应用的流量均由Envoy代 当Envoy配置的线程数比较多时（越多越明显）， 常观察到新连接被分配到某些线程。 • Envoy的线程模型是工作线程由libevent事件信 号驱动串行的处理发生的新事件（网络，定时器） • 请求堆积在某些线程将导致tp90上升，QPS处理 能力下降。 • 对于长连接和规格较高的Envoy影响更明显。短 链接可以一定程度上提升连接线程选择的随机性。 • 实际使用中客户更关注tp90的端到端时延，减少

它能解决我们的问题么？ • 有条件的，慎重的用选定试用功能 • 性价比的灵魂拷问： • 会给业务带来什么风险？ • 需要什么程度的投入？ • 可能出现什么故障？ • 能有什么好处？ • 个人看法 • 可观察性 • 路由 • 策略 • 安全试用服务范围 • 不要 All in！ • 稳定——性能和业务！ • 什么服务不怕死？ • 什么服务可以慢？ • 集群规模别太大。 • 能切换/回滚。 • 有完善的性能、功能测试方案。禁则 故障处理需求：故障预案。 • 影响范围分析。 • 选定测试版本：研读开放Issue以及Release Notes。测试方案部署 • Istio部署 • 复查集群环境 • 调整资源参数 • 调整亲和性参数 • 调整HPA • 日志输出和调试开关复查 • Istio功能裁剪 • 备用业务部署 • 试用服务部署 • 服务YAML复查 • 缺省路由设置 • 根据功能需求，编写和部署 Istio相关功能YAML

• 运维 • 部署 Kubernetes Istio Istio治理的不只是微服务，只要有访问的服务，都可以被治理。 Istio关键能力 流量管理 负载均衡 动态路由 灰度发布 可观察性 调用链 访问日志 监控 策略执行 限流 ACL 故障注入 服务身份和安全 认证 鉴权 平台支持 Kubernetes CloudFoundry Eureka 集成和定制 ACL

运维 • 部署 Kubernetes Istio9 Istio治理的不只是微服务，只要有访问的服务，都可以被治理。10 Istio关键能力 流量管理 负载均衡 动态路由 灰度发布 可观察性 调用链 访问日志 监控 策略执行 限流 ACL 故障注入 服务身份和安全 认证 鉴权 平台支持 Kubernetes CloudFoundry Eureka 集成和定制 ACL

出来，使用一个专用层次来实现，Service Mesh 对应用透明，因此应用 可以无需关注分布式架构带来的通信相关问题，而专注于其业务价值。 流量控制：服务发现、请求路由、负载均衡、灰度发布、错误重试、 断路器、故障注入 可观察性：遥测数据、调用跟踪、服务拓扑 通信安全： 服务身份认证、访问鉴权、通信加密 Proxy Application Layer Service 1 Istio 流量管理 – 概览 • 控制面下发流量规则：

Let try it on Alibaba cloud ServiceMesh 12 更多 More 更多特性 控制台一键启动、暂停热升级 控制台设置热升级策略，单批次实例比例 可视化观察热升级状态 13 更多 More 谢谢! Thanks! 14

使用Wasm for Proxy ● Pros ○ 敏捷性：过滤器可以动态加载到正在运行的Envoy进程中，而无需停止或重新编译。 ○ 可维护性：不必更改Envoy自身基础代码库即可扩展其功能。 ○ 多样性：可以将流行的编程语言（例如C/C++和Rust）编译为WASM，因此开发人员可 以选择实现过滤器的编程语言。 ○ 可靠性和隔离性：过滤器会被部署到VM沙箱中，因此与Envoy进程本身是隔离的；即使 的；即使 当WASM Filter出现问题导致崩溃时，它也不会影响Envoy进程。 ○ 安全性：过滤器通过预定义API与Envoy代理进行通信，因此它们可以访问并只能修改有 限数量的连接或请求属性。 ● Cons ○ 性能约为C++编写的原生静态编译的Filter的70％; ○ 由于需要启动一个或多个WASM虚拟机，因此会消耗一定的内存使用量; ○ The WebAssembly ecosystem ecosystem is still young; 7 Wasm in Envoy Proxy ● Wasm动态加载 ● 一致性校验: ○ https://github.com/pr oxy-wasm/spec ● 内置的Wasm runtime ○ ~20MB for WAVM ○ ~10MB for V8 ● 事件驱动模型 ● 兼容native filter调用 方式 8 Example

l 核心业务线已完成微服务改造，数万个微服务对架构服务治理能力提出了更高的要求。 l 高级架构能力能否多语言、多框架支持？ l 运维架构能力是否具备可移植性？是否能低成本复制新的产品线？ l 可观测性不足，是否有通用机制提升产品线可观测性？ Ø 部分模块上下游超时配置不合理，超时倒挂，集中管理调整成本比较高。 Ø 多数模块对单点异常，慢节点等异常缺乏容忍能力，推动每个模块独立修复，成本高，上线周期长。 服务治理能力通用化 基于Service Mesh架构共建高级架构能力，为不同模块、不同产品线、甚至整个公司内提供 各项服务治理能力的通用化、中台化能力，从而加速服务治理技术的研发和迭代，提升架构 能力可移植性。 #IstioCon 技术方案 l 核心原则 Ø 务实、高稳定性、低迁移成本。 l 核心思路 Ø 先单跳，后双跳。 Ø 服务发现下沉到Envoy。 Ø 基于 RPC + 服务发现实现透明流量劫持。 l 稳定性方面 （单点，多点，防雪崩，长尾优化，架构故障韧性能力） l 治理效率方面 （提升一级模块建成效率，二级模块预案能力） l 周边生态方面 （流量复制，稳定性工程，动态调参, 服务可观测性） l 覆盖率方面 （百度APP100%核心模块，流量占比>79.5% ） #IstioCon 收益介绍 – 防雪崩&长尾 长尾优化： LocalityAware负载均衡策略 业务价值 Lo

化之后有哪些优缺点4/23 微服务 模块 • 安全 • 配置中心 • 调用链监控 • 网关 • 监控告警 • 注册和发现 • 容错和限流 特点 • 独立部署 • 强化模块边界 • 技术多样性5/23 Service Mesh 优点 • 统一的服务治理 • 服务治理和业务逻辑解藕 缺点 • 增加运维复杂度 • 延时 • 需要更多技术栈6/23 探索 Istio 技术点 /02