支付宝与蚂蚁花呗的技术架构及实践——读后感

　　每年“双11”都是一场电商盛会，消费者狂欢日。今年双11的意义尤为重大，它已经发展成为全世界电商和消费者都参与进来的盛宴。而对技术人员来说，双十一无疑已经成为一场大考，考量的角度是整体架构、基础中间件、运维工具、人员等。

架构

架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。架构描述语言（ADL）用于描述软件的体系架构。现在已有多种架构描述语言，如Wright（由卡内基梅隆大学开发），Acme（由卡内基梅隆大学开发），C2（由UCI开发），Darwin（由伦敦帝国学院开发）。ADL的基本构成包括组件、连接器和配置

支付宝的架构设计上应该考虑到互联网金融业务的特殊性，比如要求更高的业务连续性，更好的高扩展性，更快速的支持新业务发展等特点。目前其架构如下：

　　整个平台被分成了三个层：

1.       运维平台（IAAS）：主要提供基础资源的可伸缩性，比如网络、存储、数据库、虚拟化、IDC等，保证底层系统平台的稳定性；

2.       技术平台（PAAS）：主要提供可伸缩、高可用的分布式事务处理和服务计算能力，能够做到弹性资源的分配和访问控制，提供一套基础的中间件运行环境，屏蔽底层资源的复杂性；

3.       业务平台（SAAS）：提供随时随地高可用的支付服务，并且提供一个安全易用的开放支付应用开发平台。

　　对于分拆出来的各个数据节点，为了保证对上层应用系统的透明，我们研发一套数据中间产品来保证交易数据做到弹性扩容。

　　蚂蚁花呗

　　蚂蚁花呗是今年增加的一个新支付工具，“确认收货后、下月还”的支付体验受到了越来越多的消费者信赖。跟余额和余额宝一样，蚂蚁花呗避开了银行间的交易链路，最大限度避免支付时的拥堵。据官方数据披露，在今天的双十一大促中，蚂蚁花呗支付成功率达到99.99%、平均每笔支付耗时0.035秒，和各大银行渠道一起确保了支付的顺畅。

　　蚂蚁花呗业务中最为关键的一环在于买家授信和支付风险的控制。从买家下单的那一刻开始，后台便开始对虚假交易、限额限次、套现、支用风险等风险模型进行并行计算，这些模型最终将在20ms以内完成对仅百亿数据的计算和判定，能够在用户到达收银台前确定这笔交易是否存在潜在风险。

　　总结

　　经过这么多年的高可用架构和大促的准备工作，蚂蚁金融技术团队可以做到“先胜而后求战”，主要分为三方面技术积累：“谋”，“器”，“将”。

　　“谋”就是整体的架构设计方案和策略；

　　“器”就是支持技术工作的各种基础中间件和基础组件；

　　“将”就是通过实践锻炼成长起来的技术人员。

　　纵观现在各种架构分享，大家喜欢谈“谋”的方面较多，各种架构设计方案优化策略分享，但实际最后多是两种情况：“吹的牛X根本没被证实过”（各种框架能力根本没经过实际考验，只是一纸空谈），“吹过的牛X一经实际考验就破了”（说的设计理念很好，但是一遇到实际的大业务的冲击系统就挂了），最后能成功的少之又少。这些说明虽然架构上的“心灵鸡汤”和“成功学”技术人员都已经熟的不行，但是发现一到实践其实根本不是那么回事。从此可以看出，其实最后起决定作用的不是 “谋”方面的理论层面的分析设计，最重要的是落地“器”和“将”的层面。有过硬高稳定性的各种基础设施工具的和身经百战被“虐了千百次”的技术人员的支撑才是最后取胜的关键。而这个两个层面的问题是不能通过分享学到的，是要通过日积月累的，无数流血流泪趟雷中招锻炼出来的，没有近路可抄。

而目前从业务和市场的发展形势来看，往往就是需要技术在某个特定时间有个质的能力的提升和飞跃，不会给你太多的准备技术架构提升的时间，在技术积累和人员储备都不足的时候，如何构建平台能力，把更多的精力放在业务相关的开发任务中，是每个技术团队的希望得到的能力。

转自：https://blog.csdn.net/javaxuexi123/article/details/79405819