服务市场系统解耦及数据异构设计架构

冯廷鑫，于2017年加入京东京麦服务市场，负责核心交易流程的开发，在工作中不断提升技术能力，向架构师方向迈进。

序

服务市场(fw.jd.com)是京东唯一一家为第三方软件服务商和京东商家提供服务的交易平台。服务市场是一个电商平台，但是我们不同于普通电商平台的是我们售卖的商品是京东商家可以使用的服务，这些服务是京东内部或外部开发者开发的工具，大家也可以通过fw.jd.com看到。

2018年服务市场做了多次的技术架构升级，经过这段时间慢慢的积累，是时候对自己的工作做一个简单的总结。

背景介绍

早期服务市场流量较小，将面向用户的大前台和服务商后台揉在一个项目中进行开发，缺点：耦合度过高，项目过于庞大，对于开发者不容易维护，开发成本高。一旦系统某一方出现问题，牵一发而动全身。所以在接手服务市场后，根据具体的业务场景进行了应用的拆分。

系统解耦

针对这一痛点，我们对系统的功能和业务进行了详细的梳理，对系统进行了服务治理。思考角度如下：

商品中心

服务市场包含了多种服务，对于商家而言，每一个服务都是一个商品，商品应该有一个统一管理它的系统，这个系统实现商品的底层数据结构，我们可以叫它商品中心，当其他系统需要任何商品的信息时，可以通过调用其提供的接口，获取相应数据。

交易平台

服务市场需要提供给商家服务的购买，下单，支付的能力，这种能力起初同服务市场的前台系统高度耦合在一起，但因为业务的多变化和交易能力的组件化需要，所以需要给服务市场提供一个满足其交易能力的平台，我们又称交易平台。该系统为服务市场提供纯粹的交易能力。

订购履约

在商家支付完成后，商家需要在服务市场中看到刚才下过的订单并且能够保证商家对下过订单的服务的可使用性，这叫做完成订单的履约，维护履约信息对于系统来说也是十分重要的，所以我们又维护了一个新的系统“订购履约”。

服务引擎

为了保证用户在多个端的正常使用，同时将各系统间调用关系解耦，我们又搭建了服务引擎来提供服务市场的能力给各个端。服务引擎封装服务市场的基础能力，当端接入时，由服务引擎提供统一接口，来提供能力的输出。

综上我们把原来职责不单一的系统拆分为如下图所示：

数据异构

基于上图可以看到我们已经对系统的业务层面按照服务、交易为维度进行了拆分，在数据支持方面，我们还看到早期服务市场因为用户流量小，大部分的地方都是直接查库，这种方式带来的影响还是显而易见的，很容易出现慢sql、垂直打库等问题，一旦出现，会对系统产生不可知的影响，虽然在系统层级做了读写分离，但是对数据库的压力还是很大。如下图：

基于以上情况，我们做了如下思考：（下面以订单为例）

为了防止在用户层对系统造成压力，系统在面对用户层时能够抗量是十分重要的，常见的抗量策略就是使用多级缓存，防止直接打库。常用的缓存包括：Redis，ES，JVMCache…，在考虑服务市场订单时，我们主要考虑到订单的量十分庞大，我们也知道ES一般情况下满足的是搜索的多种场景，但根据服务市场特定业务场景考虑，我们采用了把订单数据存入ES的方案。关于导入我们有两个方案：

方案一：依托于京东自有的BINLAKE，其原理是监听数据库的binLog，然后给系统发送MQ消息，然后同步到订单ES中；

方案二：在订购履约中心做写入切面，当监听到写入操作时，发送出来MQ消息，然后再写入到订单ES中。

笔者认为这两种方案不分优劣，但是方案2需要统一写入入口，才能保证ES与数据库的数据一致性。最终根据当时服务市场架构特性，我们采取了方案二，但是笔者认为方案一更满足于多个写入入口的情况，以后会向方案一进行优化。通过订单ES的构建，系统在订购履约中心提供统一接口，为上层建筑提供服务。该方案的设计，经过多次大促的洗礼，圆满的完成了任务，但我们会继续向更好的架构优化。

总结

现服务市场已完成服务化治理，实现了前台轻量化、多中心支持赋能，数据持久方式多样化，并接入京东大数据集市，数据分析自动化，逐步向更智能的服务市场迈进。

我们通过前面部分也可以看出，整个系统都在一个项目中可能会让系统更加的繁琐，维护成本变高，从我们系统的拆分来看，可以让读者更清晰的看出某个系统具体负责的内容，这对于系统的模块化是有很大的帮助。自己之前太过在乎于某一块代码该怎么写，现在去画这些图，其实更让我能够从稍微宏观一点的地方看，对自己有较大的启发。