蚂蚁金服ServiceMesh数据平面 SOFAMosn深层揭秘 奕杉Agenda Ø背景 Ø构架 Ø能力 Ø性能 ØRoadMap背景为什么蚂蚁需要ServiceMesh Ø拥抱微服务，云原生 • SOFA 5规划落地 • 兼容K8S的智能调度体系 Ø运维体系的有力支撑 • LDC • 弹性伸缩 • 蓝绿/容灾/.. Ø金融级网络安全 • 金融级鉴权体系 • 云原生zero trust网络安全趋势 2SOFAMosn内数据流 3NET/IO 4 Ø屏蔽IO处理细节 Ø定义网络链接生命周期，事件机制 Ø定义可编程的网络模型，核心方法，监控指标 Ø定义可扩展的插件机制PROTOCOL 5 Ø定义编解码核心数据结构 üMesh处理三段式：Headers + Data + Trailers Ø定义协议Codec核心接口 ü编码：对请求数据进行编码并根据控制指令发送数据 ü解码：对IO数据进行解码并通过扩展机制通知订阅方 为网络协议请求/响应提供可编程的抽象载体 ü 考虑PING-PONG，PIPELINE，分帧STREAM三种典型流程特征 Ø定义Stream生命周期，核心事件 Ø定义Stream层编/解码核心接口 ü 核心数据结构复用Protocol层 Ø定义可扩展的插件机制 Ø对于满足请求Stream池化的需求 Ø需处理上层传入的状态事件PROXY 7 Ø基于Stream抽象提供多协议转发能力 Ø执行Stream扩展Filters

Ø 持续演进路径 & 技术案例 Ø 实践案例 Ø 规划 & 展望 Ø QA背景 & 概览数据平面概览 SOFAMOSN • C实现，支持多语言扩展 • 基于Nginx扩展 • 开发不活跃 • 老牌代理系统，业界广 泛使用，服务各类场景 • C++实现 • CNCF第三个毕业项目， ISTIO原生数据平面 • 开发活跃，最新版为1.9.0 • Google, Lyft主导，业界 众多公司使用中，重点搭 Service Mesh数据平面 • 开发活跃，最新版为 18.9.1 • Golang实现 • 新生项目，初期旨在搭建 RPC亲和，高度可扩展性 的Golang转发系统 • 开发活跃，最新版为0.4.0 • 蚂蚁+UC主导，重点搭载 SOFAMesh使用，目标服 务通用场景，金融场景SOFAMOSNSOFAMOSN内部模块设计SOFAMOSN数据流SOFAMOSN数据流持续演进路径 & 支持Router模式 Ø GRPC支持 Ø 协议自动识别 Ø 链式路由扩展 Ø 完善流量管理策略，包括 Retry、DirectResponse、 HTTP Header add/delete、 流控、故障注入等 Ø 支持必要的admin接口性能 0.1.0 0.2.0 0.3.0 0.4.0 Ø 内存复用框架 Ø Slab style buffer Ø Raw-Epoll模式 Ø 读合并

王成昌（晙曦）蚂蚁金服技术专家2/20 一、业务背景 二、多集群管控 三、发布运维体系 目 录 contents 目录3/20 一、业务背景 业务背景4/20 业务背景 业务架构 演进 • 容量  应用|数据库|机房 • 容灾  机房|地域5/20 业务背景 业务架构 单元化 • 高可用 • 一致性 • 可扩展 • 高性能6/20 业务背景 业务诉求 • 运维成本  突发流量应用 同城双活架构 K8S API Server 基础发布运维 跨集群应用 资源管理 IaaS层（Aliyun/OpenStack/VMWare/Bare Metal） PaaS 核心层 核 心 流 程 两地三中心架构 跨机房和地域统一应用运维 容器运行时 （Docker/Pouch/安全容器） CNI Plugins (VLAN/VXLAN/VPC Router/ENI) CSI 运维原子操作 精细化调度 接入层流程调拨 应用层流量调拨 跨集群状态 分发/汇聚 数据层流量调拨 压测/灰度 流量管理 单元化 元数据管理 弹性流量管理 跨集群发布策略 多集群管理 跨集群网络 跨集群镜像管理 蓝绿发布 灰度分组发布 中间件变配 （DRM/Scheduler/Message） Mesh流调拨和治理 弹性建站/下站 容器腾挪/迁移 容灾切换和恢复 应急预案管理 … 分钟级容灾切换和恢复

network from your service code Exposes your services as managed APIs 概念 流量 东西流量（内部） 通信协议 路由 鉴权 流控 安全 协议转换 通用协议（HTTP、gRPC 等） 私有协议（WS、Dubbo、Bolt 等） 一般不需要 HTTP to 内部 RPC 协议 基于 Host、Path 等路由 基于 Service MOSN APP3 Logic Logic MOSN • 低成本接入 • 平滑升级 • 异构支持 • 核心系统上云12/21 蚂蚁金服 API Gateway Mesh 架构 数据流 控制流 Ops 流13/21 API Gateway Mesh Based on MOSN MOSN 能力与模块 MMTP Protocol HTTP\SOFARPC\Dubbo Gateway

traffic(For example: Rate limiting, Service priority, etc.)总结：他山之石，可以攻玉 • 解决类似的问题：运维和通信的问题 • 相似的解决方案：数据面+控制面+应用 • 不同的协议层次：SDN 2-4层，Service Mesh 主要为7层 SDN对Service Mesh发展的启发： Ø 北向接口 • 面向业务和运维 • 具有较高 Ø 南向接口 • 面向流量和路由配置 • xDS v2将统一数据面标准？ • xDS接口包含有较多实现相关内容：Listener, Filter, 能否可以成为一个通用的接口协议？ 是否会出现Envoy之外的大量数据面实现？ • 建议：对xDS接口进行改进，去掉实现相关内容 Ø Service Mesh的发展 • 控制面对数据面软硬件的统一控制能力？ • 通过控制面API接入各种丰富的应用场景 Jaeger DexMesh数据面 Pod Microservice Envoy Desktop OtherSystems Mobile DexMesh Ingress Pod Microservice Envoy (Telemetry， Policy check) 配置数据(服 务信息，路由 信息等) 定制Istio组件 应用微服务 业务请求 控制流 图例说明 Pilot

CI/CD 实战 • ServiceMesh • 踩过的一些坑 • Q&A技术架构的演进 • 单体架构 • 一个框架 • 一个数据库 • 分模块整合架构（前后端分析） • 不同的框架或业务模块 • 多种数据源 • 微服务架构 • 各种语言、各种框架或子系统 • 各种数据源 • ServiceMesh一般的开发流程 • 1. 开启一个新的 feature； • 2. Developer 从 review ，批准合并之后，feature/new_branch 会合并到 develop； • 8. Merge 触发 Jenkins/Drone 自动构建； • 9. 构建成功就执行你定义的工作流：打包镜像，触发 deploy 以及其他后续的 Automation Testing 等流程； • 10 . Drone 通知工作流程情况给开发/或者交付 QA 测试；如何提升工程效率？我是作者名称2017

高可用 • 微服务高可用设计手段 - 服务限流 • 接入层限流 • 调用外部限流服务限流 • 切面层/代理层限流 常用限 流架构23/总页数 治理策略 & 高可用 • 微服务高可用设计手段 - 服务限流 • 拒绝策略 • 延迟处理 • 特权处理 常用限 流策略24/总页数 治理策略 & 高可用 • 微服务高可用设计手段 - 服务限流 • 固定、滑动时间窗口限流 • 适合微服务接口 适合微服务接口 • 选定的时间粒度上限流 • 令牌桶、漏桶限流 • 适合阻塞限流 • 超过最大访问频率后，请求阻塞等待或者直接拒绝（等待时间=0） 常用限 流算法25/总页数 治理策略 & 高可用 • 微服务高可用设计手段 - 服务限流 • 基于来源限流（from） • 系统标签 • 自定义标签 • 基于标签匹配（to） • 系统标签 • 自定义标签 常用限 流用法 matchLabels

Mesh风头正劲Service Mesh产品多样化Service Mesh的优势 云原生 零入侵 可观察性 面向运维服务化之后，数据库怎么办？ 服务 • 无状态 • 根据规则路由 • 业务方处理事务 数据库 • 有状态 • 根据SQL路由 • 数据库自动处理事务数据库的进化趋势 • SQL • ACID • 分布式 RDBMS • SQL • BASE ACID • 分布式 NewSQL?数据库中间层的优势 系统 •事务 运维 • DBA 开发 • SQL数据库中间层应具备的能力 分片化 多副本 数据一致性 弹性化 治理能力 观察能力数据分片 App2 DB App1 App3 App2 DB1 DB2 DB3 App1 App3数据分片：引入中间件 App1 M1 App2 App3 S2 M2 M3 S1 S3 数据库中间件 App1 M App2 App3 write sync read数据分片 + 读写分离 App1 S1 App2 App3 M2 sync read S2 S3 M1 M3 write数据分片 + 读写分离：引入中间件 App1 M1 App2 App3 S2 M2 M3 S1 S3 数据库中间件 write sync read分布式事务：定义 传统事务：ACID

与现有架构的兼容性 现阶段的关键需求 技术储备与原则类因素 自研数据平面与 控制平面方案 使存量服务接入Mesh 方案 对接大量内部系统 关键收益均由数据平面产生 非完善的控制平面功能 技术体系内不引入Go语言 最成熟的服务端语言为Java 使用Java开发 数据平面Agent14/24 整体架构 数据平面 • 现有协议的流量转发 • Agent平滑升级机制 控制平面 控制平面 • 轻量的Pilot Proxy • 向Istio的标准协议靠拢 重点目标 长期规划15/24 数据平面实践细节 • 部署方式 • 升级方式 • 容灾方式 • 性能问题 • 资源问题 • 兼容问题 关键设计 关键问题16/24 数据平面部署方式 容器化运行方式 • sidecar模式 • 与业务进程相同Pod不同Container 陌陌微服务容器化部署比例在80%以上 sidecar模式部署17/24 数据平面升级方式 – 平滑升级机制 平滑要求 • 业务进程不重启 • 流量保持不变 方案选择 • FD迁移 vs 哨兵集群 原理 • sendmsg / recvmsg接口发送FD • 步骤：listener、存量连接、存量数据 Java实现 • 借助JNI与Netty Java实现FD迁移18/24 数据平面升级方式 – 发布流程 容器化发布方式

功能不能满足蚂蚁的需求，没法做到 类似envoy xds那样的扩展性 • 未来发展前景黯淡 Envoy • 安心做数据平面， 提供XDS API • 设计优秀，性能和稳定性表现良好 • C++编写，和蚂蚁的技术栈差异大 • 蚂蚁有大量的扩展和定制化需求 • 我们非常认可envoy在数据平面上的表现开源方案选择之第二代Service Mesh Istio • 第一选择，重点关注对象 • 奈何迟迟不能发布生产可用版本 奈何迟迟不能发布生产可用版本 • 性能和稳定性远远不能满足蚂蚁的 要求 • 但我们非常认可Istio的理念和方向 Conduit • 只支持k8s，而蚂蚁尚未普及k8s • 数据平面由Rust编写，过于小众，难于 从社区借力。 • 同样存在技术栈问题 • 公司和产品在社区知名度和影响力有限国内公司的选择之一：自研 华为：CES Mesher • 使用Golang编写 • 由go 第 一时间获取跨语言和技术栈下沉的红利，立足 之后再缓缓图之。 这个产品思路唯一的麻烦在于编程语言的选择国内公司的选择之二：开源方案定制 腾讯：Tencent Service Mesh • 数据平面选择Envoy：成熟产品，符合 腾讯语言体系，内部广泛使用 • 控制平面据传“挣扎了一下”，最终还 是选择Istio，进行定制和扩展，解耦k8s国内公司的选择之三：另辟蹊径 UCloud：Service