京东服务市场微服务架构和积木式赋能挑战

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

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

纵深化的业务整合

两市融合 - 涅槃之路

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

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

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

两市融合 - 并行业务

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

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

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

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

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

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

这种双写机制可以很好的进行回滚，当新流程出现问题的时候，可以切回