蚂蚁金服ServiceMesh数据平面 SOFAMosn深层揭秘 奕杉Agenda Ø背景 Ø构架 Ø能力 Ø性能 ØRoadMap背景为什么蚂蚁需要ServiceMesh Ø拥抱微服务，云原生 • SOFA 5规划落地 • 兼容K8S的智能调度体系 Ø运维体系的有力支撑 • LDC • 弹性伸缩 • 蓝绿/容灾/.. Ø金融级网络安全 • 金融级鉴权体系 • 云原生zero trust网络安全趋势 Ø定义可扩展的插件机制PROTOCOL 5 Ø定义编解码核心数据结构 üMesh处理三段式：Headers + Data + Trailers Ø定义协议Codec核心接口 ü编码：对请求数据进行编码并根据控制指令发送数据 ü解码：对IO数据进行解码并通过扩展机制通知订阅方 •定义扩展机制通知解码事件STREAMING 6 Ø定义Stream模型 ü 向上确保协议行为一致性 ü 为网络协议请求/响应提供可编程的抽象载体

如何让社区和客户认可我们的产品？开源方案选择之第一代Service Mesh Linkerd • 无控制平面 • Scala编写，基于JVM资源消耗大 • 可扩展性有限，dtab不易理解和使用 • 功能不能满足蚂蚁的需求，没法做到 类似envoy xds那样的扩展性 • 未来发展前景黯淡 Envoy • 安心做数据平面， 提供XDS API • 设计优秀，性能和稳定性表现良好 • C++编写，和蚂蚁的技术栈差异大 蚂蚁有大量的扩展和定制化需求 • 我们非常认可envoy在数据平面上的表现开源方案选择之第二代Service Mesh Istio • 第一选择，重点关注对象 • 奈何迟迟不能发布生产可用版本 • 性能和稳定性远远不能满足蚂蚁的 要求 • 但我们非常认可Istio的理念和方向 Conduit • 只支持k8s，而蚂蚁尚未普及k8s • 数据平面由Rust编写，过于小众，难于 从社区借力。 • 公司和产品在社区知名度和影响力有限国内公司的选择之一：自研 华为：CES Mesher • 使用Golang编写 • 由go chassis演进而来 • 走的是已有类库->加proxy->再加 控制平面的路线 • 部分对接Istio • 细节暂时不清楚，即将开源 新浪微博：Motan Mesh • 也是使用Golang编写 • 全新实现（原有类库是基于Java） 老成持重的稳健思路：以proxy为切入口，第

在实践中，服务网格通常实 现为一组轻量级网络代理，它们与应用程 序一起部署，但对应用程序透明。什么是Service Mesh？- by Istio 服务发现 负载均衡 流量控制 ... 黑白名单 限流 ... 身份认证 通信加密 权限控制 ... 调用追踪 指标收集 ...什么是Service Mesh？- 从网络的视角 Service Mesh关注点 网络视角： Service Mesh是一个主 Control Plane Programmable API APP ...... Data Plane Control Layer Application Layer通过Service Mesh控制面统一管理F5和Envoy https://aspenmesh.io/2019/03/expanding-service-mesh-without-envoy/ Control Plane Security 解决类似的问题：运维和通信的问题 • 相似的解决方案：数据面+控制面+应用 • 不同的协议层次：SDN 2-4层，Service Mesh 主要为7层 SDN对Service Mesh发展的启发： Ø 北向接口 • 面向业务和运维 • 具有较高的抽象层次，比较容易提取统一的控制面标准？ • 主要面向layer 7及以上？ • SMI能否统一控制面标准？如何避免成为最小公分母，扩展支持其它协议？

现阶段的关键需求 技术储备与原则类因素 自研数据平面与 控制平面方案 使存量服务接入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 数据平面升级方式 – 发布流程 容器化发布方式

问答SOFA MESH • 从 ISTIO 克隆并保持同步更新 • 使用 SOFA-MOSN 代替 ENVOY 作为数据平面 • 打包 • 安装 • 部署 • 测试 • 支持主流的微服务框架 • SOFA • HSF • DUBBO • SPRING CLOUD • … • 控制平面创新的地方 • MESH OPERATOR • RPC SERVICE CONTROLLER • …SERVICE 在非 KUBERNETES 环境部署 ISTIO 把 KUBERNETES 当作一个更好用的虚拟化方案 KUBERNETES NATIVE 化微服务 PLATFORM ADAPTER 自己做控制平面KUBERNETES NATIVE 微服务 • 使用 Kubernetes 作为注册中心 • Service • Endpoint • Pod • 使用 DNS 寻址 • 使用 iptables/ebpf ENVOY 不支持微服务使用的通信协议 • RPC 服务使用的接口，方法，参数语义无法匹配 ISTIO 的路由模 型 • 一个应用上部署了多个 RPC 服务，每个服务有自己的版本 • …ISTIO 控制平面路由的抽象模型 INBOUND OUTBOUNDSOFA 服务注册模型落地一个微服务框架需要的工作 • 部署 ZK 集群作为 RPC 框架的注册中心 • 开发 ZK Platform Adapter

图片来源：https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh 流量控制、监控8/39 金融级网络安全 Part 1： 为什么需要Service Mesh? 身份标识/访问控制 Service （client） Sidecar Sidecar Service （server） mTLS 服务鉴权 SOFAStack 双模微服务平台 DB Advisor Pod Spring Cloud 应用 SOFAMosn SOFA 服务注册中心 Service Mesh 控制平面 Galley Citadel Inspector Pilot 双模微服务 = 传统微服务 + Service Mesh 双剑合璧 服务路由 服务限流 服务拓扑 实时监控 降低资源成本，提升开发效率，享受生态红利 • 云原生不是目的，而是手段 拥抱云原生Part 3： 展望未来 和 istio 社区共建， 融合控制平面和传统注册中心/配置中心，加强 Pilot 的能力 APP SDK 各种注册中心 Galley Nacos 控制平面 （Pilot） MCP MCP SOFARegistry MCP APP Sidecar xDS/UDPA

• 读取配置 -> 连接k8s/Galley • Adapter的运行时资源开销 • 不受Adapter增减/更新/升级影响 • 保持Proxy代码简单 • 保持Proxy代码简单 • 数据平面可替换原则 Kubernete s API Server Adapters ConfigurationsOut-of-process Adapter 7/39 Istio的新回答：架构继续优先，性能继续放一边 • 读取配置 -> 连接k8s/Galley • Adapter的运行时资源开销 • 不受Adapter增减/更新/升级影响 • 保持Proxy代码简单 • 保持Proxy代码简单 • 数据平面可替换原则 • 集中式服务： • 提高基础设施后端的可用性 • 为前提条件检查结果提供集群级别的全局2级缓存 • 灵活的适配器模型，使其以下操作变得简 单： • 运维添加、使用和删除适配器 支持虚拟机？ Traffic Director：效仿k8s/Istio的方式来管理服务 k8s service Google Traffic Director 服务 服务定义 通过 k8s 在控制台手工创建 创建服务 通过k8s自动注册 手工关联服务和托管实例组 服务注册 k8s进行健康检查 通过托管式实例组配置健康检查 健康检查 通过Istio支持 通过托管式实例组支持 灰度发布 流量劫持+

（Ant Global Network Accelarator) 网商 信用 保险 财富 支付 国际支付 小程序 微贷 科技开放 物联网 Spanner LVS(四层负载) DNS 网络控制面 LDC1 Spanner Spanner APP APP APP APP Keycenter HTTP1 TLS1.2 MMTP Mtls MQTT HTTP2 TLS1.3 QUIC Mesh 控制面 Galley Inspector Citadel Pilot Pod Dubbo 应用 SOFAMosn Pod SOFA 应用 SOFAMosn KMI Pod SOFA 应用 SOFAMosn Sigma TLS，国密 服务鉴权 流量控制 镜像中心 流量镜像 流量镜像 TLS，国密 服务鉴权 流量控制 TLS，国密 服务鉴权 流量控制蚂蚁金服率先大规模落地SOFAMesh 流量控制蚂蚁金服率先大规模落地SOFAMesh UDPA 安全 统一数据 平面API 存量连接无损迁移 提升5倍发布效率 TLS双向加密 支持国密算法 WAF 流量镜像 多协议 SOFARPC Dubbo HTTP1.1/2 平滑升级 性能 单跳CPU增加5%消耗 0.2ms RT 蚂蚁金服100+应用，10w+容器已经mesh化，部分业务链路通过下沉， RT降低了7%，平稳支撑了618大促。SOFAMosn

Prometheus 统一配置管理 Configmap、Secret 负载均衡 简单负载均衡，基于Iptables Roundrobin 流量控制 简单根据服务实例进行控制云平台微服务演进之基于API网关的微服务方案 API网关功能增强 • 安全认证 • 流量控制 • 审计日志 • 黑白名单 • …K8S集群 云平台微服务演进之基于Spring Cloud的微服务方案 NS A Service • 流量管理（超时、重试、熔断） • 故障处理 • 故障注入 • … Mixer • 前提条件检查：安全认证，黑白名单， ACL检查 • 限流管理 • 遥测报告：日志监控 控制平面 数据平面 Istio-Auth • 服务间认证 • 终端用户认证Istio的核心组件 • Envoy 是一个高性能轻量级代理，它掌控了service的入口流量和出口流量，它提供了很多内置功能，如动态负 如动态负 载服务发现、负载均衡、TLS终止、HTTP/2 & gRPC流量代理、熔断、健康检查等功能。 • Mixer 翻译过来是混音器，Mixer负责在整个Service Mesh中实施访问控制和使用策略。Mixer是一个可扩展组 件，内部提供了多个模块化的适配器(adapter)。 • Pilot 翻译过来是领航员，Pliot对Envoy的生命周期进行管理，同时提供了智能路由（如A/B测试、金丝雀部

Service Mesh演进路线 1 2 实现平滑迁移的关键 3 DNS寻址方案的演进 4 5 总结 DNS寻址方案的后续规划ü 对未来长期目标的认可 • Service Mesh（带控制平面，如Istio） • Kubernetes • 微服务 ü 现实中有很多挑战 • 还有很多应用没有实现微服务化 • 还有很多应用没有运行在kubernetes之上 • Istio目前还不够稳定，也无法原生支持我们的规模 Resiliency 操作 弹性 符合远期规划 • 不走弯路，不浪费投资 • 每一步都为下一步奠定基础 • 谢绝中途推倒重来 循序渐进 • 不要有一步登天的幻想，小步快跑 • 每一步的工作量和复杂度都控制在可 接受范围内 • 每一步都简单方便，切实可行 可操纵性 • 操作层面上要有足够的弹性 • 每个步骤都是可分批进行 • 步步为营，扩大战果 • 杜绝一刀切k8s和Service Mesh落地方案演进路线 2 2 2 3 4 4 4 比较理想，绝大部分 投入最终都将保留 Service Mesh (Sidecar模式) Service Mesh (Istio模式) 带完善的控制 平面，如Istio 只有Sidecar， 直接集成周边 不现实 Istio的非k8s支 持投入产出比 太差 背景1：原生Istio无法支撑我们的规模 背景2：k8s（Sigma3.1）将加快普及