金石系统 | 多中心高可用的交易系统

本文主要是介绍金石系统 | 多中心高可用的交易系统，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

点击「京东金融技术说」可快速关注

「摘要」互联网应用多以SOA、微服务架构，多实例多机房部署方案为主；此架

构基本能够满足大部分应用场景，也是现在大部分公司及组织机构最主要的系统架构及部署方案。但是，身处崇尚创新、追求卓越的团队氛围下，对于京东支付用户体验的的无限渴望；以多中心高可用为核心架构思想的交易系统应运而生，后面我们称之为金石系统。

金石系统的主导思想是尽量不强信赖于任何系统，包括数据库、缓存等存储介质；同时对于机房的可用性也做了全面的容灾策略，实现了交易系统的多中心架构。另外，主线流程非常简洁，本着能异步就异步的基本思想，尽量降低系统运行风险，提升系统的自愈能力，作为未来5年的核心底层服务，为整个京东支付保驾护航。

金石系统支持着网银支付机构的全部交易；囊括快捷、网关、白条、小金库、钱包余额、线下充值、预付费卡、支付营销等支付工具；支撑着收单、代收、会员、预授权、退款等交易产品；推动着账务、清结算、交易记录、企业站等业务系统的正常扭转；是支付链路中非常重要的一环；承上启下，记载了支付过程中产生的支付数据，作为支付的主要凭证；支撑着每年的618及双11大促；对商城、金融、全球购、外单等不同商业主体提供高可用的底层支付服务。

---支付核心研发部出品

项目背景

随着业务体量的越来越大，每分钟上万、每天上千万的支付请求，瞬时峰值几十万的支付请求；现有的系统已经没有办法支撑未来几年的日常需求及大促压力；再加上老旧的架构体系，极其不稳定的中间件（MSP），非常昂贵的数据库（Oracle），与集团脱节的RPC技术（DUBBO），强依赖数据库，单中心的系统架构等问题，使得系统的全面架构升级迫在眉睫。

因此，重新搭建一套高可用多中心架构的交易系统迫在眉睫。

2016年11月14日：金石系统项目正式启动。初步搭建一个解决方案突击小组，经过半个月先后10几次的头脑风暴，最终初步拟定出一套完整的多中心技术架构的实现思想。
2016年11月25日：开发小组正式成立。搭建了一个5.5人（4全职+3兼职）开发团队开始突击攻坚。
2017年1月18日：全面上线。经过小伙伴们2个月的并肩作战，金石系统于2017年1月18日全面上线，线上不断测试优化，找各个相关系统进行最后的线上联调测试。
2017年2月15日：正式开始线上切量，继续观察业务的运行情况，不断完善，不断优化。
2017年3月31日：京东集团内部流量于全量切完。

短短的4个月从无到有，再到全量切完集团内单，整个流程进行的非常顺利，没有出现任何重大事故，在此非常感谢小伙伴们的辛苦付出，你们是最棒的。

基本架构思想

1、取消存储介质的强依赖

数据库是数据落地的主要存储介质，也是业务正常流转非常重要的一环；往往出现问题就是非常致命的，甚至短时间内都无法解决。因此，取消数据库的强依赖是高可用系统非常重要的一步，尽量保证数据库出问题时，业务依然可以正常运行。

线上业务对系统高性能的诉求越来越大，缓存被很多扛量系统所采纳，一旦缓存挂掉，全部打到数据库上，往往是灾难性的。因此，核心业务去掉单一缓存的强依赖，增添一套备用缓存是相当有必要的。

取消存储介质强依赖的主要方案如下：

（1） 接入JIMDB/R2M双备份缓存，将查询尽量打到缓存上；

（2） 接入JMQ，当数据库入库失败时，进行数据重试回写；

（3） 接入MQSender，对JMQ服务进行容灾，尽量保证异步消息的高可用性。

2、UUID本地化

很多业务场景都需要唯一的业务单号，通用的方式是采用数据库序列进行生成，此方式强依赖数据库，数据库故障将是致命的（本人亲身经历过，非常深刻）。

UUID服务架构升级过好几版；从集中性强依赖数据库方式；到集中式不强依赖数据库方式；最终变身为不强依赖任何服务，完全本地化jar包方式生成；完全经受住京东618、双11大促的考验，在部门内部广泛推广，得到大家一致的好评。

主要实现原理如下：

（1） 实例首次启动时，连接注册中心获取实例号，并保存到实例所在机器本地，以后不再获取；

（2） 单号加入时间戳，时间精度精确到秒，秒级支持并发量位数可以动态配置；达到单机单号不重复，加上实例号达到集群不重复；

（3） 这样UUID的生成将完全在本地JVM内存中生成，保证最优的性能及稳定性。

3、缩短业务主链路

随着SOA架构、微服务被各大企业集团采纳，一个业务往往不再是一个简单的系统，整个链路上存在着越来越多的分支流程；但是肯定不是所有的环节都是必须的，也不是所有的节点都是必须实时处理的，更不是每个分支都是必须成功的，短时间降级是可以接受的。

因此，合理的把控及缩短业务主链路流程往往能事半功倍，甚至是一个高可用架构的必备思想，只有做到主链路尽可能的短，才能最大限度的保证系统的高可用性，关键时刻可以将性能较低、服务异常的非主链路服务降级，尽量保证业务主链路的正常运行。同时，主链路越短，业务耗时越短，系统性能越高，运行越平稳。

多中心架构

随着互联网化的不断深入，各行各业对于系统的高可用性的要求也是越来越高；任何一个系统在开放的互联网大环境下短暂停止服务，负面影响的代价越来越大，因此系统的高可用性也已经成为企业硬实力的一个体现。系统的高可用需要很多方面来保证，不是一个简简单单的系统就能搞定的，也不是堆硬件就可以实现的。多中心架构是实现高可用系统非常重要的一种方案；系统的多中心主要是DB的多中心，下面咱们对金石系统的多中心进行详细的分析与探讨。

1、多中心架构基本思想

（1） 在三个不同的机房，分别部署一套集群，每个集群都只承载1/3的线上流量；

（2） 三个集群都承载线上流量，没有任何一个机房平时是闲置的，也没有任何一个机房拥有全部交易数据；

（3） 每个集群都有一套同机房1主1从数据库集群，异机房还有一个非常重要的灾备从库，最终每个机房都是1主2从的数据库集群；

（4） 平时灾备库都只是有连接，没有数据库读写权限，只有当机房出现故障时，才将灾备库的读写权限打开，同时将备用机房打开，这样就可以将故障机房的流量打到灾备机房去；最终达到不影响线上业务的终极目标。

2、机房故障切换 – A机房故障

（1） 当A机房故障时，需要DBA对于A机房的数据库集群做主从切换，将主库切到灾备机房（B机房）的A3从库上；

（2） 再将A机房配置为线下状态，此时A机房的流量将自动打到灾备机房B机房，此时B机房将承载整个流量2/3的量；

（3） 本属于B机房的流量还会打到B机房对应的主库上；

（4） 本属于A机房的流量会打到B机房中A机房的灾备A3库上；

（5） 当A机房好了后，依赖数据库的主从同步，将A3库中的数据同步到A机房的两个数据库中；

（6） 再找DBA对于A机房的数据库集群做主从切换，将主库切回到A机房的主库上；

（7） 最后将A集群上线，此时A机房的流量将自动打回到A机房；

（8） 这样一次A机房的故障容灾切换就完成了，在切换的过程中，跨集群的共用缓存将起到至关重要的左右，将保证整个切换过程中尽量达到无损。

3、机房故障切换 – A/B机房同时故障

（1） 当A/B机房同时故障时，需要DBA对于B机房的数据库集群做主从切换，将主库切到灾备机房（C机房）的B3从库上；

（2） 再将A/B机房同时配置为下线状态，此时A/B机房的流量将自动打到灾备机房C机房，此时C机房将承载全部业务流量；

（3） 本属于C机房的流量还会打到C机房对应的主库上；

（4） 本属于B机房的流量会打到C机房中B机房的灾备B3库上；

（5） 本属于A机房的流量会打到C机房对应主库的一套Other表上，同时会发出一条同步数据JMQ消息，来保证当A机房好了后自动将数据同步到A集群数据库中；

（6） 后续操作跟单纯的A机房故障一致，不再赘述。

总结

金石系统圆满的完成了它的首次618大促，高效稳定的支撑着整个618大促。同时，通过了线上的机房故障演练，无损的支撑着整个京东支付各个业务；也是京东金融首例多中心架构应用，此项目的战略意义非常重大，希望日后可以将此项目的架构思想在其他系统上继续完善壮大。最后，发自肺腑滴...希望京东支付越来越好，希望京东金融日趋强大，希望我们的大京东光明无限。

---支付核心研发部出品