连接建立 传输+保持 通道复用 复合建连 握手优化 短连补偿 智能心跳 数据压缩 质量模型 自动重试 云端补偿 柔性建连 假连淘汰 动态超时 § 终端策略覆盖移动网络难点 § 优化对业务透明 § ROI考虑 好网更快 弱网更好 协议优化 支付宝网络接入层架构示意 § 关键词：动态Hpack + PB + 动态字典 + Zstd通信协议&架构持续升级 多终端&协议接入 架构升级 TLS，国密 服务鉴权 流量控制 TLS，国密 服务鉴权 流量控制蚂蚁金服率先大规模落地SOFAMesh UDPA 安全 统一数据 平面API 存量连接无损迁移 提升5倍发布效率 TLS双向加密 支持国密算法 WAF 流量镜像 多协议 SOFARPC Dubbo HTTP1.1/2 平滑升级 性能 单跳CPU增加5%消耗 0.2ms RT 蚂蚁金服100+应用，10w+容器已经mesh化，部分业务链路通过下沉， 大规模场景下需要面对的资源占用，自动化问题、性能问题，稳定性问题兼容问题 § 不同的应用，部分Mesh化 § 同一个应用，部分Mesh化 § 蚂蚁基础设施适配 § TLS加密链路平滑迁移 Localhost or Iptables 透明劫持和加速大规模问题 10万+实例 动态服务发现 运维 § 对控制平面性能，稳定性带来巨 大挑战 § 单实例数万路由节点，数千路由 规则，不仅占用内存，对路由匹

也有各种功能， 每次升级都要重新发布应用 业务进程专注于业务逻辑 SDK 中的大部分功能， 拆解为独立进程， 以 Sidecar 的模式运行 将服务治理能力下沉到基础设施，实现独立演进，透明升级7/39 异构系统统一治理 Part 1： 为什么需要Service Mesh? 多语言、多协议 图片来源：https://www.redhat.com/en/topics/mi 为什么需要Service Mesh? 身份标识/访问控制 Service （client） Sidecar Sidecar Service （server） mTLS 服务鉴权 全链路可信、加密 零信任网络9/39 二、 在当下『路口』的思考10/39 Part 2： 在当下『路口』的思考 云原生方案？ 落地有 gap 图片来源：https://istio.io/d 管控性和可观测性不好23/39 Part 3： 蚂蚁金服的产品实践 平滑迁移 初始状态24/39 Part 3： 蚂蚁金服的产品实践 平滑迁移 透明迁移调用方25/39 Part 3： 蚂蚁金服的产品实践 平滑迁移 透明迁移服务方26/39 Part 3： 蚂蚁金服的产品实践 平滑迁移 终态27/39 Part 3： 蚂蚁金服的产品实践 多协议支持 •

103:12220 192.168.1.101:12220 To：192.168.1.102:12220 To：192.168.1.103:12220 背景：k8s内外网络打通，IP互通透明拦截带来的升级弹性：对应用透明，支持直连/单跳/双跳 Service-A Outbound Sidecar Traffic Interception To: b-ip:b-port to: sidecar-ip:sidecar-port b-ip:b-port b-ip, b-port=getOriginalDest() 都没有改造，直连 服务器端有改造，单跳 客户端有改造，单跳Service Mesh时代的客户端和寻址方式 服务发现 加密 负载均衡 请求路由 目标服务 的标识 序列化 链路追踪 故障注入 日志 监控 Metrics 熔断 限流 服务降级 前置条件检查 身份认证 密钥管理 访问控制 …… 下沉到 Service

WAF，DDos2/10 MOSN 核心能力沉淀  精细化路由  安全防护  多协议  可运维  可扩展 • 多版本发布 • 压测引流 • 服务分组 • 加密链路 • 国密算法 • 服务鉴权 • TCP、Http、SOFA • 透明劫持 • 平滑升级 • 可观测性 • 网络包过滤器 • 协议包过滤器 • 协议扩展 • 可观测性扩展 • 路由扩展 • 集群管理扩展 模块化

扑，服务网格负责在这些拓扑中实现请求的可靠传递。 在实践中，服务网格通常实 现为一组轻量级网络代理，它们与应用程 序一起部署，但对应用程序透明。什么是Service Mesh？- by Istio 服务发现 负载均衡 流量控制 ... 黑白名单 限流 ... 身份认证 通信加密 权限控制 ... 调用追踪 指标收集 ...什么是Service Mesh？- 从网络的视角 Service Mesh关注点

iptables NAT 表所使 用到的 nf_contrack 内核模块效率 低下 2. 与 AliOS 团队探索出了基于 userid 和 mark 标识流量的透明拦 截方案，基于 iptables 的 mangle 表实现了一个全新的透明拦截组件#2 短时间内支持电商业务复杂的服务治理功能 •单元化？多环境？基于参数调用的路由？ 1. RPC 使用的是 Groovy 脚本，Mesh 不具备。

自己做控制平面KUBERNETES NATIVE 微服务 • 使用 Kubernetes 作为注册中心 • Service • Endpoint • Pod • 使用 DNS 寻址 • 使用 iptables/ebpf 透明地路由所有网络流量 • 服务治理规则，服务，实例和配置都是 Kubernetes 资源 • 使用 Controller Pattern 通过 CRD 扩展新的能力 • …MESH 落地碰到的问题 • 的域名就是其接口X-PROTOCOL 通用协议扩展目标 • Kubernetes Native，高性能，低侵入性的通用 Mesh 落地方案 • 支持新 RPC 框架和通信协议低成本接入 • 协议扩展对 Mesh 控制平面透明化 • 允许对协议多层次，插件化的扩展X-PROTOCOL 配置SOFA MOSN 调用流程 Upstream protocol X APP [light client] app user

4.框架不断升级 14% 2.机器资源逐年增加 27% 1.业务和框架耦合 32%8 因为我们要解决在 SOA 下面，没有解决但亟待解决的： 基础架构和业务研发的耦合，以及未来无限的对业务透明的稳定性与高可用相关诉求。 为什么要 Service Mesh-结论9 为什么要 ServiceMesh-结论-方案 应用A 应用 应用B 应用C 应用D 应用E SOA 解耦了不同的业务团队之前的耦合 三、方案落地 方案落地11 最终选型：自研数据面+轻量 SDK，我们给出的答案是 MOSN。 方案落地-选型 开源/自研：全部迁移到 envoy？不现实，自有协议+历史负担。 SDK/透明劫持：运维和可监控性不好，性能不高，风险不太可控。12 方案落地-目标架构 MOSN APP Pod MOSN APP Pod 服务发现 More Sidecar More Sidecar

AdapterService Mesh Meetup · BeiJing 和Istio在业务感知上的区别 �39 微博Service Mesh实践 - WeiboMesh 服务透明 VS 模块耦合 Istio：对服务透明 • 云原⽣生 • IPtables流量量拦截 • 服务⽆无感知 WM：模块化耦合 • 耦合度可选 • 定制化开发Service Mesh Meetup · BeiJing

理能力 • Istio 补齐了 K8s 在微服务治理上的短板 （限流、熔断、降级、分流等） • Istio 以 Sidecar 的形式运行在 Pod 中， 自动注入，自动接管流量，部署过程对业务 透明 • 提供了完整的 Service Mesh 解决方案 • 数据面：Envoy • 控制面：Pilot，Mixer，Citadel，Galley10/24 功能视角 - 服务治理能力 – 基于Istio+Envoy 平滑迁移是 Service Mesh 在混合云架构落地的关键17/24 平滑迁移 • 边缘网关支持跨 LDC 访问 • 兜底路由：云内云外互备 • 访问控制（如白名单能力） • 灰度引流使架构透明化 • 服务间调用灰度引流 • 外域调用灰度引流18/24 API 网关 • 整体基于 Envoy+Pilot 方案： • 数据面以 Envoy Proxy 作为代理组件 • 控制面以 Pilot