京东京麦插件市场从0到1的演进之路

前言

京麦服务市场是一个面向京东POP、物流配送、仓储、供应链、金融等商家，由第三方提供软件、培训、模板装修、代运营、质检等服务的发布、共享、交易、结算、共赢的围绕电商生态的平台。那么京麦服务市场从无到有，从0到1的过程中都经历了了什么呢，下面跟随笔者来看看京麦服务市场在这段时间的历经磨难和系统演进。

一 小荷才露尖尖角

在初始我们搭建了京麦服务市场，为服务商、商家提供了互通的桥梁，实现了PC版和移动版的插件市场，同时打造了服务商入驻、服务提审、审核发布、订购履约及支付结算的服务生态闭环。下图为当时整个京麦服务市场的系统架构图：

当时开发人员较少、业务复杂度较低、系统交互少、开发时间紧张，所以采用了单体式应用，将业务糅杂在一起进行开发，这样做在初期开发效率较快，可以满足当时的业务需求，但是其中的问题也是显而易见的。

随着业务的发展，从业务上给我们增加了新的订购规则，增加了升级、续费等订购类型，添加了模块等新商品模型，系统交互由原来系统内部模块调用变为使用异步消息队列通知和服务服务化调用，下图为服务订购流程：

在确定这个流程的过程时也是很坎坷的，在在确定流程初期，我们的方案是在订购完成时将数据直接写入当数据库中，接入方通过服务化调用获取存放在缓存中按需加载的数据，但是在执行该方案时，由于沟通的服务调用量与世纪服务调用量不符，导致提供服务异常并影响到其他业务功能，后修改方案，在订购完成时将数据直接写入当数据库和缓存中并持久化缓存中数据，并通过worker将数据库和缓存中数据进行比对来保证数据一致性。

二 路漫漫其修远兮，吾将上下而求索

虽然上述方案满足了业务上的需求但是其中存在的问题也是不能忽视的，单一业务功能存在问题时所用业务都会收到影响，而且在开发过程中简单应用变得越来越大，模块间依赖越来越复杂，在新增和修改业务功能时，要梳理原有流程才能开发，若梳理存在漏洞将会影响其他业务，业务扩展越来越困难，针对这些问题，我们对系统进行了架构升级，下图升级后系统架构图：

将现有业务进行了拆分搭建了开发者中心承载服务提审、插件市场承载订购履约、运营中心承载审核发布、交易平台承载支付结算等业务，从逻辑上和物理上将业务进行隔离使它们之间互补影响，随着业务的拆离系统的增加，订购支付流程也发生了很大的变化，下图为升级后的订购支付流程：

在整个订购履约流程中采用服务泛化调用和异步消息队列来进行系统交互，由于系统增多，业务流程加长，意味这在订购支付流程失败率会增高，对于订购支付来说，成功率就代表着系统的稳定性，一笔订单能否及时完成并进行后续履约对用户来说是至关重要的。系统之间不可避免的会出现网络抖动、接口不稳定等情况，会导致订购履约流程无法流转，这对用户来说是不可接受的，对于这种异常情况，设计了相应的补偿机制，通过系统字处理及时修复异常数据，并使订购履约流程流转下去；除此之外对于每一个重要的流程流转步骤都会记录日志，方便对问题的追踪和恢复。

同时通过交易平台根据不同接入方的业务需求将基础支付能力进行组合，构建新业务能力提供给接入方，为其赋能，并通过插件市场将订单履约信息以服务化的形式提供给开发者，帮助其提升用户体验。

三 欲穷千里目,更上一层楼

为了能让系统更具有扩展性、更好的适应业务的变化，将业务相互影响减至最小，我们对业务进行了更细粒度的拆分，同时对系统架构进行了一次升级，下面是升级后系统架构图：

在其中我们为了提升用户体验将打造了服务前台和服务中台将前后端进行分离，新建订单中心、支付中心、应用中心、结算中心、履约中心、商品中心等原子中心提供相应的基础能力，

并对数据库按照原子中心的力度进行拆分，使数据解耦。

总结

京麦服务市场经过一年多的时间中，在稳定、内容丰富、有了长足的发展。

系统的再次升级，提供服务数量的增加，应用之间调用也随之增加，对于服务的治理和各个应用服务调用的全链路监控将是接下来我们最大的挑战。

本文受原创保护，未经作者授权，禁止转载。 linkedkeeper.com (文／缪宇)  ©著作权归作者所有