银行转向“瘦核心”，技术路线选型面对 4 个典型问题
核心业务系统是银行最重要的IT系统，号称“银行的心脏”。近几年银行核心业务系统的规模急剧扩大，面临的运行风险、困难和挑战日益增大。中小银行核心系统IT架构转型，必将面对下面四个问题：
典型问题一：关于中小银行核心系统转型的必要性？
胖核心的模式在目前银行业务发展过程中有这么几个很难逾越的障碍：
耦合性太强，账务问题对联机交易影响太过严重。
渠道扩展太快，胖核心的模式导致核心系统本身的扩展性跟不上渠道扩展的趋势。
账务规则及产品变化，胖核心的模式无法实现灵活性变更，每次变更需要在核心内部做手术，风险很大。
既有巨大的批量业务，又有巨大的后台联机业务，从基础架构及数据库优化都不是太容易的事儿。
对于银行的核心系统究竟是胖还是瘦，其实从很多年前开始到现在一直在讨论，二者在从前的业务发展过程中应该说各有利弊，所以采用胖瘦都有。但是随着信息技术和互联网技术的发展，银行的业务模式和业务渠道在悄然发生天翻地覆的变化，面对这些变化，固有的胖核心模式还是遇到很多解决不掉的问题，所以这是核心进行剥离的驱动力。而且随着信息技术的发展，类似系统间通讯链路太长的问题完全可以通过系统设计和技术手段来避免。因此，胖核心在未来的银行业发展过程中，肯定会需要做一些改造优化，账务从核心剥离，使得整个系统的模块儿化、灵活化得以发展。
典型问题二：关于中小银行核心系统基础架构的发展方向，究竟是分布式还是集中式？
不同的应用架构需求，衍生不同的数据系统架构，这里仅以互联网金融支付宝和传统银行进行对比：
一，分布式与集中式数据库的分野？
在业务体系上，支付宝和银行在业务逻辑、监管方式、数据要求上完全不同；业务决定技术，这也造成了不同的技术路径。需要强调的是，尽管两种不同的技术路径，但技术原理却是相同的。分布式和集中式数据库各有优缺点，也就各有不同的适用环境。
2002年，麻省理工学院MIT的教授在数学上证明了CAP理论。在分布式计算（存储）的架构里，由于网络引起的时延是必然的（Partition Network Toleration），因此对于一个操作在数据一致性（C=Consistency）和数据可用性（A=Availability）方面必须取舍一个。许多互联网的业务类型（电商、搜索引擎等等），可以接受最终的数据弱一致性，因此分布式计算模式加数据可用的高扩展架构成为Web2.0公司的平台基础。而对于金融业需要数据实时强一致性的业务，采用关系型商业数据库来满足ACID（代表Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性，是实现实时强一致性的基础）也是历史的正确选择。
分布式计算、集中式计算不是谁替代谁，而是各有不同的用点。适合不同的业务场景需求。互联网应用确实将分布式计算带到了新的台阶，但是并没有突破计算机科学的CAP基本原理。因此有时候需要牺牲数据一致性换得处理能力的线形可扩展性。而银行业务需要注重数据的实时强一致性采用集中处理，在一个统一的唯一数据视图上进行横向和竖向的扩展来满足业务的吞吐量要求。所以银行的架构是集中和分布的综合体。选择完整性/可用性（C/A）保证数据的强一致性事务处理交易，是银行在过去的三十几年的业务发展过程中要求遵循的基本架构及编程原则。采用数据库、交易管理中间件从系统级提供的数据强一致性，简化业务应用的编程使其致力于业务功能的实现是银行过去的最佳实践。因此，集中式计算体系依然至关重要。 在支付宝交易中，这种保持数据弱一致性非事务处理交易，采用分布式计算则是最经济的选择。同理，与银行核心交易无关的外围业务也可以采用分布式架构，未来银行的架构一定是一种集中式和分布式混合体系。
二，平台型轻应用和纵向重度应用，支付宝和银行的本质
从两者本质上看，阿里有着互联网企业的重要特征：业务逻辑是平台型的轻应用，即商家卖货，消费者买货，阿里本身不涉及货；支付宝也是消费者和商家之间的买卖并行交易，支付宝本质是交易工具，本身不靠资金的多少生存。
而以商业银行为代表的金融体系则是靠资金来生存发展的，它的业务逻辑则是典型的重应用：比如银行业务从资产负债表的构成就主要分为三类：存款、借款、债券等负债业务，储备、 投资、信贷、放款等资产业务，以及支付结算、基金托管、银行卡、担保、理财等中间业务。因此，银行一定要做集中式处理，这不是简单的金额加减问题，要涉及到客户账，分户账，会计总账等系列后台逻辑数据的变更，所有的账务系统要有相应的规则统一管理。借和贷必须在一个逻辑处理事务单元实时完成并保证ACID。而阿里的支付借和贷之间是脱钩的，个人支付宝帐户的扣款和商户的支付异步进行。支付往往滞后帐户扣款。因此仅仅是银行交易的一半途径且不遵循复杂的会计体系原则。
因此，两者的业务应用场景在本质是有区别的：支付宝只是做了支付这一步，而银行在支付的背后，需要有整个帐务逻辑和金融风险管控。后者要求每一步操作，不论是查询还是交易都必须有可跟踪的、有时间戳的日志。如果在银行帐务系统的处理上采用网上购物这种数据弱一致性非事务处理交易架构，错账、乱帐的风险会提高，由此产生金融风险、法律纠纷的风险提高。记得在银行未实现数据大集中之前，银行业务对帐的时间就很长，帐务出现差错，要追帐，查帐，纠错的压力也就相应而来。
典型问题三：关于中小银行核心系统如何解决互联网业务遇到一系列挑战，例如秒杀、快速响应、弹性负载等等？
应该说互联网的发展对银行的业务模式和渠道模式起到了很大的推动作用，特别是随着互联网用户监管标准的变化，应该说有很大一部分业务来自于互联网模式。但是这个并不代表互联网核心会主导银行传统业务。对于大部分银行来讲还是辐射本地，有其固有的客户群体和固有的业务模式，更重要的是银行业的交易业务的账务规则和业务标准是不会随着互联网进行完全式的革命。所以传统的核心可能会随着时代的发展存在一些问题，但是并不代表传统核心系统会消失。无论怎么发展，互联网业务是属于渠道，我们不能做喧宾夺主的事情。
传统银行核心系统的生命周期往往在10年左右，甚至更久。一些新兴的企业进入到这个领域，特别是互联网金融企业，快速推出新产品，蚕食银行的中间业务，这也提出来一个问题，我们的后台是否有一个灵活的架构支撑这一需求。银行后台API化，服务化，把它暴露出来，这是一个关键的能力，表现就是业务敏捷化。这里也对核心的选择提出了三个选择点：
1.单核，构建新型的单核系统。
2.双核，保留传统核心，构建一个独立的新核心，以满足新兴的需求。
3.无核，没有绝对的核心，每个模块各司其职，组件化配置。
但是不管银行选择单核，双核，无核哪种形态，都需要将目标和自身的情况联系起来，需要更细心的分析和摸索，不能一蹴而就，也没有绝对选项。
对于银行而言，在构建新一代核心系统的时候，需要有更多的考量：简单的说：看大做小，要看到未来业务需求对于核心系统提出的要求，也就是对核心系统提出的要求，比如技术发展趋势，业务发展模式等等，但是也需要结合银行自身的情况，自己已有的IT资产情况，IT服务和运维能力等等来实践，就是要将梦想照进现实。
典型问题四：关于中小银行核心系统如何建设，应该遵循什么样的决策思路什么样的方案？
基础架构层面：
核心系统是银行承载客户的账户和账务业务系统，其重要性不言而喻。目前中小银行“瘦核心”架构有多种版本，如题。核心系统的业务连续性最关键的还是数据库的安全稳定性。前端应用可用负载均衡如等高可用方案保障稳定性，而数据库的稳定性则题上几种模式采用不同的方案，稳定性各有千秋。
1、小型机+X86模式。数据库（Db2或者Oracle）采用小型机，双机HA模式保障高可用，应用则用X86 通过负载均衡方式保障高可用；
2、Oracle一体机+X86 架构，数据库（Oracle）采用其一体机保障高可用，X86服务器跑应用；
3、X86架构，其数据高可用性采用互联网公司（如腾讯、阿里）的分布式数据库，目前微众银行采用这种架构，其高可用性是基于分布式数据库在软件层面保障。也有少部分银行尝试这种模式；
4、LinuxOne架构。近年来IBM力推了基于大机架构的开放平台，这种设备既有传统大机的稳定性和高吞吐和负载能力，又结合了开放系统Linux的优势，非常适合银行核心系统类业务的运行。
不同模式其要求的资金投入和技术力量投入不一样，银行根据自己目前核心系统的模式及迁移工作的成本综合考虑。
业务和应用层面：
新建核心应该还是主要也业务驱动去推进，由上向下，根据业务选择需要建设哪些系统。首先第一步要对本行的所有开展的业务进行梳理，梳理完后收集业务需求。在业务需求确定后，可以着手进行核心的选型工作。确定是要做成集中化的“胖”核心，还是交易与账务、管理分离的“瘦”核心。（也可以多与兄弟银行交流学习）选型完之后，可以与各大厂商进行交流。交流完进行POC以及后续的招标工作。选择一个实施经验比较丰富的厂商还是很有必要。后续的工作就是开发、数据迁移、测试、投产等一系列的工作。先从无到有吧，建议在一开始考虑要做核心的时候，要好好做一下数据治理（如数据标准化、元数据管理）与服务治理（服务的全生命周期管理）。后续所有系统的建设都按照统一标准规范去执行。因为等核心上线后再去做这些会很麻烦。
本文由社区专家赵海根据社区交流活动整理而成。