经过多年云计算的蓬勃发展，上云已经不是太大问题，接下来的问题是怎么把云用好，用得更高效。RighScale 2019 年数据显示，目前仅使用公有云的客户占 22%，只使用私有云的客户占 3%，更多客户通过混合的模式去使用云，通过混合云取得数据隐私、安全与效率、弹性的平衡。
再看全球整个 IT 行业，公有云的比例只占整个基础 IT 市场的 10%，市场空间仍然很大，IT 市场中剩下很多都是传统企业客户。为什么传统企业无法很好地利用公有云，一个重要的原因是经过长时间建设，大多企业都拥有自己的机房；另外，有些则是因为业务比较稳定，对上公有云没有很强的需求。它们通常会发展混合云策略，把一些核心业务留在私有云，而把一些边缘业务或创新业务放在公有云上。
这些特点在金融行业也非常明显。除此之外，金融行业还有两个特征：
业务形态走向开放和互联网化——随着互联网和数字化经济的发展，金融机构需要进行数字化转型，以及业务敏捷化、服务场景化，以应对新的商业模式带来的冲击。
监管合规的诉求——金融行业的业务特点决定了它必须是强隔离、强监管的，所以公有云上的资源共享模式在监管方面会有比较大的挑战。
因此，混合云战略对金融机构更为适用。这一结论也得到研究支持，据 Nutanix 的报告显示，全球金融业在混合云应用方面的发展速度超过其它行业，目前部署普及率达到 21%，而全球平均水平为 18.5%。
那么，什么样的混合云是适用金融机构的呢？下面，我们就以蚂蚁的技术架构演进历程为例进行阐述。
第一阶段：集中式
最早支付宝系统是由不太会进行大系统开发的人员实现的。支付宝第一代架构非常简单：一个简单的单体应用，部署在一台应用服务器上，使用一个数据库，服务一个大客户——淘宝。这个简单的系统支撑了支付宝从 2005 到 2006 年早期的发展。它虽然简单，但优点是特别快，产品经理希望怎么改，修改一下代码就能立刻实现，比如支付宝红包，从提出需求到功能上线仅四天时间。但随着业务的发展，这个简单的系统无法支撑更多的交易量以及更加复杂的业务。
第二阶段：分布式
从 2006 年底开始，单体应用的弊端日趋明显，因此支付宝团队做了一个决定，要走一条过去没有人走过的路，于是启动了支付宝第二代架构的建设，即支付宝技术系统的服务化。 当时这套分布式架构起名为“SOFA”，即 Service Oriented Fabric Architecture。第一代的 SOFA 其实就解决两个问题：一是当要把系统变成分布式的时候，怎么有一个像“胶水”的机制，也就是连接器，可以把分布式系连接成一个整体；二是希望每一个服务本身是组件化的。所以当时第一代 SOFA 里采用了 OSGI（一套 Java 模化规范，允许应用程序使用精炼，可重用和可协作的组件构建），这样每个工程师可以专注于各自的组件，最后又能够把这些组件拼装在一起成为“服务”，再把“服务”拼装在一起成为整个大系统。这一整套框架，就是第一代 SOFA 框架。 在解决了服务化的问题后，下一个问题就是如何解决一致性问题。要解决分布式一致性问题，必须要分布式的提交协议。这个协议如果在数据库层实现，效率会非常低下，因为数据库层不懂任何的业务逻辑，只能以一种通用的方式去实现，从而导致无法对上层的业务逻辑层进行优化，所以大家就想到把提交协议放在服务层。大概在 2008 年 1 月份，XTS（eXtended Transaction Service）项目就上线了，上线以后不断打磨，一直到现在还支撑着整个蚂蚁集团的业务交易。
第三阶段：自研平台
本阶段最重要的事情是启动了自研数据库，也就是现在的 OceanBase（OB），并且通过了 SOFA + OB 实现了对“IBM AIX 小机 + Oracle 数据库 + EMC 存储”的替换。至此，蚂蚁整体的金融分布式架构框架搭建完毕。
第四阶段：云平台
蚂蚁的技术架构在第四阶段的时候演变成为云平台架构，而且为了应对互联网业务形态下突发性业务对资源的弹性需求，蚂蚁也在同一阶段将架构直接进化成弹性混合云架构。
第五阶段：云原生
现在蚂蚁已经演进到第五代云原生架构。蚂蚁又是如何在云原生的架构下，把混合云变成金融级的混合云，在基于云原生架构上将混合云变成金融级混合云的发展过程中，有一条主线，是不同阶段蚂蚁对研发的标准和要求，包括：自主、成本、安全、稳定、海量、敏捷，这也是在在线金融的时代，我们对云原生架构的要求。