对金融机构而言，传统IT建设模式已无法适应互联网金融业务发展需求与竞争压力，转型势在必行，以银行为例，新核心建设项目已经在众多银行启动。以下内容来自社区组织的银行同行线下交流，分享了新核心建设的风险和对策、架构选型分析等，供大家参考。
银行新核心建设中存在哪些具体的风险和问题？针对这些风险和问题有哪些对策？
银行新核心系统建设是一个巨大的系统工程，不仅仅是一个核心系统的建设，往往通过核心系统的更新，带动周边各业务系统的升级和优化，是个巨大的项目群工程。主要有以下风险：
- 领导力不足。由于核心系统项目群建设工程巨大，协调各部门及内外部资源众多，需要具有强有力的领导小组指挥和推动。因此，银行对于核心系统的建设往往是一把手工程， 由行长或者 CIO 亲自挂帅总指挥，推动项目进度。
- 周期过长。核心系统项目群建设是个系统工程，涉及的全行各个业务，同时各个系统也都需要更新对接新的核心系统。因此从产品选型招标、IT 架构规划规划、方案设计、需求评审、组织开发、测试评估、试运行、正式上线、上线运维等等，各个环节，环环相扣，都有很大工作量，消耗人力、物力等资源，很容易延期上线。银行核心系统建设周期往往少则 1 年，多则两三年。
- 项目经理经验和能力不足。 项目经理是核心系统建设项目的灵魂人物（包括甲乙双方的项目经理），由于核心系统建设的艰巨性和重要性，务必选择最合适的人担任项目经理，推进项目有序、可控、健康建设。
- 耽误银行其他业务的发展。银行新核心系统的建设，鉴于其重要性，往往是头号工程，集合了全行最优势的人力资源，信息科技部门的各项资源也重点倾斜向核心系统项目。因此，对于其他项目的关注度和支持力度势必有所下降， 尤其是目前市场日新月异的创新产品推出，快鱼吃慢鱼的时代，一旦落后，则后期很难再追赶了。
银行新核心架构应该如何选择？分布式与集中式？如何评估？
不同的应用架构需求，衍生不同的数据系统架构，这里仅以互联网金融支付宝和传统银行进行对比：
1，分布式与集中式数据库的分野
在业务体系上，支付宝和银行在业务逻辑、监管方式、数据要求上完全不同； 业务决定技术， 这也造成了不同的技术路径。 需要强调的是，尽管两种不同的技术路径，但技术原理却是相同的。分布式和集中式数据库各有优缺点，也就各有不同的适用环境。
2002 年，麻省理工学院 MIT 的教授在数学上证明了 CAP 理论。在分布式计算 （存储） 的架构里， 由于网络引起的时延是必然的 （Partition Network Toleration），因此对于一个操作在数据一致性（C=Consistency）和数据可用性（A=Availability）方面必须取舍一个。许多互联网的业务类型（电商、搜索引擎等等），可以接受最终的数据弱一致性， 因此分布式计算模式加数据可用的高扩展架构成为 Web2.0 公司的平台基础。而对于金融业需要数据实时强一致性的业务，采用关系型商业数据库来满足 ACID（代表 Atomicity 原子性、Consistency 一致性、Isolation 隔离性、Durability 持久性，是实现实时强一致性的基础）也是历史的正确选择。
分布式计算、集中式计算不是谁替代谁，而是各有不同的用点。适合不同的业务场景需求。互联网应用确实将分布式计算带到了新的台阶，但是并没有突破计算机科学的 CAP 基本原理。因此有时候需要牺牲数据一致性换得处理能力的线形可扩展性。 而银行业务需要注重数据的实时强一致性采用集中处理， 在一个统一的唯一数据视图上进行横向和竖向的扩展来满足业务的吞吐量要求。 所以银行的架构是集中和分布的综合体。选择完整性/可用性（C/A）保证数据的强一致性事务处理交易， 是银行在过去的三十几年的业务发展过程中要求遵循的基本架构及编程原则。采用数据库、交易管理中间件从系统级提供的数据强一致性， 简化业务应用的编程使其致力于业务功能的实现是银行过去的最佳实践。因此，集中式计算体系依然至关重要。 在支付宝交易中，这种保持数据弱一致性非事务处理交易，采用分布式计算则是最经济的选择。同理，与银行核心交易无关的外围业务也可以采用分布式架构，未来银行的架构一定是一种集中式和分布式混合体系。
2，平台型轻应用和纵向重度应用，支付宝和银行的本质
从两者本质上看，阿里有着互联网企业的重要特征：业务逻辑是平台型的轻应用，即商家卖货，消费者买货，阿里本身不涉及货；支付宝也是消费者和商家之间的买卖并行交易，支付宝本质是交易工具，本身不靠资金的多少生存。
而以商业银行为代表的金融体系则是靠资金来生存发展的， 它的业务逻辑则是典型的重应用： 比如银行业务从资产负债表的构成就主要分为三类：存款、借款、债券等负债业务，储备、 投资、信贷、放款等资产业务，以及支付结算、基金托管、银行卡、担保、理财等中间业务。 因此， 银行一定要做集中式处理， 这不是简单的金额加减问题，要涉及到客户账，分户账，会计总账等系列后台逻辑数据的变更，所有的账务系统要有相应的规则统一管理。 借和贷必须在一个逻辑处理事务单元实时完成并保证 ACID。而阿里的支付借和贷之间是脱钩的，个人支付宝帐户的扣款和商户的支付异步进行。 支付往往滞后帐户扣款。因此仅仅是银行交易的一半途径且不遵循复杂的会计体系原则。
因此，两者的业务应用场景在本质是有区别的：支付宝只是做了支付这一步， 而银行在支付的背后， 需要有整个帐务逻辑和金融风险管控。后者要求每一步操作，不论是查询还是交易都必须有可跟踪的、有时间戳的日志。 如果在银行帐务系统的处理上采用网上购物这种数据弱一致性非事务处理交易架构，错账、乱帐的风险会提高，由此产生金融风险、法律纠纷的风险提高。记得在银行未实现数据大集中之前，银行业务对帐的时间就很长，帐务出现差错，要追帐，查帐，纠错的压力也就相应而来。
传统架构和分布式架构并存情况下， 如何平衡两种技术体系？
一切看业务需求和特征，应用系统能采用集群部署的，尽量集群部署，采用分布式架构；应用系统无法集群部署，应用系统对稳定性和性能看重的，采用集中式架构；数据库系统对性能要求高的，写比例较高的，尽量采用集中式架构；数据库对性能要求一般，读比例较高的，单计算节点无法满足计算需求的，尽量采用分布式架构部署。
一般业务系统都有多个应用部件，WEB、应用、数据库等，根据特征和需求，可采用不同的架构，因此分布式和集中式架构其实是相互融合的，两种架构是共存的。
银行的传统架构核心如何向互联网转型？是否需要一个传统核心，一个互联网核心这种双核架构？
首先要明确为什么银行传统核心要向互联网转型， 传统核心是面向较为固定和增长趋势的渠道， 网点机构、 终端设备 （包括手机银行、网银），为其提供账务类的服务，账务类交易有一定的规律性，账务交易额度较高，动账交易频率一般。而随着互联网金融业务的快速发展，引入了大量互联网的账务类交易，面向的用户群体也从较为固定转为非固定，在特殊活动期间，如双 11，将带来超高的用户量和业务并发，而日常的一些业务活动，如秒杀、抢购、一元购、秒贷等等，也将给账务类交易带来一些无法预测的瞬时峰值， 所以对传统的核心考验不再局限于固定的渠道和增长，而是涌入式和爆发式的，传统核心靠集中式的架构已难以支撑这种业务规模和冲击。
其次要明确当前向互联网转型是否是迫切和有必要的， 还是可以采用逐步过渡的方式去进行。比如引入了互联网金融类的业务，但涉及到核心账务类的交易体量和并发度实际并没有给传统核心带来多大的压力，或者说互联网金融类的业务大多数还只是查询类业务，只在互联网金融系统内部进行，较少的动账交易在核心系统完成，这时过早的将核心系统向互联网转型， 或许会对其他非互联网类业务造成一定的影响，甚至动作较大，造成其他业务的大量改造。所以向互联网转型的过程要平稳，优先保证非互联网类业务的稳定、正常运行时首要目标。
最后给出我们行的传统核心转向互联网的一个参考， 我们按照互联网核心的规划，搭建了一整套互联网金融系统，但原有生产核心没有大的变化，涉及账务类的交易，也是由互联网金融系统提交生产核心处理。后面运行稳定了 1 年多，再逐步将一些涉及互联网账务类的交易从核心中摘除，由互联网金融系统处理，最后全部涉及互联网类的交易全部移交， 原核心生产继续为其他非互联网类业务提供账务类服务。
面对大量的存量老系统，银行向互联网转型过程中有何更加稳妥成熟的步骤处理这些系统？
采用双核心架构，存量老系统的非互联网类业务走原有核心系统，互联网类业务走新互联网核心。采取先新搭建完整的互联网金融核心系统，涉及账务类的交易继续由原核心处理，再过渡到逐步将一些涉及互联网金融的账务类交易从原核心中剥离， 直至所有交易剥离完成，期间两套核心并行运行，最后两套系统同时提供非互联网类业务和互联网业务的账务类交易。
相关方案参考：
银行IT架构转型思路及LinuxONE银行行业解决方案分享
下载地址：
http://www.talkwithtrend.com/Document/detail/tid/417031
以下内容有助于解答阅读中产生的疑问：
LinuxONE 对于中小银行来说规模适用性和性价比有什么优势？
没有确定性的体量标准， 从产品角度来说， LinuxONE 有两款产品，一个入门级，一个企业级。LinuxONE Rockhopper 最高 30 个 CPU，满足入门级需求，从几百亿到 2000 千亿左右规模银行的大规模整合，核心整合都是适用的，而 LinuxONE Emperor 最高 170 个 CPU，满足更大规模的体量需求。LinuxONE 的配置粒度可以比较细，比如 1 个CPU 的粒度增加，所以需要根据具体的客户目前的生产情况和发展预期来决定。
就硬件本身而言，由于制造工艺的复杂度，冗余设计，整机设计等等原因，LinuxONE 相对于其他小型机硬件平台更贵一些。但在数据中心建设中，硬件只是其中一个很小的部分，围绕硬件而产生的软件，机房，电力，网络等方面将会带来更为庞大的开销。而 LinuxONE解决方案不但简化了整体架构，还会带来总体拥有成本的降低，具有明显的解决方案性价比。
举一个真实的城商行客户案例，该城商行规模接近 2000 亿。
以 Oracle 软件费用为例，生产+灾备模式下，3 台 LinuxONE 服务器（ 每 台 12 核 ， 共 36 核 ) ， 整 合10*S822(20c)+3*E850(48c+15*X3850(60c)， 354 个物理小型机 CPU 核，900 个 X86 核，共 1254 个 CPU 核。根据 Oracle 计价模式,Power 和 LinuxONE 按照实际物理核付费，X86按照 0.5 核的比例付费。即 LinuxONE 方案（36 核） ：原方案（804核） 约等于 ≈ 1： 22 ≈ 4.5%， 相当于 LinuxONE 方案能够节约 95.5%的 Oracle 软件成本。
采用 LinuxOne 架构如何实现内部安全隔离？
金融传统的互联网架构都是安全纵深非常深的架构模式，采用LinuxOne 的话，那么相当于所有的虚拟机都在一个物理设备内，那么它是如何实现内部的安全隔离？如何让客户可信？
LinuxONE 是商用服务器中唯一获得 EAL 5+ 最高等级安全认证 （权威的第三方安全认证组织， CC ） ，EAL5+的标准是分区之间的隔离性等同于物理隔离，包括分区间的 CPU, 内存，存储连接，网络连接等都可以物理隔离。在部署物理隔离时，从硬件底层通过微码来实现物理分区，将 CPU,I/O,内存，网络独占模式而不是共享。技术的可信度首先在于专业认证和市场案例，除了刚才提到的专业认证，我们已经帮助客户在物理机上实现分区隔离。 比如某城商行客户将两个不同的业务网络部署在 LinuxONE 上，同时还有一个开发测试环境，实现 3个不同的物理隔离分区，相当于三台物理服务器。
同样 CPU 数量的 Linuxone 和 x86 平台相比，性能差距有多大？
单从 CPU 性能比较，应该在 1：4 到 1：8 之间，但因实际场景不同，比如大规模整合，比如核心业务系统的强 I/O 处理业务，异构灾备等等，1：20，1：30 甚至更高比例也是有的。
Linuxone 平台是否需要外接存储？
需要外接存储，支持类型涵盖传统的 SAN 架构，基于 IP 的存储，软件定义存储，以及分布式存储（比如 Ceph,GPFS）等。
閱讀更多 IBM中國 的文章
