金融行业正在流淌着一股去 IOE，去集中化的 IT 架构转型洪流。我有幸参与到这股洪流中，见证这一重大变革。以下是我对这股洪流的一些思考和想法。

当前主流金融的 IT 架构

众所周知，目前大部分金融机构的 IT 架构还是以“IOE”的 IBM 大小型机，Oracle 数据库，EMC 存储为基础的集中式架构。

这种架构有以下优点：

• 成熟度高

• 可靠性高

• 可用性高

这些产品目前承载着世界上众多金融行业的核心系统，而这些产品的厂家在这个领域有几十年的积累，产品的成熟度，可靠性，可用性可见一斑。

不过这种架构也有三大缺点：

• 第一个就是成本高。硬件，软件，服务都价格不菲。这些费用在金融机构躺着赚钱的时代还是可以接受的，但是在现在以及未来瞬息万变的时代，金融机构的经营形势会越发趋紧，那么这一块 IT 架构支出就会成为金融机构的负担。

• 第二个就是 IOE 的东西都是黑盒，其核心科技就像一个迷。万一再来一个类似“棱镜门”，“华为门”的“IOE 门”，金融 IT 架构的处境可想而知。虽说可能性不大，但是不怕一万就怕万一。所以，自主可控才不会受制于人。

• 第三个就是可扩展性较差。这种架构无法做到快速，无限制的扩展。之前也提到，未来是瞬息万变的时代，消费模式会从工厂生产什么，消费者消费什么的模式转变到消费者海量碎片化需求主导的模式。那么 IT 架构需要能支持随时扩展以便适应业务的快速发展。

新金融的 IT 架构

为了避免集中式架构的三大缺点，以互联网银行为代表的新金融 IT 架构浮出水面。最开始的思路就来源于互联网+：将互联网的架构加上金融架构。这种模式吸收了互联网架构的优势，同时保留了金融行业的高标准要求。

这种 IT 架构基于开放式的平台，采用廉价的 PC 服务器集群，形成分布式的架构，在有高性能，高扩展性，低成本的基础上，同时满足金融架构的高可用，低风险，强管控的要求。

image.png

在新金融的 IT 架构框架下，大量廉价的 PC 服务器集群（以开源的 Linux 系统为主）替代了大小型机，很好的诠释了团结就是力量。正所谓三个臭皮匠顶一个诸葛亮，整合的策略对了，三个臭皮匠的能量就能聚合起来发挥出巨大的能量。同时，将集中式的服务拆分成微服务，部署在大量 PC 服务器上能实现高性能，高扩展性，低成本，高可用的要求。

以 mysql 为代表的开源数据库替代了封闭的 Oracle 数据库。我们不光能使用这些开源数据库，查看源代码，而且我们还能贡献我们的智慧，让它变得更好。虽然单个这类数据库的性能可能没有 Oracle 的好，但是将他们整合起来形成分布式数据库，然后使用分库分表的手段可以达到高性能，高扩展性，低成本，高可用，低风险的要求。

分布式存储技术在某些程度上可以替代 EMC 的存储。它最大的特点就是高可用性，高可扩展性和高数据可靠性。其典型的开源产品有 Google FS，HDFS，CephFS，GlusterFS。

金融场景为什么要考虑使用新架构？

除了上文提到的成本问题，自主可控问题，高可扩展性问题外，我认为还有以下原因促使金融机构要考虑使用新的架构。

• 金融的业务服务范围的扩大，业务趋于互联网化，生活场景化，所以需要有架构可以支撑其短时间内转向和扩展。比如，互联网化的热销理财产品，网络秒杀的场景，银行 App 生活缴费，吃喝玩乐，结账优惠场景会逐渐增多。

• 客户连接的复杂化，除了柜台，电话连接，还会有海量用户随时从各种地方，各种设备的连接。这些连接对内部系统连接数，特别是 Session 连接数和数据库连接数来说是巨大的挑战。金融机构需要新的架构来承载海量的连接，防止系统被打垮。

• 服务的多样化从柜面接客，电话银行转换成柜面，电话，公众号，24*7 的在线智能服务，千人千面服务等。多样化的服务接口需要分布式架构进行独立性能保障，访问隔离等。

分布式架构是否可以满足金融场景的要求？

前面谈了集中式架构的缺点，有人会问分布式架构就没有缺点了吗？似乎分布式系统只能同时满足一致性，可用性，分区容错性三者之二吧？确实没错。

对于金融场景来说，高可用，分区容错性不可或缺，而且一致性也需要得到保证（毕竟谁也不想看到转账到朋友的钱没有到账，结果自己的余额却被扣掉了吧）。

但是，需要注意的是，这种三选二的说法其实是按照集中式架构的模式照搬到分布式架构而言的。试想一下，一台强大的数据库被拆分成了 N 台数据库，这 N 台数据库之间的数据需要时间同步，当异常发生时，可能就产生了数据的不一致性。

那么我们换一个角度思考一下这个问题。我们将原来的数据库拆分成了 N 台数据库之后，每台数据库也只处理原来业务的 1/N，同时其和其他处理（N-1）/N 业务的数据库之间不进行同步，这样是否就可以解决这个一致性的问题了呢？答案是显而易见的。

这时候有同学又要问了，那如何能保证每台数据库只处理原来业务的 1/N？同时数据库的高可用怎么办？

对于第一个问题，支付宝，网商银行给出了答案：使用 LDC（单元化）架构，一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。将业务按照一定维度进行拆分，拆分成 N 份，每份由一个单元的服务和数据库处理即可。

对于第二个问题，我们可以给主数据库配上两个从数据库，同时实现他们之间的强一致性同步。虽说性能上稍微有些下降，但是却能使整个分布式系统满足金融场景的特殊需求。

image.png

此外，从上图也可以看出 LDC 架构另一个好处就是天然自带灰度属性。新发布的功能可以在某些特殊的业务单元中进行灰度验证，降低因为新版本引发的故障的影响范围。

综上所述，分布式架构理论上可以满足金融场景的特殊需求。

阿里的解决方案 - SOFAStack

阿里旗下的支付宝，网商银行的这套 LDC 单元化架构依托于 SOFAStack™（Scalable Open Financial Architecture Stack）。它包含了构建金融级云原生架构所需的各个组件，也是在金融场景里锤炼出来的最佳实践。提供微服务应用开发、部署发布、项目管理、监控运维、容灾高可用等全栈式解决方案，并兼容 Dubbo、Spring Cloud 等微服务运行环境，助力客户各类应用轻松转型分布式架构。

在宏观架构层面，SOFAStack 提供单机房向同城双活、两地三中心、异地多活架构演进路线，使系统容量能在多个数据中心内任意扩展和调度，充分利用服务器资源，提供机房级容灾能力，保证业务连续性。

异地多活单元化架构是“三地五中心”部署模式的技术创新。在该架构解决方案下，可以避免跨机房、跨城市访问的延迟，真正实现异地多活部署，不但消除了传统“两地三中心”架构中的单独冷备中心，并提升了灾备高可用能力，无论在成本还是在伸缩性、高可用方面，都带来了巨大的优势。

image.png

在微服务层面，SOFAStack 包括了一个面向未来架构的微服务平台，支持异构应用融合迁移。

微服务平台通过 SOFA 微服务和 Service Mesh 微服务，提供了既支持 SOFA 框架又支持 Service Mesh 架构的微服务管理和治理能力，解决用户在技术转型期间与未改造的遗留系统相互之间打通和过渡问题，帮助金融机构平稳的从传统的集中式、微服务架构演进到云原生架构。

image.png

在分布式应用组件层面，SOFAStack 还提供了分布式中间件套件以满足传统金融架构的平滑迁移、融合适配，以稳妥应对业务升级变更，并积极应对金融交易系统所面临的服务和数据扩展性、事务一致性、秒级容灾、弹性供给与调度等关键技术挑战。

image.png

在应用生命周期管理层面，SOFAStack 提供了一个多模应用 PaaS 平台，SOFAStack CAFE（Cloud Application Fabric Engine）云应用引擎。它提供应用管理、流程编排、应用部署、集群运维、监控分析、容灾应急等全生命周期管理的 PaaS 平台能力，满足金融场景中经典和云原生架构的运维需求，帮助传统架构平滑过渡、保障金融技术风险 。

image.png

结语 - 架构未来将何去何从？

所谓天下大势，合久必分，分久必合。在我看来，架构也是如此。现在，我们正处在合久必分的洪流中。但是未来，可能是较长之后的未来，未必不会出现分久必合，合久必分的反复。

比如说，未来，我们掌握了自我可控的性价比高的强大核心计算技术；

比如说，量子计算，生物计算，光子计算，超导计算等有了巨大突破；

那么，那时候未必不会出现分久必合的局面。

再远一些的未来，由于数据范围扩大，我们可能不光要计算一个省的数据，更可能需要计算一个国，甚至整个地球的数据；

再远一些的未来，由于数据维度扩大，数据量也会爆炸；

那么，那时候未必不会再次出现合久必分的局面。

让我们拭目以待吧！