上篇文章《诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中，介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，帮助大家了解 Service Mesh 未来发展方向和前景。蚂蚁金服持续在进行 Service Mesh 布道和交流。本文内容整理自 10 月 26 日 Service Mesh Meetup#7 成都站主题演讲，现场视频以及分享 PPT 获取方式见文章底部。

从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付，千万春晚咻一咻的。

前言

在云计算和 SDN 下，我们经常听到流量的东西南北向概念，简单来说从外部 Internet 等到数据中心内部的流量走向被称为南北流量，数据中心内部的 VM 之间的流量被称为东西流量。

当我们追踪南北向的网络流，请求通常会经过四层负载均衡，七层负载均衡等，这通常被我们称为网络接入层代理。当数据中心内部主动访问公网时候，流量通常也会经过 NAT 网关等做网络地址的转换，这也被我们称为网络代理。当我们把视角转向数据中心内部，网络代理的存在感似乎不是那么强，随着 SOA 的发展我们形成了各种成熟的服务通信框架，例如蚂蚁金服的 SOFARPC，阿里集团的 HSF，Google 的 gRPC 等等，网络代理功能被集成进了各种通信框架中，似乎已经 Proxyless 化了，但是随着微服务以及 Service Mesh 的架构提出，东西向的网络代理以独立的姿态又出现了。

本文将围绕蚂蚁金服近十年网络代理的变迁，揭示整个蚂蚁金服接入层网络以及 Service Mesh 的演进过程，同时带来我们的思考。

旧瓶新装

我们先来看看业界情况，传统四层负载均衡的代表产品当然是 IPVS，百度阿里等公司早年均对 IPVS 做了非常深度的定制功能，支撑了早期业务的飞速发展。接着也有 DPDK(阿里云 SLB)，类 DPDK 技术的代表 Google 的 Maglev 以及 eBPF 技术的代表 Facebook 的 Katran 出现。

七层网络代理各个大厂均有产品代表，Google 的 GFE、百度的 BFE、腾讯的 TGW，阿里经济体内部也因为场景等原因有众多，例如手淘的 Aserver，集团 web 统一接入 Tengine，当然还有蚂蚁金服的 Spanner（后面会详细介绍）。同时随着 Service Mesh 概念的提出和技术的逐渐成熟，Mesh 中 Sidecar 角色的网络代理也像雨后春笋一样多了起来，包括蚂蚁金服的 SOFAMosn，Istio 社区方案的 Envoy 以及 Rust 编写的 Linkerd，当然 Service Mesh 场景的网络代理和网络接入层的代理我认为没有本质的差别，随着云原生的深入化，大家终将会形成合力并保持一致的形态。

上图是2019年 Gartner Networking 方向的曲线，可以看到在上升和爆发区有着非常多的网络代理的影子（Secure Access Service Edge，Service Mesh，Edge Networking，Firewall as a Service etc.），虽然网络代理是一项古老的技术以及产品形态，但是仍然随着基础设施以及业务的变化以新的能力和角色展现在世人眼前。

网络代理的十年

网络代理技术一直围绕“高效接入，访问加速，稳定高可用，安全合规”四个关键词，不断升级核心能力，架构以及运维能力，底层基础网络物理带宽从1G到10G、25G、100G；阿里骨干广域网络走出杭州扩展到全国、全球规模，不断地通过前瞻技术架构研发，技术自主能力的提升和转变，助力业务发展。

蚂蚁金服应用网络架构概览

产品理念

我们应该以什么样的业务设计来满足上层业务以及市场的需要？产品理念决定了产品的走向，我们设定了网络产品的核心理念模型：

网络产品设计理念

接入层代理十年变迁

接入层网络代理的十年变迁之路，我们可以总结为三个时代，四个阶段：PC 时代，移动时代和万物互联云原生时代，伴随着这三个时代，我们经历了四个关键路径。

前世

2010年前蚂蚁金服网络代理是商用设备的时代，包括 F5 的 bigip，Netscaler 等产品，对于商业设备白盒化，大家比较熟知的是去 IOE，其实网络设备走在了更前面。使用商用设备主要有几个问题，厂商的 Lockin，成本以及灵活扩展等问题，所以从2010年蚂蚁金服开始向自主研发演进。

自主研发

我们同时开启了四七层网络接入的自研之路，四七层网络由于场景的不同，在整个演进路线上也有较大的差异。

四层负载均衡

四层网络由于不理解业务语义，主要进化路线是伴随着系统技术，硬件技术的变化，围绕提高吞吐，降低延迟的目标而演进。2014年全面使用 DPDK 进行技术重构，将传统基于内核技术的 IPVS 新建，转发指标分别从万级，十万级提高到百万和千万级的每秒包转发。

同时随着 Ebpf，Xdp 技术的出现，基于内核的高速转发平面产品又横空出世（包括 Facebook 开源的 Katran）打破了 DPDK 技术的垄断，同时可编程交换芯片以及 P4 语言也加入了这一站场，这里不具体讨论每种技术的优劣。

Spanner

Spanner 是蚂蚁金服的统一接入网关，其意为扳手，主要是为蚂蚁金服 SSL 卸载和网络接入提供了白盒化解决方案，承载了蚂蚁金服所有的业务流量，包括支付宝 App，Web，商户等的终端访问。

金融级三地五中心架构的流量调度

上图展示了 Spanner 的编年史，在2013年蚂蚁金服上架了自己的逻辑数据中心架构 LDC，同时随着演进支持了目前的蚂蚁金服金融级的三地五中心容灾架构：

为了支持这套架构，蚂蚁金服的所有基础设施都进行了改造和技术升级，流量调拨能力作为最基础的能力，是一个基本盘，Spanner 通过对请求头的识别以及全站转发规则映射来实现流量调度，支撑并不限于以下场景：

机房内随机路由；
蓝绿发布；
容灾：
- 逻辑机房内容灾；
- 机房级别；
- 城市级别；
弹性调度；
压测流量调度；
灰度流量调度；

SSL/TLS 实践

蚂蚁金服作为全集团最早实践 https 全站的 BU，一直围绕着安全，合规，性能的主题进行全站加密体系的建设。

成本之战

前面提到2012年 Spanner 全面上线后，我们接入层具备了定制业务逻辑的能力，在2013年很好支撑了 LDC 的上线，同时我们在性能成本方面也有机会去进行持续的提升，同年我们引入 SSL 加速卡软硬件一体解决方案，从现在来看该套方案已经非常成熟了，集团 Tengine，Openssl 都提供了非常方便的接入框架，但是当年这一块还一直处于探索阶段。我们在 Spanner 里做了 Nginx 的 SSL 握手异步化改造，改造了 Openssl 同 Cavium 的 SSL 加速卡进行适配，整套方案在当时的机型上较 CPU 提升了基于 RSA2048 算法的 SSL 握手3倍的性能，同时也对后续各大厂商在这方面的实践产生了指导性意义。

性能之战

在解决了全站 SSL 带来的成本提升问题后，协议性能以及用户体验问题摆在了我们面前，2018年8月，互联网工程任务组（IETF）正式发布 TLS1.3 协议的最终版本（RFC 8446）。该协议在安全性、性能和隐私方面有重大改进，大大提升 HTTPS 连接的速度性能。同年9月 Openssl 也宣布发布其最新版本 openssl1.1.1，支持 TLS1.3。但大家可以看到，无论是协议还是实现都在2018年才真正 Realese，但是在2014，2015年我们已经面临了移动网络下的 SSL 带来的问题，最终我们基于 TLS1.3 草案，在 TLS1.2 上以扩展形式实现了：

1RTT，0RTT 减少握手延迟；
Cache Info 扩展缓存证书等服务端信息，避免再次握手时重复传输数据；
ECDHE-keyshare 扩展；
ECC-signature 扩展使用高效 ECDSA 签名算法的同时，兼容广泛使用的 RSA 证书；
Small Ticket 自定义 Session Ticket 编码格式，从160 byte -> 76 byte；我们提前享受了 TLS1.3 带来了红利同时在此基础上做了更多优化，沉淀了蚂蚁金服的轻量级 mTLS 加密库。

安全合规能力持续提升

央行、国家密码管理局、支付清算协会等开启了非银行支付机构的国产密码落地改造工作，蚂蚁金服也全面开始拥抱监管，安全可控以及金融科技的能力建设。我们将此前在加密库，Openssl 等方面的积累沉淀再启程，打造了Babassl 库（阿里经济体共同打造）：

Brisk and Better assurance SSL；
基于Openssl；
合并经济体内部对 Openssl 的定制修改；
全面兼容现有国家密钥安全体系，并在此基础上推出了性能更优的国密+tls1.3单证书标准；
支持 SGX 等可信机制；
轻量级，适配多终端；

同时我们有 Openssl 亚洲唯一 committer 杨洋加持。

移动无线战役

伴随着 ALL IN 无线的集团战略的推进、支付宝 App 使用的人数增长和场景复杂化，我们同支付宝网络团队于2015年合作进行了名为“一网打尽”的移动技术整治专项，在介绍具体的技术改造前，我们先来看看移动互联网场景的问题：

端到端的无线网络复杂性；
运营商网络黑盒；
无线终端的长时在线性；

具体到支付宝 App，线上支付、线下支付、大促、境外游支付等为常见的场景，而操作响应慢、无响应、支付缓慢、push 消息不及时等都是令人头痛的移动体验，所以我们围绕快速稳定和高效进行一场移动无线战役，这里将着重分析在 Spanner 上进行的技术改造。

咻一咻的并发挑战

网络通道方面是一个持续建设过程。此前我们基于 TCP 通道以及 SPDY 私有帧打造了一套高效的端到端的网络链路，一网打尽网络专项主要对流量通道进行了持续升级和流量收编，将 RPC 链路，Push 链路统一。由于当时的背景，HTTP2 并没有完备的实现，同时不支持双向全双工通信，HTTP2 也并没有对移动网络量身定做非常多的优化。基于此我们在统一通道上实现了新的协议 MMTP（蚂蚁无线传输协议）以及 MTLS（SSL/TLS 实践中提到），我们将Hpack 进行了动态化，同时进入基于 Zstd 的动态字典压缩算法，同时在实现上对包大小的追求到了极致，较之前的网络体验提升非常明显。在2015年的春晚红包中，我们支撑了3亿终端用户同时在线，数千万每秒的咻一咻点击。

经此一役，我们构建了统一接入双工通道，实现了移动网络通信的确定性，最终具备数亿活跃设备触达、上亿设备同时在线、体验可靠流畅的云管端通道技术能力，在此之后沉淀为蚂蚁金融科技移动产品 mPass 的网络接入组件。

万物互联云原生

这一阶段是我们再启程的阶段，通过前面个阶段的锤炼，我们的接入层已成体系，具备了持续集成，快速迭代的底座，为更好支持业务的不确定性提供了坚实的底盘。我们同蚂蚁安全团队、支付宝网络团队共同持续进行安全合规加强，网络体验提升的技术能力加强。

物联设备接入

基于 Spanner，我们实现了 MQTT 协议可以通过非常小的接入成本实现新的设备和协议的接入。目前我们支持了 MQTT 协议的 IoT 设备接入，包括支付宝收银盒等产品形态。

安全防攻击

在安全防攻击方面蚂蚁接入层一直在持续演进，通过和蚂蚁安全团队共建的 WAF，流量镜像等，完备了接入层的安全合规体系。

通信协议与架构升级

在高效接入方面蚂蚁接入层一直在持续演进，通过引入 QUIC 协议，蚂蚁全球加速节点来提升扫码支付，商户支付，境外游，海外钱包等的用户体验。

QUIC较优实践

引入 QUIC LB 解决 QUIC 连接迁移难题；
多进程轮转 Listen 解决 Server 平滑升级；
服务不可用的网络 Reset；
UDP 数据包高吞吐内核调优；
0RTT token 校验，防重放攻击；
客户端 MTU 探测；

蚂蚁全球网络加速

为了提升境外游，蚂蚁海外站点等的蚂蚁金融用户体验，我们利用阿里集团全球的骨干网络，基于蚂蚁网络接入层技术建设了蚂蚁全球网络加速节点。

云原生生态融合

目前互联网最流行的词非“云原生”莫属，通过业务与基础设施解耦带来生产力解放的同时，传统基础设施的边界越来越模糊，IaaS 与 PaaS 将在一定程度上融合。目前传统的网络接入代理（包括 Spanner）仍然是以独立于应用生命周期的方式，通过中间层（多为自身管控平面）与业务服务进行关联，这样导致维护成本颇高，在服务通信 mesh 化后，接入层也可以通过下沉到中间件方式，从而达到基础设施融合的目的。在网络代理数据平面方面 CNCF 正在筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API，为 L4/L7 数据平面配置提供事实上的标准。后续有望看到东西，南北流量代理均兼容 UDPA，从而编织出一张全局统一调度的云原生网络。

Mesh 架构下的网络代理

服务发现与路由

东西流量的服务发现与路由，其实是一个去网络代理的过程，我们可以看到从初期的集中式代理演进到了服务配置中心的点对点通信，但是在云原生微服务的演进过程中，我们又对网络代理有了新的要求。这里我不再着重描述 Service Mesh 是什么，能解决什么问题，只是稍作强调一下在 Service Mesh 场景下，网络代理又以新的方式回来了，他站在每一个服务的旁边帮助服务打理与业务无关的各种网络以及服务治理问题（负载均衡，服务路由，鉴权等）。

为金融业务而生的 SOFAMesh

蚂蚁金服于2017年开始探索 Service Mesh，2018年开始自研 Sidecar-SOFAMosn 以及控制平面（整体产品SOFAMesh），2019年上半年开始落地支撑了618部分业务，2019年下半年全面铺开迎接双十一大促，目前对外公布数据是覆盖交易核心链路100+应用，数十万容器实例，目前正在静待今年双十一的验证。

可以看到蚂蚁金服 SOFAMesh 在架构演进上的决心非常大，目前已经到了中盘拿结果阶段，为什么蚂蚁金服需要 Service Mesh：

拥抱微服务，云原生；
异构语言体系融合；
统一服务治理；
运维体系有利支撑；
全局流量管理，打通南北，东西；
金融级网络安全；

Service Mesh 架构带来的红利都是蚂蚁金服所需要的，这里不再多介绍，而对于金融级网络安全我可以多做一些描述。

我们通过 Mesh 化支持了服务的全链路加密以及服务鉴权，在金融场景同时支持国密算法，拥抱监管合规。同时控制平面适配蚂蚁金服 KMI 系统，能达到金融级的秘钥管理能力，同时在 Mesh 代理 SOFAMosn 上实现了 Mirroring 流量功能，通过实时分析服务通信流量构筑强大的金融风控系统。至此从研发，测试，灰度，生产打造了全安全生命周期 Service Mesh 架构，支撑了蚂蚁金服的各种业务。

云原生安全网络代理 SOFAMosn

SOFAMosn：

https://github.com/sofastack/sofa-mosn

Written in go

前面提到蚂蚁金服自研了 Golang 版本的网络代理 SOFAMosn：

为什么我们要自研？
为什么我们不用 Spanner？
为什么不使用社区方案 Envoy、Linkerd？

其实在研发初期，我们已经预料到作为下一代蚂蚁金服的基础架构，Mesh 化势必带来革命性的变革以及演进成本，我们有非常宏大的蓝图：准备将原有的网络和中间件方面的各种能力重新沉淀和打磨，打造成为未来新一代架构的底层平台，承载各种服务通讯的职责。

这是一个需要多年时间打造，满足未来五年乃至十年需求的长期规划项目，合作共建团队跨业务，SRE，中间件，基础架构等。我们必须有一个具备灵活扩展，高性能，满足长期演进的网络代理转发平面。Spanner、Envoy 在研发效率、灵活扩展等方面均有不满足的地方，同时在整个 Mesh 改造涉及到非常多的部门和研发人员，必须考虑到跨团队合作的落地成本，所以我们基于 Golang 栈自研了云原生场景下的新型网络代理 SOFAMosn。对于 Golang 的性能，我们前期也做了充分的调研和测试，在 Service Mesh 场景下单 Sidecar 的性能从来都不是需要最高优先级考虑的问题，往往对性能 RT 有极致要求的业务目前看来并不适合 Mesh 架构。

SOFAMosn 能力与模块划分

SOFAMosn 主要划分为以上几个模块，我们可以基于 Stream、Net 等进行能力扩展，下面会讲到。

SOFAMosn 协程模型

Golang 体系下，我们使用轻量级的协程进行基础架构，一条 TCP 连接对应一个 Read 协程，执行收包、协议解析，一个请求对应一个 Worker 协程，执行业务处理、Proxy 和 Write 逻辑。

SOFAMosn 能力扩展

协议扩展

通过使用同一的编解码引擎以及编/解码器核心接口，提供协议的 plugin机制，目前已经支持：

SOFARPC；
HTTP1.x/HTTP2.0；
Dubbo；

NetworkFilter 扩展

通过提供 Network Filter 注册机制以及统一的 Packet Read/Write Filter 接口，实现了 Network Filter 扩展机制，当前支持：

TCP proxy；
Fault Injection；

StreamFilter 扩展

通过提供 Stream Filter 注册机制以及统一的 Stream Send/Receive Filter 接口，实现了 Stream Filter 扩展机制，包括支持：

流量镜像；
RBAC 鉴权；

心跳检查扩展 Demo

基于 xDS 的动态配置

Mesh 场景下网络代理的挑战

从前面的介绍可以得知，网络接入层最大的挑战就是应对海量洪峰流量时的高效性，而作为 Mesh 场景的大规模落地，除此之外还有更多需要考虑的问题：

不同的应用，部分 Mesh 化；相同的应用，部分 Mesh 化；TLS 链路的兼容等。我们必须做到任何场景下保证可正常处理请求，做到可灰度、可回滚的兼容，平滑迁移；
通用的框架能力（SOFAMosn/Envoy）无法直接满足复杂的、定制的业务能力，需要进行针对性的更加灵活扩展实现；
需要融合已有的应用服务体系，如注册中心、配置中心等，做到行为的一致性；
大规模场景下需要面对的资源分配，自动化问题、性能问题，稳定性问题；

下面我主要谈谈大规模下的问题，数十万实例对控制平面性能，稳定性带来巨大挑战以及单实例数万路由节点，数千路由规则，不仅占用内存，对路由匹配性能也有较大影响。在服务发现方面，海量高频的发布订阅动作对网络代理的稳定性和性能也带来挑战。微服务的治理和运维同样一直都是一个难题，Mesh化后独立出来的网络代理需要融入到云原生业务体系里统一对待，所以SOFAMosn的独立平滑升级，良好的发布策略等都是非常重要的。

平滑升级

由于 Sidecar 作为基础设施的特殊性，我们需要达到基础设施升级的业务无感知的目的，传统的网络代理例如 Nginx 通过关闭老进程的 Listen 端口来做到新进程接管新连接和请求的目的，这种方案对于 HTTP 等短连接 Ping-Pong 协议是非常有效的，但是无法很好支持长连接的双向流式协议。所以我们在 SOFAMosn 上实现了连接迁移能力，达到网络代理升级过程中的连接平滑迁移，保证服务的持续性。通过 sendmsg 以及 TCP_REPAIR 都可以做到套接字的迁移，其实在此种场景中套接字的迁移能很好实现，整个连接的 session 恢复会是比较麻烦的过程。

资源问题

当网络代理 SOFAMosn 作为 Sidecar 部署时，我们面临了新的挑战，不再像 Spanner 一样独占物理机，或者以独立应用的容器化方式只用关心自己的能力以及资源消耗，我们必须精细化 CPU，内存等资源，才能达到与应用最优的协同合作方式。

性能数据

上图是一个简单的同 Envoy 的性能测试，测试双方使用默认配置没有使用任何调优，仅供参考。

总结与思考

关于未来：

云原生，多云混合云时代，南北，东西流量的边界逐渐模糊；
应用网络代理层部分能力固化，下沉至系统网络栈或者智能硬件设备；
Sidecar -> Proxyless -> Networkless；
物理通信基础设施的升级势必带来应用网络层的变革；

回望这十年，是商业的发展不断推动着系统演进的十年，又是技术演进不断成就着商业的奇迹的十年，我们经过十年沉淀，建设了一套金融级的通信安全基础设施，具备全局调度能力的应用层网络 SDN 系统，新的基础软件，生态以及硬件在不断迭代，提供越来越极致的架构改变和性能提升，技术的进步又会驱动业务不断去拓展未曾接触或曾经无法解决的问题领域，给我们带来更大挑战，所以我们将来更需要密切把握技术脉搏、兼具全局视野，以帮助我们做出关键判断，未来已来，让我们与时代同行，期待下一个十年。

作者介绍：

肖涵（涵畅），蚂蚁金服高级技术专家。2011年加入蚂蚁金服，一直从事四/七层网络负载均衡，高性能代理服务器，网络协议相关的研发工作，目前是蚂蚁金服系统部应用网络组负责人。

本文转载自公众号金融级分布式架构（ID：Antfin_SOFA）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247485543&idx=1&sn=a79a3a07ef733d3a8a66543eee2aa187&chksm=faa0e7bdcdd76eabdfe30d31f4034f818adcf449b33959fe6c3a8f3321cb64fbc4ed4302d738&scene=27#wechat_redirect

创作场景

从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路