京东服务市场是为第三方软件服务商和京东开放商家提供的交易服务平台，为第三方服务商赋能，并为其搭建起与商家间交易合作的桥梁。

服务市场团队在2018年完成了云平台京东服务市场的交接与POP平台京麦插件市场的系统融合，并承载着京东自营与三方越来越多服务进行商业变现的业务诉求。相对于传统的电商系统，服务市场面对着的是更复杂的业务领域，更灵活多变的交易组合场景，如何让系统具备积木式赋能的能力，通过松耦合架构设计具有系统高内聚性，把耦合度降到最低，进一步实现较为合理的微服务架构风格的应用系统，期间遇到了很大的挑战也总结了很多经验。本次分享和大家回顾这个艰辛却有收获的过程。

纵深化的业务整合

两市融合 - 涅槃之路

2017年底，京东云平台京东服务市场交接到POP平台京麦插件市场进行系统融合，我们称之为两市融合。两市融合是为了实现对外统一的服务入口，实现两个系统变成一个系统，但当时这两个市场却是两套完整的系统闭环。

融合项目是对两个市场进行深度的融合改造，融合不仅是进行流程融合和数据融合，其中最难的就是同时支持双边业务的并行运行，所以，整个融合过程在服务发布、服务审核、服务展示、服务订购和服务使用等环节对两个系统原业务进行了大量的兼容处理，造成了极高的系统复杂度和极差的稳定性。

融合方案并没有采取单边市场下线的方案，而是采取了将两个市场裁取缝合的处理方式，交易流程使用了京麦插件市场的流程，商品流程使用了服务市场的流程，这种融合方案现在看来的确不明智。

两市融合 - 并行业务

并行业务的难度在于双边读业务与写业务的同时支持，因为不能简单的下线一边的业务，但当时对数据的读写入口不能完全梳理清晰，所以融合过程中对上下游各种业务需要兼容支撑，因此在融合中的过渡阶段产生了三套流程并行的尴尬阶段，并且还需要同时双写三套数据库表及同步多个数据缓存，复杂度可见一斑。

当时两个市场的两个数据库是独立对外提供数据服务的，如何将两个数据库变成一个数据库，是当时最大的难点。

而且服务市场作为一个交易系统，数据库是系统的核心，不仅MySQL有很多从库，还有Redis、ES、Solr、HBase等作为数据缓存，所以在数据异构方面做了很多功夫。

两市融合 - 流程融合 & 数据融合

流程融合包括服务发布审核流程融合、评价评分流程融合、服务搜索流程融合、订单订购流程融合、结算流程融合、退款流程融合、取消订单流程融合和发票流程融合等等。

以订单订购流程融合为例，由于服务市场和插件市场融合切换是无缝的（不能停服务），且两侧订购、订单数据结构又不完全一致，同时数据切流又是逐步放量。所以订购、订单流程的融合采用数据库双写的方式，所谓双写方式，是在写原服务市场数据库和插件市场数据库时，通过订阅Binlog，使用BinLake框架订阅写入sql再整理数据写入新数据库。最终所有服务通过调用新库进行查询服务。

这种双写机制可以很好的进行回滚，当新流程出现问题的时候，可以切回到老数据库进行降级。当新订购流程出现问题时，也可以通过关闭切流控制影响范围，采用老流程进行订购订单处理流程。

这里补充说下，插件市场和服务市场的老流程都是写到各自的老数据库中，而新流程其实也是写到服务市场的老数据库中，新数据库的数据都是通过BinLake写入的，这样保证在流程融合过程中的数据一致性。

而流程融合完成后，即读入口都切到新数据后，就可以逐步切换写入口了，把两套数据库变成一套数据库。切换的方式其实很简单，主要是通过配置中心进行逐步切换写流程，但要考虑切换失败如何处理异常流，假如遗漏了一个场景，还有业务读老数据库，但这时老数据库里是没有数据的，怎么办？

所以，准备了两套方案，一套回滚，另一套补偿。考虑到回滚的操作难度很大，因为代码回退、流程回滚可能出现的风险会很高，因为那时数据已经不一致了，所以首选方式是补偿，当数据出现不一致时，启动后端校验Worker将数据补偿到老数据库中，并迅速修复线上问题。

两市融合 - 系统架构

随着融合的深入，服务市场的架构逐步演进成为经典的三层架构，底部是外部依赖，概括主要是京东商城和京东金融的中台服务；中间是服务市场的服务层，包括服务引擎、商品中台、订购履约中台和支付中心等系统；上部是服务市场的应用层，包括服务市场大前端、商家工作台、服务商后台等系统。

架构部署 - 调用关系