编者按：从今天起，“传统IT”板块将陆续发表与银行传统IT系统相关的文章，敬请关注。
本期专辑是新一代核心系统选型。选型需要解决”业务需求和选择技术平台”两大类问题。前者是应用架构的解决范畴，还涉及行内IT整体规划；后者涉及“是否使用分布式结构”、“是否参考微服务”、”是否做双核心”、”双活等运维需求怎样落地”等问题。本专辑谈及了核心相关的所有新技术领域，算是个开篇吧。
微众银行是国内中小银行体系第一家采用分布式核心系统的银行，同时也是国内第一家总体采用去IOE的分布式互联网框架的第一家银行。在此之前，国内的银行均普遍采用IOE的技术体系。
去IOE的分布式核心系统建设没有先例，业界也没有可借鉴的经验。甚至，用最新的Java技术体系建设的核心系统都刚开始在极少数厂商酝酿中，当时大家普遍用的都是Oracle的存储过程来做存贷款业务交易，又笨又重，代码的可解释性差。对于一家初创银行来说，定下去IOE的基调，是比较需要魄力的。笔者还清楚的记着，某行以为朋友听说我们在做分布式核心系统，而且是自主研发，信誓旦旦的说我们一定会失败，没有银行敢这么做过。
当时定了一个三年三步走的战略：第一年采购厂商的系统，做到30%行内自主研发；第二年做到70%行内自主研发；第三年100%完全达到行内自主研发。实际上，仅第二年的7月分左右，核心系统建设第二期完成，厂商全部撤离，就已经提前达成了完全自主研发的目标。
对于厂商采购的原系统，也并非是拿来主义，在业务设计、框架设计广泛借鉴了腾讯、平安等先进经验。在架构上广泛采用最新的Java体系，如Spring，Mybatis等，在代码层次上全部采用Java，拒绝使用存储过程、视图、触发器等。
可以说，自从14年12月份微众银行的分布式核心系统投产后，业界才开始广泛的换核心，14年底平安银行就开始建设分布式核心系统，直到最近两年，很多中小行才开始考虑更换分布式核心系统。
总体来说，微众银行的分布式核心系统有着非常多的业界开创性的特色：
一、业务导向、产品导向
在微众的一次全员大会上，某位领导说过这么一句话：在尊重金融规律的前提下，适当的运用互联网的先进技术。这一句话其实就是信息科技部的价值体现，银行不同于互联网公司，可以做到技术的标新立异。技术的运用是在深刻理解银行业务的前提下，因地制宜。
因此，信息科技部比较大的一个特色就是要求全员都要深刻的懂银行业务，做系统之前一定要先把业务了解透彻。比如做转账，就要懂得转账的业务模式，同时还要了解内部账、客户账等等的关系；做支付，就要懂得支付通道、清算模式等等。
上面的价值观是很多银行都没有意识到，或者不具备，或者是懒得去考虑的。见到了太多了的地方，对于金融业务不慎重视，认为有个岗位随便一个人都可以顶上去干。在微众是非常看重金融经验的沉淀和积累，技术是受控于业务的导向。
分布式核心系统建设之初，并没有盲目急于动工，而是先进行了大量的业务的设计和论证。包含传统银行核心系统的业务模式，互联网场景下核心系统应该扬弃的地方。举例来说，现金业务怎么搞，要不要？分布式环境下日切该怎么做，利息怎么计算？分布式的锁怎么做？转账交易如何做到平账？分布式账务如何做到平账？账户体系怎么设计？冲账/冲正怎么玩？
运用了大量的时间，和业界有丰富经验的专家来进行业务方案的设计，同时进行技术框架的设计。等所有的事情想清楚了，在动工建设。
二、重架构、轻应用
全行进行了统一的架构设计，架构设计综合考虑到了容灾、备份、扩容、管理、调度、交互、联机、批量、实时、异步、通信等问题。全行统一架构的好处就是在底层就处理了大部分技术问题，让应用层各个系统轻装上阵，不需要做更多设计考虑，将更多的精力放在业务逻辑上面。
微众的全行架构广发采用了BAT的分SET，同城双活/多活，分库分表等经验，后来这套架构方法被很多银行借鉴，但目前还没有一家银行做过超越，在气象上接近就是中信百信银行，也有着雄厚的实力。
三、去IOE、分布式
全行重要系统基本都采用TdSql数据库（Mysql的一个腾讯改进版），全部应用都采用分布式架构，重要系统全部自研。
分布式场景下，路径追踪，跨库、跨集群、跨SET交易都变得比较常见，综合考虑全行统一流水号设计、统一日切设计、统一分库分表、统一的分布式事务，让开发、应用、运维变得简单。
四、交易核算分离
交易核算分离不知道是什么时候的提法，还有个更激进的交易级总账。笔者所了解到的中小银行，微众银行是第一家做交易核算分离的。核心系统只记录交易流水，不做核算处理。核心系统只负责常规交易、账户管理。
日终的时候，交易流水会转化为会计流水、总分核对流水等汇总到小总账系统单独进行核算。
交易核算分离的最大好处就是，减轻了核心系统的压力，核算不会影响交易，交易不会影响核算。交易系统和核算系统各司其职，不在搅在一起。系统部署也微服务化，减轻了运维的压力。
五、独立小总账
交易核算分离的一个手段就是独立一个小总账系统，核心系统的交易流水会不定期传输给小总账，小总账系统将其转化为会计流水。
日终的时候，日终跑批也分为两步：第一步是核心系统日终，处理计提，结息，资金清扫等事项；第二部是会计系统日终，处理总账过账，总分核对，生成科目分户账。
全行有一个独立的大总账系统，各个交易系统包含核心系统、黄金系统等的小总账会通过文件的形式传输给大总账系统进行并账处理。不像大部分银行，银行总行还在核心系统，并未做分离。
六、瘦核心
将传统银行的胖核心的建设理念完全摒弃，建设仅仅包含账户管理、交易管理的瘦核心系统，将其他业务逻辑分散到外围系统中。其中，CIF系统、黄金系统、支付系统、小总账、大总账系统完全从核心剥离并微服务化，客户信息只在核心系统有一份弱集合拷贝。
瘦核心的好处是不言而喻的，胖核心又大又笨又重，业务复杂，出问题互相传导，开发缓慢，业务深度耦合。
七、纯Java技术体系
摒弃了Oracle及视图、触发器、存储过程等，不允许用上述技术。全盘采用Java语言做架构和业务逻辑的开发。
后来有些金融科技公司走得更远，采用Go语言做主导。笔者认为这是不合理的，Go语言无法做到Java语言那样丰富的知识库，Java的体系和生态是其他语言无法比拟的。做交易系统，Java语言是目前最为合适的。
八、复杂交易
由于采用了去IOE的分布式框架，业务和交易模式随着发生了质变。日切、转账、结息都有着和传统业务模式完全不同的特点。所以在做业务设计的时候，不能在抱着过去的经验，需要结合分布式理念做全新的设计。
譬如转账的时候正好日切，分布式环境下，客户A于T日转账给客户B，而客户B的时间已经到了T+1日，那么，期间的利息如何计算？会计分录如何写且不产生单边账？
尾声：
不知不觉，已经离开深圳和微众三年了，有幸在含着金钥匙出生的公司里有过一段难以忘怀的经历，也把自己当年的所见所闻，记录下来，谨以此文感谢微众银行共事过的领导、同事和朋友。