公司新闻

首页 > 公司新闻 > 正文

蚂蚁金服亿级并发下的移动端到端网络接入架构解析

2019年01月01日 热度:639 ℃

导读

支付宝移动端架构已完成了工具型App、平台型App,以及超级App三个阶段的迭代与逐步完善。

本文将重点聚焦支付宝在移动网络接入架构的具体演进,以及应对新春红包等项目在亿级并发场景下的具体应对之道。此外,还将延展探讨蚂蚁金服移动网络技术如何对外商业化应用和输出。

一. 蚂蚁金服移动网络接入架构演进

支付宝移动网络第一代架构

最初的支付宝app整体架构可以简单称之为单应用架构。单应用包括两部分,客户端APP和服务器,通过https进行通信。

由于无线业务的逐步发展,许多业务需要从PC迁到无线,越来越多的开发要投入到无线上,但是当时的架构无法支撑多业务多团队的并行研发。每个业务功能要拉一个分支,N个业务同时要拉N个分支,合并代码也是很痛苦的,整个架构成为很大的瓶颈。

支付宝移动网络第二代架构

后来针对支付宝App架构进行了升级,引入了API网关架构:把后端服务抽象为一个个接口对外提供服务,可以拆成各种各样的服务,每一个系统的研发与发布跟其他的系统没有关系,并且支持多端应用接入,比如口碑APP、支付宝主APP。

最重要的是引入了移动RPC研发模式,有一个中间态的DSL的RPC定义,可以生成多端代码,中间的通信细节全部由RPC框架负责,客户端只需关心业务。

API网关架构提供了完善的API服务生命周期,可以定义为从API研发到发布上线、配置、服务上线、服务运营等,直到最后的下线。在研发支撑过程还做了很多工具,比如说代码生成、API测试工具等。针对服务上线之后的运行支付宝APP有一套完整的监控体系,包括会给每一个API打分,比如API的响应时间、数据传输大小、响应时间等,比如当错误率超过一个法定值时,会发邮件预警。还有很多客户端和服务器的诊断功能,可以提供全平台式的应用支持。

此外,还引入了无线RPC的机制。

研发时,服务端工程师开通接口,自动拉取服务,接入到网关后台;业务工程师可以生成各个客户端的RPC代码,发给客户端工程师做集成;客户端工程师依靠RPC代码发到网关,由网关转发到业务服务器。整个过程非常简单,整体研发效率有很大的提升。

支付宝移动网络第三代架构

再后来支付宝开始尝试做社交。由此,平台化架构的设计优化迫在眉睫,而新的业务场景对App稳定性也提出了更大的挑战和要求,于是移动接入的第三代架构应运而生。

首先对网络协议做了优化,把客户端和服务器通信机制变成一个长链接,自定义了长连接协议MMTP;第二,引入了SYNC机制,服务端可以主动推送同步数据到客户端;第三,引入了移动调度,里面有各种个性化调度,比如机房容灾、白名单调度等。

接下来具体看一下网络协议的优化。

网络传输协议最底层是SSL/TLS,蚂蚁是基于TLS1.3自研了MTLS,上一层是会话层,最开始基于HTTP,现在基于自研的通信协议MMTP,最上层是RPC、SYNC、PUSH应用层协议。

RPC解决“请求 - 响应”的通信模式;SYNC负责“服务器直接推送数据到客户端”的通信模式;PUSH负责“推传统的 PUSH弹框通知”。

另外重新定义了HTTP2,引入H2+私有帧协议,支持了自定义双向通信,HTTP2现在基本上已经定为下一代通信协议,主流的浏览器都已经支持了。同时也引进到移动端,因为它具有多路复用、hpack高可压缩算法等很多对移动网络友好的特性。

接下来讲一下SYNC机制。

本质上SYNC是基于SyncKey的一种同步协议。举个“账单页展示”的例子来解释什么是SYNC:传统意义上客户端要拉取这个人所有的账单,就发RPC请求给服务器,服务器把所有的数据一下子拉回来,很耗费流量。SYNC机制是同步差量数据,这样达到了节省流量的效果,数据量小了通信效率也更高效,客户端拿到服务端数据的成功率更高。

另外对于SYNC机制,客户端还无需实时在线,对于用户不在线的情况,SYNC Server会将差量数据保存在数据库中。当客户端下次连接到服务器时,再同步差量数据给用户。在支付宝内部,在聊天、配置同步、数据推送等场景都应用了 SYNC机制。

关于移动调度设计,实际上移动调度底层是一个HTTPDNS,而不是传统的LocalDNS。

因为传统DNS首先有DNS劫持的问题,而且运营商本身的DNS质量参差不齐,会影响到请求响应的质量,另外它还不支持LDC多中心调度等复杂的自定义调度需求。所以支付宝做了移动的调度AMDC,支持容灾、策略、通道优化、LDC白名单的调度。

支付宝移动网络第四代架构

关于第四代支付宝移动架构演进,主要做了两件事情:第一,统一网络库;第二,网关去中心化。

一方面,客户端平台需要覆盖iOS、Android,此外还有IOT RTOS等平台,未来还需要支持更多端。然而每支持一个平台,都需要重新开发一套网络库;另一方面,客户端网络库有比较丰富且复杂的策略,每个平台上的策略实现也会有不同,这些不同会导致很多意想不到的问题。

基于上述两点,用C语言做统一网络库,可以运行在不同的平台上,所有的客户端网络策略和调度全部统一。这样极大程度地降低了研发成本,每个需求只需要一个研发工程师投入,不同平台升级统一网络库即可。

服务端部分做了网关去中心化的架构升级,中心化的网关有两个问题:第一,容量规划的问题,现在整个支付宝网关平台有近万个接口,每次搞活动前都需要评估接口的请求量,但是峰值请求量很难评估,每次都是定一个大概的容量;另外,网关服务器成本越来越高,每次活动业务量很大,每次都要大量扩容;第二,稳定性问题,API 网关更贴近业务,发布变更比较频繁,有时候因为某个业务而做的变更存在问题,会导致整个网关集群挂掉,影响到所有的业务,无法做到业务级别的隔离。所以做了网关去中心化,去掉了“形式”上的网关,把网关上的API路由能力前置到最上层的接入网关上,把网关核心功能(比如说验签、会话、限流等)抽成一个Jar,集成到业务系统上。

这样有两个好处:

一是性能提升,网关调用业务的远程调用变成了本地JVM调用;

二是稳定性提升,每个业务集成一个稳定版本的网关Jar,某一个业务系统做网关Jar升级时,其他业务系统都不受干扰。

但网关去中心化的缺点也是比较明显,比如版本分裂问题,每次系统集成的网关Jar的版本都不一样,比如发现网关Jar有一个安全漏洞需要升级解决,推动各个业务系统升级Jar是一个比较痛苦的过程,业务系统需要经历集成新版Jar,测试回归,线上发布等复杂的过程。

另外还存在依赖Jar冲突、异构系统不容易集成的问题。Service Mesh的出现带来新的思路,将网关逻辑做到ServiceMesh中的网络代理中,作为Sidecar以独立进程的形式部署到业务系统中,完美支持无损平滑升级,同时也支持异构系统,解决了支付宝内部Nodejs和C语言系统的去中心化的集成问题。

二. 如何应对新春红包亿级并发挑战

从2015年春节开始,支付宝都会做新春红包活动。2016 年,支付宝和春晚合作,“咻一咻”红包,峰值达到了 177 亿 / 分钟,每秒钟将近 3 亿的请求 —— 这样的并发挑战,如何应对?

应对之道

支付宝做大型活动的过程是:首先产品经理在几个月之前确定业务的玩法,技术拿到业务玩法后开始做技术评估,评估出活动峰值的在线用户数、核心业务请求量等核心指标出来之后会评估技术方案。

技术方案依赖于要分析核心链路,然后对所有的系统做容量评估,容量评估以后做限流的方案,最后看能否对整个链路中某些系统或者节点做优化。

最后的重点是,能否对非核心的业务、非核心的功能做依赖度降级。技术方案出来以后会做压测,压测达标之后是活动演练,演练中会发现一些问题,及时修复掉。后续便是准备实战应对,如果其中有问题会做应急的处理。活动结束之后,会将之前做的降级策略,机房弹出等操作进行回滚操作。

我们网络接入层是如何保障大促活动的呢?下面主要针对接入层限流和性能优化做一下分享。

接入层限流

面临的请求量是上亿级的,后端业务肯定撑不住,入口层必须要通过限流的手段保护后端系统。

核心思想是要做一个有损服务,保障核心业务在体验可接受范围内做降级非核心功能和业务。首先调低压缩阈值,降低对性能层的消耗;另外把非核心不重要的接口全部降级,因为这些接口被限流也不会对客户端体验造成影响。

多层级限流机制分为LVS限流接入层限流API网关限流业务层限流

  • LVS 方面:单VIP一个LVS集群一般是4台机器,一个集群LVS肯定扛不住,所以给每个IDC分配多个VIP,多套LVS集群共同承担流量,并且提高抗DDOS攻击的能力。

  • 接入层方面:提供了TCP限流、核心RPC的限流能力。另外在API网关层做了分级限流算法,对不同请求量的接口做了策略,高QPS限流用简单基数算法,超过这个值就直接拒绝掉;对中等QPS做了令牌桶算法,接受一定的流量突发;对低QPS进行分布式限流,保障限流的准确。

TLS 性能优化

网关接入层面对如此海量的请求,必须做好性能的极致优化,为此做了很多性能优化,降低对性能的消耗。

首先分享下TLS的优化,有没有TLS对性能来讲是量级的差别(http和https的差别)。了解加密算法的同学知道,在TLS中性能开销最大的是TLS握手阶段的RSA加解密。为了优化RSA加解密对服务器的性能消耗,几年前的优化策略是硬件加速,将RSA加解密的操作交给一个单独的硬件加速卡处理。随着TLS的不断发展,TLS中的RSA基本被废弃,用最新的ECDSA取代RSA,ECDSA最底层的算法和成本对性能的消耗远低于RSA,相差5-6倍。另外使用Session Ticket机制将TLS从2RTT降低为1RTT,同时极大提升了性能。

压缩算法优化

最常用的压缩算法是gzip,压缩的两个关键指标是:压缩比和压缩/解压速度。有很多开源算法,像gzip、lz4、brotli、zstd,而Facebook的压缩算法zstd 的这两个指标都占优。但是zstd对于字典的要求比较高,通过清洗线上海量数据,得到合适的字典,极大提高了压缩率和压缩性能。

三. 蚂蚁金服移动网络技术商业化应用与输出

一站式移动开发平台mPaaS

蚂蚁移动网络技术的商业化是依托于蚂蚁金服移动开发平台mPaaS。

mPaaS是源于支付宝App近10年的移动技术思考和实践,为移动开发、测试、运营及运维提供云到端的一站式平台解决方案,能有效降低技术门槛、减少研发成本、提升开发效率,协助生态伙伴快速搭建稳定高质量的移动App。移动网络服务在mPaaS中提供了MGS网关服务、MSS数据同步服务、MPS推送服务、MDC调度服务等丰富的网络解决方案。

全面整合蚂蚁金服技术能力

服务端侧的 MGS(网关服务)、MPS(推送服务)、MSS(同步服务)是核心服务,基本上覆盖了请求响应、推送、增量更新三种模式,可以满足大部分的业务应用场景。网关服务的开放版开放版支持HTTP、Dubbo、ZDAS、SOFA-RPC等多种协议,还支持插件式功能,通过插件的方式强化网关功能。MSS服务机制是增量更新的模式,而且可以做顺序推送,比如做聊天,聊天消息必须是一条条到达,不能乱序,而且还可以做到秒级触达。

发表评论
◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

相关文章

自然人办税服务平台APP端用户操作手册V1.0.doc

自然人办税服务平台(ITS)(个人所得税部分)——APP端用户操作手册编写日期:2018年12月12日目  录1. 概述...........................................

杜绝拒付盗刷!这些风控手段代理商需学会

杜绝拒付盗刷!这些风控手段代理商需学会

对于当下的收单市场来说,由于市场比较纷乱缺陷及风控措施的欠缺,导致调单、拒付、盗刷的情况时有发生,有很多代理商经常出现忙活了几个月甚至大半年,结果收到一纸分润被扣光的通知,这是因为有一笔或几笔的拒付盗...

杜晓宇:金融科技在支付结算领域的应用及展望

(一)金融科技在支付结算中发展迅猛,市场竞争激烈  在金融科技在支付结算中的研究方面,发达国家起步较早,美国、欧洲等国家金融机构与相关公司积极进行自身支付结算技术的研究,以推动自身支付结算业务的不断发...

第三方支付经历“冰与火之歌” 年内收到超80张罚单

第三方支付经历“冰与火之歌” 年内收到超80张罚单

金融风控研习社行业探讨/知识分享作为互联网金融最具的代表性的细分赛道之一,第三方支付在过去几年里,彻底改变了人们的生活方式。特别是在移动互联网的普及带动之下,俨然已成为最主流支付方式之一。根据易观数据...

第三方支付正本清源,创新与风控是未来决胜关键

第三方支付正本清源,创新与风控是未来决胜关键

考拉划重点· 第三方支付正本清源(监管力度在加强,遵守规则就好啦~)· 围绕B端需求的共给侧创新空间巨大(迎合用户需求、为大家解决问题是重点~)· 风控与合规是支付机构的生命线(用我们的企业文化来说就...

广东工业大学2019年博士学位研究生招生考试时间公告及报名考试费缴费须知

广东工业大学2019年博士学位研究生招生考试时间公告及报名考试费缴费须知

各位考生:我校2019年博士学位研究生招生考试将于2019年3月9-10日进行。考试时间:上午8:30-11:30,下午14:00-17:00考试地点:广东工业大学大学城校区广东工业大学2019年博士...