网站怎么做图片搜索,wordpress伪静态nginx,wordpress 内容页插件,百度网站怎么做的赚钱吗为了与金融从业者、科技从业者共同探讨金融 业务的深层次问题#xff0c;蚂蚁金服联手 TGO 鲲鹏会上海分会#xff0c;在 12 月 8 日举办了「走进蚂蚁金服#xff1a;双十一背后的蚂蚁金服技术支持」活动。蚂蚁金服高级技术专家贾岛为大家分享了《亿级并发下的蚂蚁移动端到…为了与金融从业者、科技从业者共同探讨金融 业务的深层次问题蚂蚁金服联手 TGO 鲲鹏会上海分会在 12 月 8 日举办了「走进蚂蚁金服双十一背后的蚂蚁金服技术支持」活动。蚂蚁金服高级技术专家贾岛为大家分享了《亿级并发下的蚂蚁移动端到端网络接入架构》主题演讲。本文根据当天演讲整理有部分不改变原意的删减。
讲师介绍蚂蚁金服高级技术专家贾岛
靳文祥花名贾岛2011 年毕业后加入支付宝无线团队参与过悦享拍、支付宝无线网关设计、无线接入、移动网络优化等项目。目前负责蚂蚁金服移动网络接入架构设计与优化。
前言
支付宝移动端架构已完成了工具型 App、平台型 App以及超级 App 三个阶段的迭代与逐步完善。
本次分享将聚焦支付宝在移动网络接入架构的具体演进以及应对新春红包等项目在亿级并发场景下的具体应对之道。此外我们将延展探讨蚂蚁金服移动网络技术如何对外商业化应用和输出。
一. 蚂蚁金服移动网络接入架构演进
支付宝移动网络第一代架构
支付宝无线团队于 2008 年成立那时支付宝 app 整体架构可以简单称之为单应用架构。单应用包括两部分客户端 APP 和服务器通过 https 进行通信。
由于无线业务的逐步发展许多业务需要从 PC 迁到无线越来越多的开发要投入到无线上但是目前的架构无法支撑多业务多团队的并行研发。每个业务功能要拉一个分支N 个业务同时要拉 N 个分支合并代码也是很痛苦的整个架构成为很大的瓶颈。
支付宝移动网络第二代架构
2013 年我们针对 App 架构进行升级引入了 API 网关架构把后端服务抽象为一个个接口对外提供服务可以拆成各种各样的服务每一个系统的研发与发布跟其他的系统没有关系并且支持多端应用接入比如口碑 APP、支付宝主 APP。
最重要的是我们引入了移动 RPC 研发模式有一个中间态的 DSL 的 RPC 定义可以生成多端代码中间的通信细节全部由 RPC 框架负责客户端只需关心业务。API 网关架构提供了完善的 API 服务生命周期可以定义为从 API 研发到发布上线、配置、服务上线、服务运营等直到最后的下线。我们在研发支撑期做了很多工具比如说代码生成、API 测试工具等。针对服务上线之后的运行我们有一套完整监控的体系包括会给每一个 API 打分比如 API 的响应时间、数据传输大小、响应时间等比如当错误率超过一个法定值时会发邮件预警。我们还做了很多客户端和服务器的诊断功能提供全平台式的应用支持。此外我们引入了无线 RPC 的机制。
研发时服务端同学开通接口自动拉取服务接入到网关后台业务同学可以生成各个客户端的 RPC 代码发给客户端同学做集成客户端同学依靠 RPC 代码发到网关由网关转发到业务服务器。整个过程非常简单整体研发效率有很大的提升。
支付宝移动网络第三代架构
2015 年开始支付宝开始尝试做社交。由此平台化架构的设计优化迫在眉睫而新的业务场景对 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 取代 RSAECDSA 最底层的算法和成本对性能的消耗远低于 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 服务机制是增量更新的模式而且可以做顺序推送比如做聊天聊天消息必须是一条条到达不能乱序而且还可以做到秒级触达。MPS 服务在国内我们会自建 PUSH 通道另外在自建通道不可用时会尝试走小米、华为等厂商 PUSH 通道推送保证高可用、高推送率。
以上即关于蚂蚁金服如何构建亿级并发下的移动端到端网络接入架构实践的分享。TGO 鲲鹏会是极客邦科技旗下高端技术人聚集和交流组织目前已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、苏州、武汉全球十一个城市设立分会。现在全球累计 700 多名会员60% 为 CTO、技术 VP、技术合伙人。
如果你想和这些优秀的科技领导者们一起前行目前厦门分会已经成立欢迎点击「报名表单申请加入」。
