本文做者:肖涵(涵畅)git
上篇文章《诗和远方:蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中,介绍了 Service Mesh 在蚂蚁金服的落地状况和即未来临的双十一大考,帮助你们了解 Service Mesh 将来发展方向和前景。蚂蚁金服持续在进行 Service Mesh 布道和交流。本文内容整理自 10 月 26 日 Service Mesh Meetup#7 成都站主题演讲,现场视频以及分享 PPT 获取方式见文章底部。github
从网络硬件设备到自研平台,从传统服务治理到 Service Mesh,本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付,千万春晚咻一咻的。web
在云计算和 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;阿里骨干广域网络走出杭州扩展到全国、全球规模,不断地经过前瞻技术架构研发,技术自主能力的提高和转变,助力业务发展。session
咱们应该以什么样的业务设计来知足上层业务以及市场的须要?产品理念决定了产品的走向,咱们设定了网络产品的核心理念模型:
网络产品设计理念
接入层网络代理的十年变迁之路,咱们能够总结为三个时代,四个阶段:PC 时代,移动时代和万物互联云原生时代,伴随着这三个时代,咱们经历了四个关键路径。
2010年前蚂蚁金服网络代理是商用设备的时代,包括 F5 的 bigip,Netscaler 等产品,对于商业设备白盒化,你们比较熟知的是去 IOE,其实网络设备走在了更前面。使用商用设备主要有几个问题,厂商的 Lockin,成本以及灵活扩展等问题,因此从2010年蚂蚁金服开始向自主研发演进。
咱们同时开启了四七层网络接入的自研之路,四七层网络因为场景的不一样,在整个演进路线上也有较大的差别。
四层网络因为不理解业务语义,主要进化路线是伴随着系统技术,硬件技术的变化,围绕提升吞吐,下降延迟的目标而演进。2014年全面使用 DPDK 进行技术重构,将传统基于内核技术的 IPVS 新建,转发指标分别从万级,十万级提升到百万和千万级的每秒包转发。
同时随着 Ebpf,Xdp 技术的出现,基于内核的高速转发平面产品又横空出世(包括 Facebook 开源的 Katran)打破了 DPDK 技术的垄断,同时可编程交换芯片以及 P4 语言也加入了这一站场,这里不具体讨论每种技术的优劣。
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 上以扩展形式实现了:
Ticket 编码格式,从160 byte -> 76 byte;
咱们提早享受了 TLS1.3 带来了红利同时在此基础上作了更多优化,沉淀了蚂蚁金服的轻量级 mTLS 加密库。
安全合规能力持续提高
央行、国家密码管理局、支付清算协会等开启了非银行支付机构的国产密码落地改造工做,蚂蚁金服也全面开始拥抱监管,安全可控以及金融科技的能力建设。咱们将此前在加密库,Openssl 等方面的积累沉淀再启程,打造了Babassl 库(阿里经济体共同打造):
同时咱们有 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较优实践
蚂蚁全球网络加速
为了提高境外游,蚂蚁海外站点等的蚂蚁金融用户体验,咱们利用阿里集团全球的骨干网络,基于蚂蚁网络接入层技术建设了蚂蚁全球网络加速节点。
目前互联网最流行的词非“云原生”莫属,经过业务与基础设施解耦带来生产力解放的同时,传统基础设施的边界愈来愈模糊,IaaS 与 PaaS 将在必定程度上融合。目前传统的网络接入代理(包括 Spanner)仍然是以独立于应用生命周期的方式,经过中间层(多为自身管控平面)与业务服务进行关联,这样致使维护成本颇高,在服务通讯 mesh 化后,接入层也能够经过下沉到中间件方式,从而达到基础设施融合的目的。在网络代理数据平面方面 CNCF 正在筹建通用数据平面 API 工做组(Universal Data Plane API Working Group / UDPA-WG),以制定数据平面的标准 API,为 L4/L7 数据平面配置提供事实上的标准。后续有望看到东西,南北流量代理均兼容 UDPA,从而编织出一张全局统一调度的云原生网络。
服务发现与路由
东西流量的服务发现与路由,实际上是一个去网络代理的过程,咱们能够看到从初期的集中式代理演进到了服务配置中心的点对点通讯,可是在云原生微服务的演进过程当中,咱们又对网络代理有了新的要求。这里我再也不着重描述 Service Mesh 是什么,能解决什么问题,只是稍做强调一下在 Service Mesh 场景下,网络代理又以新的方式回来了,他站在每个服务的旁边帮助服务打理与业务无关的各类网络以及服务治理问题(负载均衡,服务路由,鉴权等)。
蚂蚁金服于2017年开始探索 Service Mesh,2018年开始自研 Sidecar-SOFAMosn 以及控制平面(总体产品SOFAMesh),2019年上半年开始落地支撑了618部分业务,2019年下半年全面铺开迎接双十一大促,目前对外公布数据是覆盖交易核心链路100+应用,数十万容器实例,目前正在静待今年双十一的验证。
能够看到蚂蚁金服 SOFAMesh 在架构演进上的决心很是大,目前已经到了中盘拿结果阶段,为何蚂蚁金服须要 Service Mesh:
Service Mesh 架构带来的红利都是蚂蚁金服所须要的,这里再也不多介绍,而对于金融级网络安全我能够多作一些描述。
咱们经过 Mesh 化支持了服务的全链路加密以及服务鉴权,在金融场景同时支持国密算法,拥抱监管合规。同时控制平面适配蚂蚁金服 KMI 系统,能达到金融级的秘钥管理能力,同时在 Mesh 代理 SOFAMosn 上实现了 Mirroring 流量功能,经过实时分析服务通讯流量构筑强大的金融风控系统。至此从研发,测试,灰度,生产打造了全安全生命周期 Service Mesh 架构,支撑了蚂蚁金服的各类业务。
SOFAMosn:https://github.com/sofastack/sofa-mosn
Written in go
前面提到蚂蚁金服自研了 Golang 版本的网络代理 SOFAMosn:
其实在研发初期,咱们已经预料到做为下一代蚂蚁金服的基础架构,Mesh 化势必带来革命性的变革以及演进成本,咱们有很是宏大的蓝图:准备将原有的网络和中间件方面的各类能力从新沉淀和打磨,打形成为将来新一代架构的底层平台,承载各类服务通信的职责。
这是一个须要多年时间打造,知足将来五年乃至十年需求的长期规划项目,合做共建团队跨业务,SRE,中间件,基础架构等。咱们必须有一个具有灵活扩展,高性能,知足长期演进的网络代理转发平面。Spanner、Envoy 在研发效率、灵活扩展等方面均有不知足的地方,同时在整个 Mesh 改造涉及到很是多的部门和研发人员,必须考虑到跨团队合做的落地成本,因此咱们基于 Golang 栈自研了云原生场景下的新型网络代理 SOFAMosn。对于 Golang 的性能,咱们前期也作了充分的调研和测试,在 Service Mesh 场景下单 Sidecar 的性能历来都不是须要最高优先级考虑的问题,每每对性能 RT 有极致要求的业务目前看来并不适合 Mesh 架构。
SOFAMosn 主要划分为以上几个模块,咱们能够基于 Stream、Net 等进行能力扩展,下面会讲到。
Golang 体系下,咱们使用轻量级的协程进行基础架构,一条 TCP 链接对应一个 Read 协程,执行收包、协议解析,一个请求对应一个 Worker 协程,执行业务处理、Proxy 和 Write 逻辑。
协议扩展
经过使用同一的编解码引擎以及编/解码器核心接口,提供协议的 plugin 机制,目前已经支持:
NetworkFilter 扩展
经过提供 Network Filter 注册机制以及统一的 Packet Read/Write Filter 接口,实现了 Network Filter 扩展机制,当前支持:
proxy;
StreamFilter 扩展
经过提供 Stream Filter 注册机制以及统一的 Stream Send/Receive Filter 接口,实现了 Stream Filter 扩展机制,包括支持:
心跳检查扩展 Demo
从前面的介绍能够得知,网络接入层最大的挑战就是应对海量洪峰流量时的高效性,而做为 Mesh 场景的大规模落地,除此以外还有更多须要考虑的问题:
下面我主要谈谈大规模下的问题,数十万实例对控制平面性能,稳定性带来巨大挑战以及单实例数万路由节点,数千路由规则,不只占用内存,对路由匹配性能也有较大影响。在服务发现方面,海量高频的发布订阅动做对网络代理的稳定性和性能也带来挑战。微服务的治理和运维一样一直都是一个难题,Mesh化后独立出来的网络代理须要融入到云原生业务体系里统一对待,因此SOFAMosn的独立平滑升级,良好的发布策略等都是很是重要的。
平滑升级
因为 Sidecar 做为基础设施的特殊性,咱们须要达到基础设施升级的业务无感知的目的,传统的网络代理例如 Nginx 经过关闭老进程的 Listen 端口来作到新进程接管新链接和请求的目的,这种方案对于 HTTP 等短链接 Ping-Pong 协议是很是有效的,可是没法很好支持长链接的双向流式协议。因此咱们在 SOFAMosn 上实现了链接迁移能力,达到网络代理升级过程当中的链接平滑迁移,保证服务的持续性。经过 sendmsg 以及 TCP_REPAIR 均可以作到套接字的迁移,其实在此种场景中套接字的迁移能很好实现,整个链接的 session 恢复会是比较麻烦的过程。
资源问题
当网络代理 SOFAMosn 做为 Sidecar 部署时,咱们面临了新的挑战,再也不像 Spanner 同样独占物理机,或者以独立应用的容器化方式只用关心本身的能力以及资源消耗,咱们必须精细化 CPU、内存等资源,才能达到与应用最优的协同合做方式。
关于将来:
回望这十年,是商业的发展不断推进着系统演进的十年,又是技术演进不断成就着商业的奇迹的十年,咱们通过十年沉淀,建设了一套金融级的通讯安全基础设施,具有全局调度能力的应用层网络 SDN 系统,新的基础软件,生态以及硬件在不断迭代,提供愈来愈极致的架构改变和性能提高,技术的进步又会驱动业务不断去拓展不曾接触或曾经没法解决的问题领域,给咱们带来更大挑战,因此咱们未来更须要密切把握技术脉搏、兼具全局视野,以帮助咱们作出关键判断,将来已来,让咱们与时代同行,期待下一个十年。
此次蚂蚁金服 Service Mesh 上双十一,将是 Service Mesh 的历史时刻:Service Mesh 首次超大规模部署,欢迎对 Service Mesh 感兴趣的同窗持续关注本号,在双十一以后将会分享一系列蚂蚁金服 Mesh 化相关文章,与你们交流分享。
本文做者:肖涵(涵畅),蚂蚁金服高级技术专家。2011年加入蚂蚁金服,一直从事四/七层网络负载均衡,高性能代理服务器,网络协议相关的研发工做,目前是蚂蚁金服系统部应用网络组负责人。