银行 IT 架构到底要不要云化？

  银行到底是继续采用集中式架构还是全部更换成分布式架构，是继续保持现有传统架构还是改造成基于云计算的全新架构？本文用较长篇幅全方面分析了集中式架构（非云化架构）和分布式架构（云化架构）的特点、优缺点，并提出了转型思路，从技术和管理两个角度给出了转型路径的建议，是一篇经过深思熟虑、有参考价值的深度文章。

  【作者】雨辰，目前就职于某银行，具有十余年工作经验，有着多年股份制银行、城商行、农商行开发、运维的经验，主持或参与过银行新核心系统、大数据平台等重要信息系统的建设。

  IT 架构作为企业架构的基础，支撑着上层业务架构的建设与发展，进而促进顶层愿景和战略的顺利实施。在企业信息化建设加快速度进行发展的今天，信息系统规模慢慢的变大，复杂程度慢慢的升高，IT 架构技术支撑能力的重要性愈加凸显。近年来，随着金融理财产品和服务模式的持续变革，以及银行业转型发展的深入推进，促使人们不断思考银行IT 架构面临的挑战和影响。

  各大型国有商业银行经过十多年的发展，都已经实现了数据集中，而且，随着客户服务的持续不断的发展和提升，各家商业银行核心业务系统的账户量和交易量都已经逐渐达到了一定规模，系统的解决能力和性能以及可用性、可靠性、数据一致性、业务连续性等要求极高。在这样的一个过程中，集中式架构发挥了及其重要的作用，各家银行的核心系统基本都构建在集中式架构之上，尤其以大型主机架构为代表。集中式架构下，一般都会采用纵向扩展的方式即通过增加单机的资源配置来提升系统的解决能力。通过硬件设备和基础软件的集群机制来提升系统的可用性。当前，各商业银行目前仍以采用大型或小型主机为主的方式来构建自己的IT业务系统。

  与此同时，以蚂蚁金服、腾讯等为代表的互联网公司则走出一条完全不同的技术路线 开放平台、开源软件构建了云计算平台。在此基础上建立了新的分布式联机交易处理架构，能处理海量并发支付交易。支付宝“双十一”秒杀促销活动和腾讯微信春节“摇一摇，抢红包”活动均创造了单位时间并发交易量远超各大国有商业银行的单位时间交易量峰值的奇迹。随着网络金融的迅猛发展，互联网分布式架构得到不断应用、优化和完善，技术逐步成熟，并体现出与主机集中式架构相比在运行风险控制、可扩展性、敏捷开发、灰度发布和总拥有成本等方面的优势。分布式架构以X86和云计算为基础、以数据切分（Sharding）、读写分离为特征，采用横向扩展的方式，通过增加服务器的数量，提升系统的解决能力，每个节点都是一个可独立运行的单元，失效时也不会影响应用整体的可用性。另外，系统能分散到多个节点运行，降低了对单节点的解决能力和可靠性要求，给使用X86服务器替代高性能的主机和小型机服务器创造了条件，可大幅度的降低基础设施的投入成本。

  同时银行自身也面临着来自业务模式和业务量的巨大变化，一是随着移动网络、线上支付、电子商务的加快速度进行发展，金融服务的渠道和场景更丰富，服务模式和体验更加新颖，需要IT系统在支撑多渠道服务协同、信息共享联动、提高服务个性化智能化等方面发挥更大作用。二是随着各行各业互联网化和现实世界数据化趋势的不断演进，人类社会已进入了数据大爆炸时代，银行需充分的发挥数据价值，助推客户营销、产品设计、风险防控和经营管理转型，这就要求IT系统在数据存储、分析挖掘、数据服务等方面给予有效支撑。三是随义务处理线上化和自助化的绝对数量和占比持续提升，信息系统对于银行服务的基础支撑作用日趋关键，要求IT架构在安全稳定运行、业务承载能力等方面提供更有力的保障。这些都对于IT架构提出了新的挑战和要求。

  那现在问题来了，银行到底是继续采用集中式架构还是全部更换成分布式架构，是继续保持现有传统架构还是改造成基于云计算的全新架构？本文将从以下几个方面做论述。

  传统银行走的是集中式交易处理道路，大多数银行的核心系统采用了集群数据库架构；传统银行的应用架构围绕交易处理为核心的模式，将外围产品与核心系统来进行松耦合设计，围绕传统金融的原子事件的模式组织交易。银行核心系统要严格保证每一个原子交易事务处理的一致性原则，要求具备ACID的特性：A(Atomicity)——原子性，C(Consistency)——一致性，I(Isolation)——隔离性，D(Durability)——持久性。Automicity-要求一个事务中所有操作具有原子性，所有操作要么全部完成，要么全部未完成；Consistency-保证事务在开始和结束时数据库应该在同一状态；Isolation-保证事务间的逻辑隔离，事务因此会单独进行数据库操作,多个事务之间不会相互影响；Durability-要求事务一旦完成操作，就不能撤销了。银行系统由于需要出示社会民生等不可或缺的基本金融服务，因此其对于资金账户安全性及交易一致性的要求要远超网络公司，所以银行的核心IT能力一定要选择一致性和可用性，向客户提供金融服务，如果没办法保证一致性和可用性，那整个核心金融服务将不堪设想。基于这样的设计原则，大多数银行的核心系统采用了单站点集群数据库架构（single site clustering database）。这种架构在传统的关系型数据库上将数据逻辑集中，通过紧耦合的数据提供整合的单一逻辑形象，支持跨多个业务线的紧耦合的大联机交易量的处理，能确保信息的实时的单一真实性，无需通过应用层跨系统的集成开销来保证数据和交易的一致性。

  业界对于分布式架构尚未形成统一的定义，但基本包含“基于分布式架构的系统是一组相互独立但并行协同工作的计算机集合；对系统的用户来说，系统就象一台计算机一样”这两层意思。从硬件角度，每台机器都是自治的、独立的；从软件角度，用户感受是整体的、一致的。据此，分布式架构应具备以下特征：一是物理部署分布式，即用多台计算机来共同承载业务；二是处理过程分布式，系统各环节各司其职、并行处理，通过特定机制有效协同关联；三是数据存储分布式，将数据分散存储，但不影响数据运算结果的完整性和一致性。综合上述特点，分布式架构设计的核心理念是“并行拆分与横向扩展”，即按照一定维度将系统进行拆分，系统各部分松耦合并行运行，并建立起较为完善的横向扩展与容错恢复机制。

  分布式系统是个由多个互相连接的处理资源组成的计算机系统，它们在总系统的控制下协同执行同一个任务，最少依赖于集中的程序、数据或硬件。这些资源可以是地理上相邻的，也可以是在地理上分散的。分布式系统隐含的共同特征是：场地分布、数据分布、硬件平台多样化、操作系统多样化、应用平台多样化。

  相比而言，网络公司由于面对数亿级别用户、数百亿级别的浏览量、PB级的数据量，所以可伸缩性是至关重要的。网络公司放弃了ACID，转而偏向BASE：基本可用（Basically Available）、软状态（Soft state）、最终一致（Eventually consistent）。依照理论计算科学著名的布鲁尔CAP定理，一个分布式计算系统一致性（Consistency)、 可用性（Availability）、分隔容忍（Partition tolerance）三项中最多只能满足两项。对于互联网分布式系统而言，网络分区是既定的，只有在放松对一致性的要求或放松对可用性的要求做出选择；网络公司都选择了可用性，而放松了对一致性的要求。互联网公司的应用架构为提供高伸缩性、高变化的服务，普遍采用开源、横向扩展的分布式计算模式。在无共享分布式架构下每一个节点都是独立、自给的，而且总系统中没有单点竞争，具有灵活的可伸缩性。

  目前主流的网络公司如google、yahoo、淘宝等在分布式框架下的设计原则上都有高度一致性：首先做到“能分则分”，把问题分解成易于处理的模块，如果不切分就无法扩展规模，比如电商的用户数据、商品数据、购买数据不断分摊到更多的主机上去处理；第二做到“能异步则异步”，用异步原则来解决伸缩性、响应延迟等问题；第三做到“能自动则自动“，让更多的手工调整变成自动调整，借助了机器学习的方式来完成；第四做到“记住所有失败”，互联网应用没办法避免错误，但是应该记录分析所有错误来不断的提高应用的体验。

  集中式架构系统底层一般都会采用成熟的商业基础软件构建，这种架构的优点是成熟稳定，可用性、可靠性好，银行的技术人员可专注于业务功能开发，无需过多关注底层技术的实现。

  （1）可靠性更高。由于集中式架构的软硬件历经了三十多年的发展，拥有了不断成熟的技术，完善的商业支持体系，相比新兴的分布式架构更具成熟稳定和可用性。同时由于集中式采用服务器数量比分散式更少，能够大大减少硬件的故障点和概率，从而能够提升系统的可靠性和稳定能力，减少硬件维护的工作量，降低系统管理的繁琐程度。目前某大型商业银行主机系统日均承载了近4亿笔交易，峰值达到每秒1万多笔，并继续保持着迅速增加的态势，在监督管理的机构要求日益加强的前提下，IBM的大型机表现出了高度的系统可靠性。

  （2）交易和事务的强一致性。银行集中式架构能够保证交易和事务的强一致性，不同于社交信息处理、互联网信息处理、电商交易处理等可以容忍最终的事务完整性而不追求实时的事务完整性。

  （3）业务连续性更有保障。对银行系统的灾难备份，集中式结构下，可以在一定程度上完成灾备的方式，相对较多。分散式结构下，要建立灾难备份系统，难度相对较大。由于设备数量多、地点可能分散、平台不一定一致，对灾备技术的选择比较受限制，可选方案相对较少。之前某银行采用IBM 大型主机GDPS 双活解决方案结合应用优化，成功实现了跨数据中心全球核心业务的分钟级切换运营。该双活方案是在两个数据中心之间同时运行着同样的应用并拥有同样的数据，在两中心之间可以智能地调度金融交易，当任何一个站点的系统在计划内或计划外停止运行时，其金融交易均可在分钟级内全部切换至另外一个中心对外提供服务。

  （4）开发和运维的复杂度较低。某银行在全国数据大集中后，核心业务系统交易成功率和业务连续性得到了逐步提升，产品创新与推广更高效，业务量年均增长率近30%，至2016年底，日均交易量在2.6亿笔左右，峰值交易量突破3.2亿笔/日。自集中以来，虽然业务产品和业务量均大幅度增长，但底层技术架构基本保持不变，运维更为集中统一，有力地保障了业务加快速度进行发展和生产的平稳运行。

  （5）安全性更高。同时由于IBM 主机由于其专用和封闭的特点，系统各模块之间的数据通讯传输不需要从网络、操作系统、数据库系统和应用多层面采取安全加强固定措施，包括链路和数据加密、身份识别、访问控制、数字签名、入侵检测、系统加固、审计跟踪等等，提高系统安全性。实际上，即使采用主机集中式架构，系统本身在某些特定的程度上更为安全。

  （6）硬件系统扩容简单。集中式结构下，除了能采用横向方式进行扩充外，由于单台主机具备较好的扩充能力，因此能够使用纵向方式来进行处理能力的扩充。纵向扩充方式，仅涉及硬件配件的增加，数据库软件和应用软件不需调整，实现起来相对容易。

  （7）初期采购成本和运行成本相对要低。机房建设成本，采用分布方式进行系统建设，一般需要的主机数量从数台到数十台不等。这些主机，都需要基本的机房占地（包括主机自身面积和每台四周一米左右的维护空间）、承重设计、电力供应、制冷需求。累计到一起之后，通常对机房的基本建设提出很大的需求。尤其对于一些保密性要求较高的中心机房，机房建设成本往往不是以平面面积进行衡量，而是以立方面积进行计量的。这种情况下，每增加一台主机设备，将导致机房基本构建成本的大幅度上升。而采用集中方式进行系统建设，所需要的主机和存储设备大幅度减少，相应对占地面积、承重设计、电力供应、制冷设备等基本建设方面的要求都大大降低，从减少了机房建设成本。运行成本方面集中式架构的运行成本较低。由于采用较少的设备，在机房个数、机房空间、电源功率、机房制冷、保修费用等方面，集中式都比分散式相对节约。

  （8）共用资源的使用率更有效。分布式架构需要对每台主机都配置本地磁带机、光驱、显卡、显示器等设备。而集中模式则可以根据需要对每台主机只配置一套这类设备。如果在每个分区都安装公共的外围设备，如磁带机、磁带库、光纤存储设备或高性能通讯卡等，是最简单容易的办法，也是最浪费的方式。而集中式架构，可以做到在每个分区需要上述设备时，动态划分给它，当分区不需要时，可以从此分区拿掉，划分到其它需要的分区上。这避免了每个分区都实际配备外设造成的浪费，提高了公用设备的整体利用率。因此，集中模式对系统资源的利用更加有效。

  （1）风险度集中。虽然产品比较成熟稳定，但一旦出现软件或者逻辑上的极端异常，也有可能导致整个集群不可用，从而引发全局性停业。

  （2）性能容量存在上限。虽然对于目前的银行业集中式架构仍可以满足性能业务需要，但是由于我国人口基数大，随着经济的快速发展，业务量在全球处于领先，同时伴随以搜索引擎、社交网络、电子商务等为代表的互联网时代来临，数据量以每年50%以上的速度快速增长，对信息系统处理能力带来了空前的挑战。集中式架构容易出现性能容量瓶颈。而且许多新的问题、产品缺陷将有可能首先在我国触发。

  （3）成本高昂。集中式架构对基础软硬件产品的可靠性、可用性依赖度高，这些技术产品基本被极少数公司所垄断，缺乏有力的竞争者，IT成本居高不下。

  分布式架构按照一定的维度将系统进行拆分，通过一定的负载均衡机制，将业务分摊到多个节点上处理。这种架构的优点是能够使用更开放的架构，各节点松耦合，对底层产品的可靠性、可用性依赖降低，可以基于廉价的硬件和开源软件构建，受单一厂商的制约较少，可以引入多家厂商竞争，成本更为低廉，可用性、可扩展性更好。尤其是随着应用规模的扩大，边际成本将更低。

  （1）系统扩展能力较强。可基于通用硬件扩展计算和存储能力来提升系统解决能力，满足业务不断增长的需求；通常，一个企业会买一台大型主机来完成所有的工作。而当公司繁荣扩充、工作量就会增大，当其增大到某一程度时，这个主机就不能再胜任了。仅有的解决办法是要么用更大型的机器（如果有的话）代替现有的大型主机，要么再增加一台大型主机。这两种作法都会引起公司运转混乱。相比较之下，如果采用分布式系统，仅给系统增加一些处理机就可能解决这个问题，而且这也允许系统在需求增长的时候逐渐进行扩充。

  （2）系统成本优势明显。分布式系统基于相对廉价的通用计算和存储设备构建，获取相同处理能力的成本低于传统架构。随着微处理机技术的发展，现在人们只需花几百美元就能买到一个CPU芯片，这个芯片每秒钟执行的指令比80年代最大的大型机的处理机每秒钟所执行的指令还多。如果你愿意付出两倍的价钱，将得到同样的CPU，但它却以更高的时钟速率运行。因此，最节约成本的办法通常是在一个系统中使用集中在一起的大量的廉价CPU。所以，倾向于分布式系统的主要原因是它可以潜在地得到比单个的大型集中式系统好得多的性能价格比。

  （3）系统运行可靠性较好。将系统拆分后并行运行在多台相同的设备上，即使单一设备出现故障，整个系统仍可正常运转或仅局部受损；同集中式系统相比较，分布式系统的另一个潜在的优势在于它的高可靠性。通过把工作负载分散到众多的机器上，单个芯片故障最多只会使一台机器停机，而其它机器不会受任何影响。理想条件下，某一时刻如果有5%的计算机出现故障，系统将仍能继续工作，只不过损失5%的性能。

  （4）系统运行效率较高。在对系统各环节合理拆分的基础上，通过并行处理进一步突破传统串行处理存在的效率瓶颈。

  （5）信息共享的方式更为灵活。从长远的角度来看，主要的驱动力将是大量个人计算机的存在和人们共同工作与信息共享的需要，这种信息共享必需是以一种方便的形式进行的，而不受地理或人员、数据，机器的物理分布的影响。

  （6）使用更为灵活。分散式结构中，所有主机的功能单一，若需要变换功能，需要对系统进行较大调整。集中模式下，各分区的功能可以根据需要进行调整，如果将来有业务扩充或者功能增加时，实现起来比较容易。相比而言，集中模式的灵活性更强。

  （7）能够为业务产品创新、降低功能耦合程度等方面的提供更多的支撑。分布式架构的灵活可扩展、并行高效率处理等优势，在业务促销、复杂产品估值、实时风险防控等方面发挥价值。

  （1）数据和事务一致性较差。在对系统进行拆分后，如何协调各部分之间的并行处理，确保最终处理结果的一致性，分布式系统由于其数据分开存放，不同功能并行处理，为了确保系统整体可靠性，往往采用“数据最终一致性”的原则进行设计，需在产品功能设计层面同步予以考虑。

  （2）增加了开发和运维的复杂度。根据CAP理论，在可用性、分区性与一致性三者之间，同时只能满足两个，如果要满足可用性（A）、分区性（P），就需要牺牲一致性（C），业界的一般做法主要是根据业务特点，通过较为复杂的应用设计，放弃实时一致性、保障最终一致性来解决该问题，分布式架构增加了应用设计和研发的复杂度。此外，随着节点数的增加和分布部署，对运维管理、异常处置也提出了更高的要求。

  （3）支持软件的成熟度和稳定性较低。什么样的操作系统、程序设计语言和应用适合这一系统呢？用户对分布式系统中分布式处理又应该了解多少呢？系统应当做多少而用户又应当做多少呢？就目前的最新技术发展水平，我们在设计、实现及使用分布式系统上都没有太多的经验。

  （4）跨网络访问过程中可能存在的信息丢失和通讯延迟。由于它会损失信息，所以就需要专门的软件进行恢复。同时，网络还会产生过载。当网络负载趋于饱和时，必须对它进行改造替换或加入另外一个网络扩容。在这两种情况下，一个或多个建筑中的某些部分必须花费很高的费用进行重新布线，或者更换网络接口板（例如用光纤）。一旦系统依赖于网络，那么网络的信息丢失或饱和将会抵消我们通过建立分布式系统所获得的大部分优势。

  （5）安全性偏低。上面我们作为优点来描述的数据易于共享性也是具有两面性的。如果人们能够很方便地存取整个系统中的数据，那么他们同样也能很方便地存取与他们无关的数据。换句话说，我们经常要考虑系统的安全性问题。通常，对必须绝对保密的数据，使用一个专用的、不与其它任何机器相连的孤立的个人计算机进行存储的方法更可取。而且这个计算机被保存在一个上锁的十分安全的房间中，与这台计算相配套的所有软盘都存放在这个房间中的一个保险箱中。

  （6）系统整体的可靠性方面技术复杂。如何确保在单个节点异常情况下系统正确切换与恢复，确保系统整体可靠性等等，这都需要在系统设计与实现层面制定有针对性的解决方案。

  （7）对于研发和运维的人员要求高。分布式架构对于架构设计、研发、运维等人员的知识结构有着新的要求，需要有相配套的人员知识结构。

  （8）分布式架构需要科技和业务部门深度耦合。分布式架构下系统各组成部分的相互关系及作用模式发生了较大变化。除了在系统架构设计和研发等方面的变革，更由于系统部署模式、故障恢复机制的变化，须在运维监控、应急处理等方面进行配套，需要研发部门与运维部门之间的紧密协同，密切配合，将科技和业务人员深度耦合在一起。

  （9）部分场景下成本不低。对于功能相对简单、服务需求相对稳定的业务，使用分布式架构反而将显著增加设计与实施成本。

  综上所述，分布式和集中式两种模式，各有利弊。笔者认为在构建银行系统的过程中需兼顾集中式和分布式两种IT架构。一方面，通过集中式架构保证银行系统的资金账户实时性、安全性及交易一致性；而另一方面，通过分布式架构向数量众多、分布广泛小微客户提供高扩展性、多变化的应用服务。因此笔者建议在构建银行IT系统过程中，对于涉及银行核心交易的IT应用，应该严格遵守一致性要点；而对于面向互联网的非核心应用，可以用分布式架构来支撑其运行。向集中式和分布式架构有机融合的架构体系进行转型。

  （1）是主机平台上。深入研究业务特点和应用架构，将可以下移的应用和数据迁移到开放平台。进一步推广主机开放融合架构，扩大查询交易迁移范围。将交易路由层分离出来，采用独立的负载均衡设备实现交易的统一接入和负载均衡调度，减少了对主机的依赖，降低了资源消耗。采用读写分离设计，构建主机开放融合架构，将查询类交易的应用逻辑处理下移到国产X86服务器上，将明细数据下移到开放平台上，基于Hadoop架构实现明细业务查询。将可以下移的业务系统整体下移到开放平台，减少主机资源使用。

  （2）是开放平台上。通过对集群技术、虚拟化技术、分布式数据库、分布式存储等技术的深入应用，采用Linux替代UNIX，用X86服务器替代小型机，引入集群数据库和MPP数据库，探索存储虚拟化应用，构建更加开放的分布式架构，结合业务特点对应用进行精心设计，从应用接入层、应用服务层到数据服务层和存储服务层建立不同的分布式架构，以同城和异地灾备中心建设为契机，将业务合理分布到多个中心，构建多活架构，进一步提升系统的健壮性和应急处置能力。

  （3）是运维管理上。分布式架构降低了单个节点对基础软硬件的可靠性、可用性依赖，通过架构来保障系统的整体可用性。但随着分布式架构、虚拟化等技术的实施，设备与系统数量快速增长，一个系统涉及的节点众多，为运维管理带来了较大的挑战。因此需要加强开发与运维的融合，持续优化完善现有的监管控平台，加强流程平台与自动化平台的融合，进一步提升端到端的运维管理标准化、自动化水平，提升问题发现、定位、处置能力。降低分布式架构所带来的运维压力。

  采用互联网分布式架构替代传统的主机集中式架构开发构建银行核心业务系统在技术上是可行的，并且能解决银行核心业务系统面临的困难和挑战，大幅度的降低了核心系统的总拥有成本，提高自主可控能力。但替代是一次技术路线的重大转移，国有商业银行实施技术转型过程中应该进行充分地学习研究、分析论证和测试验证，周密规划，稳步推进。

  （一）从技术路线、对功能相对稳定、与客户资金安全紧密相关、且无明显性能容量压力的业务，一段时期内仍以传统集中式架构实现。对于业务新颖性强、创新速度较快、交易并发量大，或者对信息系统部署有特殊监管要求的境外业务，则逐步以开放平台分布式架构实现。

  2、对于原有部署在主机集中式系统的存量非核心业务，可以考虑逐步迁移至开放平台分布式架构系统。随着交易种类和交易的迅速增加，应充分发挥主机系统和开放平台系统的不同优势，可以将客户增值服务信息、历史明细、现金管理、会计要素管理、小额支付、金融市场、投资理财等相关业务迁移至开放平台。逐步减少主机的负载和压力。

  3、对于原有部署在开放平台并采用传统集中式架构的系统，可以结合业务特点差异有选择性地实施分布式架构改造。对于已有的网上银行、手机银行、银企互联、信贷管理、客户营销管理等系统，可以结合银行自身业务发展需要和业务内在特点，差异化地实施IT架构优化提升。对于线上支付、短消息提醒、产品集中销售等业务量波动较大的内容，应逐步按照分布式架构实施改造；对于柜面业务处理、客户营销管理等业务量相对稳定的内容，则重点基于集中式架构持续优化提升。

  1、提高认识，调整战略。要认识到进行核心业务系统技术替代的重要性和必要性，互联网金融技术“狼”真的来了，面对新的技术浪潮，要采取积极的应对措施，实施IT战略转型。银行需要从业务视角出发重新思考IT 和业务的关系，提高业务系统的敏捷性，实现业务和IT 的融合，在控制风险的同时，尽可能“多、快、好、省”地为业务创造价值。

  2、虚心学习，奋起直追。面对互联网金融技术，商业银行经历了从“不屑一顾”到“不以为然”、从“警醒震惊”到现在“奋起直追”的过程。实际上，在云计算、大数据、移动计算和社交媒体等技术应用开发方面，商业银行已经落伍于互联网企业了，现在是放下商业银行采用主机“高、大、上”身段的时候了。商业银行应该虚心向互联网公司学习云计算和分布式处理技术，结合银行业务系统特点，采用云计算和分布式架构改造其核心业务系统。

  3、排除困难，大力推进。从技术上说，实施替代的难点在于同现有技术体系的融合，是全盘替代还是部分替代，替代项目的实施管理难度也很大。从管理上说，要充分认识来自方方面面的阻力，既有技术人员和业务人员因循守旧和技术偏好造成的抵触情绪，还有可能来自厂商及其代言人出于商业利益的阻挠、恐吓和游说。因此，替代工作需要获得上级主管部门、银行高层领导的大力支持，方能顺利实施。

  4、大胆设想，小心求证。既要看到云计算和分布式技术的巨大潜力与优势，也要重视可能存在的弱点和不足，特别是要充分评估对业务和客户体验造成的影响。认真对银行核心业务进行梳理和分析，识别银行业务相对互联网信息处理在交易一致性、安全性等方面的更高要求。对各种分布式处理技术进行充分的分析评价和测试验证，做好技术选型和架构设计。

  5、搞好试点，逐步推广。同引进各种新技术、新产品的过程一样，为了有效控制引入新技术的风险，国有商业银行替代核心系统也应经历先试点、后推广的过程。在试点过程中完善新平台技术架构，制订实施工艺和规范，形成开发和运行工具。特别要对云计算和分布式处理方面的开源软件进行学习、消化和吸收，组建一支技术过硬的互联网分布式架构开发队伍，为实现技术路线的全面转型做好准备。

  综上所述，分布式架构具有更好的可扩展性，对基础软硬件的可靠性、可用性依赖度更低，能够使用更加开放、廉价的产品构建。但我们也要看到其给应用设计、研发、运维管理所带来的挑战。总之，技术是为业务服务的，无论是集中式架构还是分布式架构，各有优缺点，我们需要根据不同的应用场景，选择合适的技术架构。此外，银行与互联网企业在信息系统建设上，无论是业务类型、风险容忍度、监管要求上，还是技术架构和文化机制上，有着较大的差异。确保客户资金安全和生产运行稳定，是银行信息化建设的首要原则，在分布式架构应用当中，要结合技术可控、风险可控、成本可控综合考量，要本着实事求是、稳妥前行的原则逐步推进。