来源：蓝海云

实现从传统商用技术和架构向开放、开源、分布式系统架构转型，是银行“十三五”期间信息科技工作的主要目标和重要任务。架构和技术转型，能够有效支持业务创新，加大竞争力。

架构转型的意义

1. 分布式系统架构是技术发展的趋势

随着互联网和云计算服务的快速发展，作为其主要技术的分布式计算、存储和应用技术正在成为当今信息科技的主流。分布式系统架构不仅具有可扩展性强、处理效率高、容错能力强等特点，更为重要的是，它还是大数据、机器学习、人工智能、区块链的支撑技术。目前，国内外金融机构都在积极、审慎地开展私有云建设，研究并尝试开源、分布式技术和应用。

2. 架构转型是银行生存和发展的迫切要求

第一，生态化、场景化的金融服务，以及数字化、智能化等技术，已经对银行的支付、征信、风险技术、理财、客户获取等核心领域产生极大冲击，互联网技术创造了平台经济、共享经济，也推动着金融服务模式的创新，银行不加快技术转型就会被未来淘汰。第二，以开放、合作、分享的理念和态度参与到互联网金融生态中必须要有开放的技术体系和架构与合作者联接和交换，现有的闭源架构在一定程度上限制了银行业务的合作范围、扩展性和效率。第三，开源、开放的分布式技术成本更低、效率更高、用户体验更好、开发和测试方法更为敏捷。

3. 架构转型是适应我国金融业安全可控趋势的迫切要求

以X86、开源为特征的技术体系，有利于我国信息产业企业和银行业掌握技术，从而改变我国银行业长期以来基础软硬件等核心技术完全依赖国外厂商的状况，适应国家网络空间安全战略要求。

中信银行的云计算转型经验及在实践中所面临的困难和挑战分享值得借鉴和思考。

架构转型目标和实施步骤

1.架构转型目标及实施策略

中信银行高管层对互联网、云计算、大数据有着敏锐洞见。自2013年开始布局云计算、大数据、分布式数据库等互联网新技术应用研究，投入资源，组建专职团队，规划中信银行私有云架构，开展相关技术的研发和落地实施工作。以开源、开放的分布式架构为转型的重要推手，扎实推进银行IT架构转型各项工作。在前期研究和试点基础上，2016年初，全行“十三五”信息科技发展规划进一步明确：完成向开放、分布式架构转型，建成组件化、服务化、移动化的应用架构，完成核心系统的下移。搭建支持在线、离线和实时数据服务的混合数据架构，提供精准化管理和智能化服务。打造弹性扩展、快速部署、高可用、低成本的“中信云”，建设随需应变的基础设施。

架构转型是一个复杂的过程，需要采取循序渐进的实施策略：

一坚持架构规划先行。确定分布式架构为架构转型的最终目标，建立专职实施团队，制定架构转型原则，明确架构转型实施路径。

二坚持“研发应用相结合”。以新技术启发创新型应用，以业务需求指引技术研发，边研发、边释放，成熟一批、上线一批，逐步推进新技术落地。

三坚持“先管理后交易系统、先外围后核心系统”。以分布式、大数据应对海量高并发的计算需求，从传统技术和云计算技术相结合的混合架构逐步过渡到开源开放的分布式架构，以积极稳妥的步骤推动IT架构转型。

2.架构转型实施步骤和成效

一是制定架构转型规划。2013年开始，中信银行组织人员研究互联网企业的最佳实践，并根据其自身的业务发展实际需求，研究制定中信云平台的整体架构规划。新一代的技术架构平台以硬件资源池化、基础软件开源化、软硬件资源灵活调度和弹性供给为基本特征，采用大数据处理、分布式计算、实时智能分析等最新的云计算技术，构建软件基础平台。按照“搭平台、建队伍、上应用”的执行步骤，踏上转型之路。

二是从大数据平台建设和应用入手。2014年，搭建了基于开源Hadoop技术的企业级大数据平台，引入开源技术组件10余项，完成大数据生态的整体部署。经过3年建设，平台已经实现了行内外数据、结构化与非结构化数据的采集、存储与分析，搭建了在线精确查询、离线批量加工、实时事件处理、内容管理、大数据挖掘等5个平台，支撑了交易风险控制、对客精准营销、用户行为分析、智能投顾和人工智能等创新型应用。让交易数据在前中后台之间“动起来”，让沉睡的历史数据在分析系统中“活起来”，消除技术壁垒和数据孤岛，充分发挥数据资产的价值。

三是分步骤推进“中信云”基础设施建设。建设了云数据中心，实现了中信生产和测试“两朵云”的建设目标，开展了容器项目的预研。

在生产云中，按照“云数据中心”理念，重新规划基础架构，进行机房布局、高密机柜选择和大容量设备选型，大力发展平台化运维、自动化运维、智能化运维，稳步推行开源产品，加大新型运维团队的培养，设计了基于云计算的双活中心、灾备中心架构。2016年11月，全行管理类信息系统100%接入云平台，平台包含142台X86服务器，节约了1445台物理机，120个机柜空间。

在测试云中，包括170台X86服务器，运行了1632个虚拟机，节约了1462台物理机，110个机柜空间。完成了测试环境的100%纳管，同时向分行开放了开发测试资源，完成了配套的规范、流程建设，提供了30多种涵盖中间件、数据库部署需求的云服务。

“两朵云”在试点阶段就取得了显著成效。“生产云”累计节约6500万元的服务器采购成本，每年节省1440万元的机柜租赁成本。同时，总行云平台向分行提供互联网特色应用云服务，满足了分行迫切的互联网出口需求。“测试云”累计节约6200万元的服务器采购成本，每年节省1320万元的机柜租赁成本。测试环境虚拟机部署效率提升50%，环境准备时间缩短一半。

2016年，还开展了容器项目预研，基于DevOps的理念，进行了容器云的系统规划、场景设计、产品选型和POC测试。实践过程中，坚持从实际业务需求、运维需求出发，将实际需求与容器云最佳实践相结合，在微服务、应用容器化改造、弹性扩展、灰度发布等方面，进行了深度研究和实践。

中信银行云平台的实施，实现了强健稳定、弹性伸缩、开源开放的基础架构平台，为中信银行云平台战略的实现打下了坚实基础，为后续的PaaS平台建设提供了坚实的技术支撑。后续还将进行SDN对接、存储自动化管理、PaaS平台对接等工作。

3.大胆尝试分布式数据库研发和试点

在实现架构转型过程中，必须实现数据持久化层的分布式，但这恰恰是分布式架构中技术难度最大、最为关键的部分，在银行同业没有先例可以借鉴，因此决定自主研发分布式数据库。经过3年时间，分布式数据库已经具备事务实时一致性控制、集群高可用切换、联机在线重分布和数据库备份恢复等关键能力。目前正在进行二期项目研发，届时将具备更完善的分布式事务控制能力、日终批处理能力、在线扩容能力、问题诊断能力以及更高的并发处理能力。中信银行的分布式数据库已经在冠字号系统、中信银行新门户和金融同业合作平台试点成功，目前运行平稳。

2020年完成两大“核心”群的迁移

2017~2020年，是中信银行架构转型的关键实施阶段。一是计划用3年半时间将信用卡中心以及其他外围系统全部迁移到分布式技术架构。二是计划在“十三五”期末，完成核心业务系统向基于X86平台的分布式架构的迁移。三是围绕上述两项重大任务，搭建PaaS平台。以两大“核心”迁移项目投产为标志，推动架构转型目标达成。

转型难点及对策

尽管分布式系统架构成为趋势，但是银行业要实施架构转型，在思想观念重塑、团队能力建设、技术难点攻关等方面尚存在巨大挑战和困难，必须采取强有力的措施攻坚克难。

难点一：思想观念转型难度大

长期以来，银行信息科技团队将确保客户和银行的资金安全作为恪守铁律。使用最成熟、稳定的技术，保证系统交易的实时一致性，是银行信息技术部门的基本工作原则。因此，银行架构无一例外地选择使用以IOE为代表的成熟、稳定、具备良好技术支持保障体系的“经典”商用软件和体系架构，并培养了大批熟悉应用相关技术的优秀技术人员。分布式架构与传统架构相比，在架构、设计、开发、运维、管理上需要有不同的思维和技术能力，这对我行现有技术团队的思想观念和思维模式造成巨大冲击，需要有一个“脱胎换骨”的转变过程。

对策：一是虚心向掌握新技术的互联网公司学习，开展技术交流与合作。二是建立云计算、金融IT产品创新实验室专职研发团队，通过小团队的研究、创新、试点和培训，以点带面。三是应用新技术解决业务痛点，让技术团队和业务部门真切感受到新技术的好处，理解和支持技术转型。第四，也是最为重要的一点，高管层高度重视和支持架构转型工作，给信息技术部门留出一定的转型时间、资金，以及试点和试错空间。

难点二：缺乏掌握新技术的人才

开源技术同样需要技术支持，但是与传统技术发展路径不同，云计算技术专家大多集中在互联网公司。由于开源技术的变化很快，研究这些技术的大多为创新型公司，一般规模小、不稳定，难以提供持续、稳定的技术支持，并且缺乏对银行应用特点的理解和实践经验。银行必须培养和拥有一批既掌握新技术又有丰富银行应用经验的技术人才，而银行现有的招聘、薪酬和激励机制，不足以吸引此类紧缺人才。

对策：一是高度重视并积极尝试建立吸引和留住信息科技人才的机制，建立信息科技专业技术岗位序列，让专家型技术人员有良好的发展空间。二是通过制定转型目标、针对性的培训、项目实践、评估阶段效果等措施，有计划、有步骤地循序渐进，目前已取得了一定成效。

三是积极开展与国内有实力供应商的合作，改变单纯的甲乙方关系，联合开展技术难点的研发和攻关，共同培育市场化的服务支持环境。

难点三：数据持久化层的技术难点

在银行IT架构向分布式架构转型过程中，最大的技术难点在于“数据持久化层”的分布式。相比之下，应用逻辑层和接入层的分布式架构已经很成熟，在银行内已经得到广泛应用。之所以说是难点，是因为数据是有状态的，特别是银行核心系统保留的账务数据，在交易过程中会被不停地更改，这部分数据一旦被分布到多处存储，就会造成更改信息的不一致、更改信息不可见、读取信息不准确等一系列问题，也就是技术上经常说的分布式事务下数据一致性、隔离性、原子性和持久性的问题。

对策：为解决上述技术难题，在分布式数据库中研发了“全局事务管理器”和“分布式隔离级别”。前者很好地解决了分布式事务一致性和隔离性问题，但仍然没有突破CAP理论，处理性能会受到影响。为解决性能问题，又研发了“分布式RR”和“分布式CR”两个隔离级别，对明确不会产生分布式事务、不受分布式事务影响的请求，可以指定“分布式CR”隔离级别，从而确保分布式数据库的整体处理性能。

银行业是信息化程度较高的行业，信息化队伍及知识储备相对充分，因此短短几年，各银行业金融机构在分布式架构领域已有很多收获。但总体而言，由于CAP原理的约束，银行对于分布式架构的应用仍然落后于互联网行业。银行分布式架构特点是混合模式，在应用层广泛采用分布式实现，但在数据库层，还普遍采用集中的数据库模式。

实施分布式架构的关键点

银行实施分布式架构，需要从信息化建设理念、系统设计方式、IT运维模式、灾备中心机制、人才队伍建设和产业生态建设等6个方面进行通盘考虑。

从信息化建设理念上看，分布式架构需要全新的“弹性”架构的思维。传统架构是按照“峰值性能要求”来规划和设计信息化的基础设施和运维能力，采购和部署信息化资源的，所以成本较高，信息化系统的处理能力在一个阶段内是固定的，处理能力的变化非常繁琐而且容易导致风险和事故。分布式架构则不然，是按照“日常性能要求”来规划和设计的，信息化资源可以灵活动态增加，在业务高峰期采用“错峰调剂”和“临时租借”的方式快速响应计算能力要求，所以可以降低IT资源成本，并且满足更高的突发性、大规模并发的业务需求。

从设计方式来看，传统的系统设计方式是各个系统独立运行，系统之间采用应用集成和数据交换的方式实现互连互通。分布式架构则强调组件化和服务化，功能模块按照业务可以采用横切、纵切等方式灵活划分组件和服务，数据则大量采用本地化小数据库的方式实现分布式数据访问，通过轻量级服务和高速的消息机制实现应用和数据的整合。

分布式架构需要使用新的IT运维模式。传统的IT运维强调的是在服务水平约定的基础上实现标准化和流程化。而在分布式架构下，IT资源节点更多（数量上会上升1～2个数量级），节点的增加和减少更加实时和动态，要求更加自动化和智能化的监控维护，在应用代码的设计和开发环节就需要统一考虑监控维护。因此，需要研究和应用DevOps（实现开发、运维一体化的一系列过程、方法和工具的统称）模式，在软件开发、数据中心运营和质量保障（QA）工作之间实现更紧密的沟通、协作与整合。这对我们的很多银行而言是非常巨大的挑战。

分布式架构的灾备实现方式是全新的课题。由于应用的分布式计算框架的“先天”能力，以前一直困扰银行界多年的灾备数据中心的“多活”问题不再是一个难点。反而是以前容易解决的远程数据灾备问题更加复杂了，往往需要至少保留3个或以上副本才能保障数据的可靠性，需要在设计中充分考虑。

分布式架构人才队伍的建设也是一个关键。过去二十多年，无论是合作厂商还是银行自有的科技人员大都是传统架构的技术背景。而市场上现有的分布式架构人才主要聚集在互联网公司和金融科技公司，属于热门人才，人力成本比较高。银行需要考虑倾斜性的人力资源政策，创新科技人才薪酬体系，尽快建立自己的核心技术团队。

分布式架构的实施策略

选择分布式架构，是国家安全可控战略的要求，也是随着互联网发展，商业银行提升自身金融服务能力的需要，各单位应根据自身现实情况，按照“整体规划，分层分类，逐步推进”的策略，走出一条有自身特色的转型之路。

首先，应充分考虑自身业务特点，高度关注分布式架构系统的风险特点，从信息化战略的高度，明确目标，统一思想，制定IT架构蓝图，明确分布式架构整体规划。

其次，在业务场景的确定和应用系统的选择上，需要区分不同的业务种类和应用层次，采取区别的方式。在业务场景层面，电子渠道和其他内外部协作的互联网应用场景，包括大数据征信、大数据营销、大数据风控等业务场景，可以优先考虑应用分布式架构。从应用架构分层来看，对交易和数据的强实时一致性要求不高的环节，如渠道层，数据分析层，内部管理层，可以应用分布式架构。对于核心账户处理，受限于CAP理论的约束，在目前业务流程对数据强实时一致性的要求下，实现完全的分布式处理存在一定困难，可通过优化业务流程，借鉴BASE理论（基本可用、软状态、最终一致性）逐步实现分布式处理。最后，制定稳妥、有效可行的实施路径。