业务架构是一个新型的名词，最早是业务端和系统架构，随着业务的发展，业务的需求和系统之间需要架构做转换。但是，所有的系统不稳定时期，往往是系统升级的时期，系统改造时产生的阵痛，京东支付在这方面的实践经验。

　　为何要业务架构变革

　　互联网支付的发展从艾瑞的数据看，2015年整个支付交易规模11万亿，到2018年达到22万亿。尽管和银行的规模相比有些低，但是互联网金融和银行金融区别：互联网金融的特点是金额小，但是笔数多。银行的手续费非常高，金额大去银行，小金额不划算。而互联网的促销时手续费非常低，几分钱而已。这个金额下，交易的笔数远超银行，而且快速增长。2015-2018交易金额翻一番，交易的笔数也要翻番。系统的话互联网金融系统和金额无关，而是和交易笔数相关，快速增长，是机遇和挑战。

　　业务产品快速变化，之前是靠业务收单为主，并且计算手续费，非常简单的业务模式，随着2011年业务的发展，现在程度互联网金融远不是之前第三方支付，现在有银行、保险、证券、基金等，因此互联网金融都想涉足，业务的形态和流程的复杂度，必然会极速化的发展变化，而且要求用户体验达到极致。

　　京东小金库背后是货币基金的业务，有更好的基金出来，会用小金库购买收益率高的基金，购买行为系统要做业务流程，想货币基金立即赎回，在帐目上做应收款，然后做报收款等等。基金的流转非常复杂。同时，需要提高研发的开发效率。互联网的竞争是以天来计算，哪怕几个小时，业务的规模和占据的契机完全不一样。还要保证质量和可靠运行。

　　什么是业务架构变革

　　架构变革是架构变迁迭代重要的一环，如果系统架构不能解决问题的话，靠人为的调整很难满足业务发展的需要。因此需要架构的变革。三个标准进行评估：一个是节约成本，同样收益下。一个是提高研发效率，一个是满足业务的发展。

业务架构变革的痛点

　　1、影响广，基础设施架构变动，相当于核心系统的变革，必然对核心之上的业务产生影响。2、周期非常长，影响到外围的变化，同时整个周期下新的业务不能中断，老的系统需要维护，两个系统并行的情况下，运营难度可想而知，而且成本非常大。3、新老系统的切换，之前业务小的话可以停机维护，在线的切换好一些。对于第三方支付来说影响更大，7*24，只能做在线切换，系统的切换一定是在线，而且是无缝的。

　　关于系统切换有一个形象比喻：高速公路上换轮胎。某银行高管也曾经表示：不换核心等死，换了核心找死。架构的变革不是轻易就能变的。

系统切换的难点：

　　一个是平滑过渡，新老系统之间的兼容性一开始设计的时候就要考虑，保证业务处理的连续性，也要保证异常事件可退回。

　　二是资损控制，资金核算，幂等控制，数据的一致性。需要临时的整合的数据一致性控制。一旦动到资金，要对核算的口径保证一致。

　　举例：央行业务架构变革，一代支付系统向二代系统变革。

十年换一个核心，系统切换周期是五年。商业银行从1999到2005年，做数据的大集中，从各个县集中到省，再集中到数据中心。伴随着银行的核心，2009年已经不适用了，2009-2015银行都在做核心系统的更新换代。

　　首先要有很强的变革目标：接入方式、清算方式等调整，之前是多点接入改成一点接入。

　　变革的特点：

　　最终，从架构看，从分散式的整合成二大支付系统，从三级管理到集中管理。

　　京东支付的架构实践

　　当时为了收单业务，后来老的业务加入新的业务，做了打补丁的架构，弥补业务的需求，无法根本解决互联网金融发展的业务需求。从2013-2014年开始了新的业务架构设计，把老的业务拆分和封装，形成了新的业务架构。

　　业务的变革主要是针对核心的，涉及到上层应用的迁移，这是京东支付两年内要完成的任务。

　　新平台的架构目标

　　新支付平台业务架构将各个产品线的公共交易、支付、财务等基础服务抽象沉淀至基础支付平台，积累账户、会员、信用等企业核心数据，形成稳中灵变的总体业务架构思路，适应未来业务的发展需要。

　　目标1、基础服务抽象与封装、复用公共业务服务，逐步建立会员、账务、会计、交易统一体系，抽象和封装公共处理逻并下沉形成统一的基础支付平台，降低业务产品的复杂度及重复研发成本。

　　目标2、核心系统稳定性需求、解决既快又稳矛盾，基础支付平台做到安全、稳定、可扩展，为上层业务的快速发展与创新提供平台支撑，从架构层面解决互联网金融业务的“快”和支付行业的“稳”之间的矛盾。

　　目标3、提供完整的数据视图、沉淀企业核心数据，沉淀企业核心数据，随着业务数据不断沉淀积累，这些数据是企业持续发展的源动力，同时也为用户和业务提供大数据支撑。

　　收单业务，从最早的网管收到到快捷支付收单，整个业务的模式相对简单，新平台做收单交易的切换。

　　先切换账务核心系统还是切换交易、业务系统?老的业务系统年久失修，很多系统不能动，无法做大的改造，最后决定不再原来系统上升级，而是从新做交易、业务、账务的核心。第一个阶段先切换业务和交易，保证账务不受影响，切换的过程经历了灰度切换，然后分业务进行切换，遇到问题回滚修复之后再切换。整整经历了半年时间完成收单业务切换。

　　第二，会员交易切换，包括个人和企业、移动端的交易。新平台要创建的支付产品，各个门户要串接，业务要逐个切换。资金要成长，账务系统承接会员交易的主要任务。对于结算人员还是看到老的账务系统，交易和应用切到新平台。

　　第三，账务系统的切换。开始存在老的账务在老的系统，比如退款交易还是在老系统中，数据没有清零时，老系统想新系统同步，财务人员看到新系统，资金的核算、账务的核算等。保证新系统的业务发生额是完整的，在这个前提下做账务的清零。收支流水的一致性，逐步的验证，最终实现了迁移。对于新平台是完整的，收单、交易、支付、渠道、账务处理等等，形成了一个闭环。整个过程没有太大的震动，一步步切换，降低了风险。

　　系统切换后的成果

　　1、业务体系：统一客户账户体系、支持业务流程的再造、核心平台稳定可靠、快速响应业务需求、完善资金核算体系、提供完整数据视图;

　　2、系统稳定性：有效提升支付交易成功率、支持日峰值交易千万级以上、支持十亿级会员账户处理、服务可用率达到 99.99%、核心业务系统0停机维护。

　　总结

　　架构变革的误区：1、架构变更就是技术系统升级， 基础架构是公司核心竞争力的重要组成，不仅是技术升级，更是业务流程变革；2、重新造轮子，忽略继承发展，误认为架构变革就是重新建全新的系统，忽略外部接口、历史数据的继承。3、忽视兼容性，无法平稳切换，影响业务的连续性和资金的安全性，造成业务中断和资金损失。

　　架构变革的几点建议：1、持续架构治理，不建议频繁架构变革；2、一旦确定变革，尽早分阶段规划实施；3、不仅解决现有问题，需前瞻性放眼未来；4、关注系统切换过渡，保证业务连续性；5、没有最好的架构，只有最合适的架构。

　　业务变革和IT的关系，传统的银行，业务部门和技术部门是两个大部门，之间的交互靠工单报送需求，互联网要求响应速度快，技术团队需要有业务架构的角色，把技术和业务进行融合。

　　对于技术团队，资源是稀缺的，需要合理的分解，分阶段是为了降低成本，一旦出现问题降低代价。资源充足的情况下，阶段可以重叠，同步进行，迭代式的发布。一个业务一个业务的切换，否则资源的投入非常大。分阶段按业务划分，过渡期的时间要尽量缩短。

作者介绍：阮森灵拥有15年金融行业支付清算业务架构经验，获得清华大学硕士学位，曾先后供职于人民银行、支付宝、中信银行，专注于互联网+金融业务架构和规划。担任京东金融支付首席架构师，承担新支付平台业务架构规划设计。

出处：http://www.wtoutiao.com/p/U42r4R.html