每年“双 11”都是一场电商盛会，消费者狂欢日。今年双 11 的意义尤为重大，它已经发展成为全世界电商和消费者都参与进来的盛宴。而对技术人员来说，双十一无疑已经成为一场大考，考量的角度是整体架构、基础中间件、运维工具、人员等。一次成功的大促准备不光是针对活动本身对系统和架构做的优化措施，比如：流量控制，缓存策略，依赖管控，性能优化……更是与长时间的技术积累和打磨分不开。
支付宝的架构设计上应该考虑到互联网金融业务的特殊性，比如要求更高的业务连续性，更好的高扩展性，更快速的支持新业务发展等特点。目前其架构如下：业务平台（SAAS）(1.随时随地可用的支付服务 2.安全易用的开放支付应用开发平台) 技术平台（PAAS）（1.可伸缩性、高可用的分布式事务处理与服务计算能力 2.弹性资源分配与访问管控） 运维平台（IAAS）（1.基础资源伸缩性 2.组件扩展性 3.系统平台稳定性） 。
在双十一大促当天业务量年年翻番的情况下，支付宝面临的考验也越来越大：系统的容量越来越大，服务器、网络、数据库、机房都随之扩展，这带来了一些比较大的问题，比如系统规模越来越大，系统的复杂度越来越高，以前按照点的伸缩性架构无法满足要求，需要我们有一套整体性的可伸缩方案，可以按照一个单元的维度进行扩展。能够提供支持异地伸缩的能力，提供 N+1 的灾备方案，提供整体性的故障恢复体系。基于以上几个需求，我们提出了逻辑数据中心架构，核心思想是把数据水平拆分的思路向上层提到接入层、终端， 从接入层开始把系统分成多个单元，单元有几个特性：
- 每个单元对外是封闭的，包括系统间交换各类存储的访问 ;
- 每个单元的实时数据是独立的，不共享。而会员或配置类对延时性要求不高的数据可共享 ;
- 单元之间的通信统一管控，尽量走异步化消息。同步消息走单元代理方案；
这套架构解决了几个关键问题：
- 由于尽量减少了跨单元交互和使用异步化，使得异地部署成为可能。整个系统的水平可伸缩性大大提高，不再依赖同城 IDC；
- 可以实现 N+1 的异地灾备策略，大大缩减灾备成本，同时确保灾备设施真实可用；
- 整个系统已无单点存在，大大提升了整体的高可用性；同城和异地部署的多个单元可用作互备的容灾设施，通过运维管控平台进行快速切换，有机会实现 100% 的持续可用率；
- 该架构下业务级别的流量入口和出口形成了统一的可管控、可路由的控制点，整体系统的可管控能力得到很大提升。基于该架构，线上压测、流量管控、灰度发布等以前难以实现的运维管控模式，现在能够十分轻松地实现。
蚂蚁花呗是今年增加的一个新支付工具，“确认收货后、下月还”的支付体验受到了越来越多的消费者信赖。跟余额和余额宝一样，蚂蚁花呗避开了银行间的交易链路，最大限度避免支付时的拥堵。据官方数据披露，在今天的双十一大促中，蚂蚁花呗支付成功率达到 99.99%、平均每笔支付耗时 0.035 秒，和各大银行渠道一起确保了支付的顺畅。
目前从业务和市场的发展形势来看，往往就是需要技术在某个特定时间有个质的能力的提升和飞跃，不会给你太多的准备技术架构提升的时间，在技术积累和人员储备都不足的时候，如何构建平台能力，把更多的精力放在业务相关的开发任务中，是每个技术团队的希望得到的能力 。
过去我们是通过某个开源或者商业组件来实现技术共享得到快速解决谋发展技术的能力的，但是随着业务复杂性，专业性，规模的逐步变大，这种方式的缺点也是显而易见的：1、很多组件根本无法满足大并发场景下的各种技术指标；2、随着业务的复杂和专业性的提高，没有可以直接使用的开源组件；3、“人”本身的经验和能力是无法传递的。
