双 11 是一个疯狂的日子，不仅仅是消费者和电商行业的盛宴，也是技术领域的一次挑战。第一分钟 13.6 万笔交易，单日交易额达到 191 亿，为了支撑如此庞大的交易，支付宝背后的团队功不可没，在 11 月 11 号下午双 11 还未完全落幕之前，InfoQ 就来到在支付宝大楼采访了支付宝的 CTO 李静明，听他谈支付宝为这次双 11 所做的准备以及现场指挥等情况。
李静明首先从购物前、购物中、购物后三个角度分析了支付宝所起到的作用，用户在天猫或者淘宝所见到的红包都是由支付宝团队负责，并且所有的交易创建、支付、确认完成等交易动作都是由支付宝来支撑，支付宝是整个购物环节完成的最后一环。
从 2005 年开始，支付宝经历了烟囱型、面向服务型和云平台型三个时期。李静明说目前支付宝是第三代系统架构，能够保证 1 亿 + 的交易量、80 亿 + 的数据库事务、1000 亿 + 服务调用和 500+ 个应用协同完成。第三代系统主要在可伸缩性、故障容忍、弹性控制三个方面做出了大的改进。系统方面的改进是支付宝一直都在做的事情，他说：
双 11 是对支付宝的一次大考，准备工作很重要，我们把工作都已经做到了平时。
支付宝是这次双 11 活动的重要环节，其系统面临巨大的压力，在 8 月初旬支付宝就成立了“11.11”项目组，主要负责支付服务的容量指标和扩容计划，整个准备工作是一项复杂的系统工程，牵涉到不同的系统和业务平台，支付宝采用的策略是由各个平台根据自己的系统范围和经验来定义场景以及应对措施，根据搜集上来的反馈建立一整套完善的预案。针对这次双 11 活动，他们制定了两百多个预案，每一个预案都详细列出了问题场景、必要的操作、影响范围以及负责人等，通过这段时间的演练保证在预案被触发的第一时间做出反应。李静明说这次双 11 所有发生的状况都是在预案之内，容灾、降级系统都没有被触发。在故障容忍方面，支付宝通过如下的措施使得系统达到了 4 个 9（99.99%）的稳定性：
- 消除数据库单点
- 完善的数据库 failover 机制
- 控制服务依赖处理服务故障的影响
- 通过完全独立的 IDC 解决 IDC 故障
在双 11 之前，支付宝团队根据往年的数据预估了今年的系统容量，2011 年支付宝完成了 3369 万笔交易，他们对今年的预估是去年的 3 倍，事后证明这个预估是正确的（支付宝今年完成了 1 亿零 580 万笔交易）。针对系统将会面临的压力，他们倒推了整个系统流程，在可能出现的环节部署了一些技术措施（如限流等），保证系统稳定。针对于系统中可能出现的资源和计算能力分配不足等问题，支付宝能够通过弹性控制进行秒级的系统监控和资源调度，在网络、数据库和 IDC 等多个层面上满足伸缩性的要求。但是，他还说道，虽然整体趋势的预估不会有太大的出入，但对于刚开始那一瞬间的系统压力是很难估计的，这也造成了今年凌晨过后很多用户出现了排队的现象。李静明说今年整体的运行状况都是在计划内，但还是有一个小遗憾：用户的引导做的不够好，导致一部分用户看到了不一致的文案造成了误解。
双 11 时期支付宝的所有系统监控和调度都是通过“作战指挥室”来统一指挥，通过远程视频的方式和天猫、淘宝等团队进行实时通讯。李静明说他们发现双 11 中支付的瓶颈主要还集中在银行接口方面，为了保证用户的购物能够顺利完成，支付宝采取了一些措施：首先，积极和银行方面沟通，提前做出扩容；其次，引导用户提前在支付宝充值，减少对银行端口的压力；最后，在活动当中通过限流的方式保护银行接口。他提到了一个趣闻，在这次的活动中，有一个银行抱怨他们的量没有上来，要求支付宝不用限流，他们能够抗住所有的交易量。当支付宝停止保护以后，银行的接口立即就陷入瘫痪的状态。
这次的双 11 刷新了国内甚至国际的交易记录，在技术层面上我们也看到了支付宝的表现，当问及是否采用了一些独有的技术时，李静明表示支付宝大部分都是采用的标准技术协议和组件，在使用过程中对其进行了优化。
冰冻三尺非一日之寒，支付宝平时积累的技术力量为这次双 11 大考画上了圆满的句号。
相关阅读
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论