《蚂蚁金服11.11：支付宝和蚂蚁花呗的技术架构及实践》读后感
我通过阅读《蚂蚁金服11.11：支付宝和蚂蚁花呗的技术架构及实践》通过介绍支付宝的整体架构，并且以“蚂蚁花呗”为例，介绍了软件架构如何开展工作，这让我对软件架构如何展开工作有了一些认识。
这篇文章主要从支付宝的架构、架构特性、分布式数据结构、数据可靠性和蚂蚁花呗几个方面展开叙述。
支付宝的架构主要被分成了三层：
（1）运维平台（IAAS）
（2）技术平台（PAAS）
（3）业务平台（SAAS）
支付宝的架构是逻辑数据中心架构。支付宝在双十一大促时会面临巨大的压力，所以系统规模很大，复杂度也非常高，因此支付宝哟一套整体性的可伸缩方案，可以按照一个单元的维度进行扩展，不再依赖同城IDC，可以实现N+1的异地灾备策略，大大缩减灾备成本，而且业务级别的流量入口和出口形成了统一的可管控、可路由的控制点，整体系统的可管控能力得到很大提升。《蚂蚁金服11.11：支付宝和蚂蚁花呗的技术架构及实践》中对交易系统的数据主要分为三个大数据库集群：
1、主交易数据库集群，每一笔交易创建和状态的修改首先在这⾥完成，产生的变更再通过可靠数据复制中心复制到其他两个数据库集群：消费记录数据库集群、商户查询数据库集群。该数据库集群的数据被水平拆分成多份，为了同时保证可伸缩性和高可靠性，每一个节点都会有与之对应的备用节点和failover节点，在出现故障的时候可以在秒级内切换到failover节点。
2、消费记录数据库集群，提供消费者更好的用户体验和需求；
3、商户查询数据库集群，提供商户更好的用户体验和需求；
因为支付宝对交易的成本比传统金融公司更敏感，所以支付宝数据架构发展，就是一部低成本、线性可伸缩、分布式的数据架构演变史。现在支付宝的数据架构已经从集中式的小型机和高端存储升级到了分布式PC服务解决方案，整体数据架构的解决方案尽量做到无厂商依赖，并且标准化。
《蚂蚁金服11.11：支付宝和蚂蚁花呗的技术架构及实践》一文中提到“纵观现在各种架构分享，大家喜欢谈“谋”的方面较多，各种架构设计方案优化策略分享，但实际最后多是两种情况：“吹的牛X根本没被证实过”（各种框架能力根本没经过实际考验，只是一纸空谈），“吹过的牛X一经实际考验就破了”（说的设计理念很好，但是一遇到实际的大业务的冲击系统就挂了），最后能成功的少之又少。这些说明虽然架构上的“心灵鸡汤”和“成功学”技术人员都已经熟的不行，但是发现一到实践其实根本不是那么回事。从此可以看出，其实最后起决定作用的不是 “谋”方面的理论层面的分析设计，最重要的是落地“器”和“将”的层面。”
文章中的“谋”，“器”，“将”分别是指整体的架构设计方案和策略、支持技术工作的各种基础中间件和基础组件和通过实践锻炼成长起来的技术人员。大多数人认为架构设计方案和策略更为重要，但是通过大多数成功的案列发现，有过硬高稳定性的各种基础设施工具的和身经百战被“虐了千百次”的技术人员的支撑才是最后取胜的关键，而且这两个方面不是可以通过学习别的架构和成功案列就可以的，是要通过自身的积累和业务自身的特性总结出来的。
过去我们是通过某个开源或者商业组件来实现技术共享得到快速解决谋发展技术的能力的，但是随着业务复杂性，专业性，规模的逐步变大，这种方式的缺点也是显而易见的：
1、很多组件根本无法满足大并发场景下的各种技术指标；
2、随着业务的复杂和专业性的提高，没有可以直接使用的开源组件；
3、“人”本身的经验和能力是无法传递的。
所以现在我们通过“云”分享的技术和业务的能力的方式也发展的越来越快。