KTV在线预订在发展过程中主要面临以下问题:

  • 商家给到的包房库存不能代表线下实际包房情况

    一些商家会担忧KTV在线预订会变成电影预订一样,控制他们业务的生命线,因此会给很少的包房库存。

  • 商家除了KTV在线预订之外,还要接待其他预订渠道的客人

    正常情况下,商家还要接待线下电话预订和团购购买而来的客人,因此针对在线预订包房会具有不确定性。

  • 不同时间商家的接待意愿不同

    比如在节假日的时候,其他渠道引流的客人已经很多,就很难提供给线上客人使用,但在淡季的时候,商家更愿意多接待KTV在线预订的客人。

  • 商家自己使用管理系统与我们提供的预订系统脱节

    商家都会有自己的管理系统,用于管理包房的开房和结束,商家在接待订单过程中,需要线在KTV在线预订的商家后台操作,之后再到自己的管理系统中操作;整个流程较长,且容易出错。

因此在产品层面需要提供更多的订单接待工具,让商家可以根据自身实际情况更方便的接待预订订单。

在预订发展中,我们依次提供了商家接单模式、售中接单模式及系统直连模式的接单方式,加上在上线之初就已经提供的库存模式,总共存在四种接单方式,给系统设计带来较大的挑战。

1. KTV在线预订总体流程

在KTV在线预订流程中,用户支付成功之后,系统将采用多种手段来促成交易,这个过程是预订流程。

预订流程细节

在预订业务中共有库存、商户接单模式、售中接单模式和系统直连模式。

  • 库存模式:销售从商家拿到的包房库存,系统可以直接扣减这些库存,扣减成功则预订成功,如果库存扣减失败则会流转到商家接单模式。

  • 商户接单模式:商户参与预订过程的决策;用户支付之后如果系统检测到相应包房已经没有库存,则该订单会流转到商家这里,商家可以通过商家后台(PC&APP)或者接听电话,在商户后台界面或电话中获知订单详细信息,并决定是否接单。如果商家同意接单,则预订成功;如果商家拒绝该订单会流转到售中客服;但是商家很多时候不能及时处理,会出现商家超时未处理的情况,相应的很多商家因为太忙可能在电话中并没有清楚订单详细内容,因此针对这部分商家拒绝的订单也会流转到售中客服。针对商家超时的订单,商家可以继续在商家后台中处理,也就会出现一份订单同时由商家和售中客服同时处理。

  • 系统直连模式:系统直连是与商家自身的管理系统直接对接,平台上的订单也会直接进入商家自身的管理系统,从而能够更快速方便的决定是否可以预订成功。单因为每个商家使用的系统网络情况均不同,很容易出现一些商家大部分订单都超时无法处理的情况,针对这部分订单会进入商家接单模式,由商家在商家后台里处理。

  • 售中接单模式:售中接单是售中介入预订流程的模式,主要是来处理商家超时或商家拒绝的订单,由售中客服与商家电话联络,从而确定商家是否要接单,如果电话沟通商家依然拒绝或长时间没有响应,则最终预订失败,如果商家同意接单则预订成功。

2. 预订流程复杂度

通过上面的分析发现,预订的流程涉及的方式较多,有商家直接处理、售中客服介入和商家系统自动处理,在这个系统需求中重要有一下难度。

  • 单个预订方式复杂

    当个预订方式自己有很多自定义的状态,每个预订方式的状态会自我流转,每个预订方式的状态也会比较多。

  • 预订方式之间的流转

    在图中会发现预订方式在一定情况下会发生流转。

  • 预订方式的并行

    一定订单不仅会发生预订方式的穿行流转,还会出现并行,比如商家超时未处理订单,订单会流转进售中预订方式,这时候售中客服和商家可以同时处理。预订方式的并行还带来处理结果判定问题,因为多个预订方式会出现并发问题,而不同预订方式中的预订结果可能是相反的,如一个订单同时在商家接单模式和售中模式中时,如果两个渠道都是同意,则以最先结果为准,如果商家拒绝,该订单则会以售中客服处理的结果为准。

  • 各个预订方式有自定义的交互

    各个预订方式都有这自己复杂的交互方式:

  • 扩展性

    分析了这些需求,但还包含了很多隐含的需求。
    增加新的预订方式 :随着业务的发展可能会出现很多新的预订方式,比如可能出现打印机的预订方式等。
    预订方式定制化:各个预订方式之间的流转可能会有新的定制化,比如在商家接单方式中,可能一些商家在拒绝之后就不希望再流转到售中客服,也就是对于部分商家的订单,商家接单方式中拒绝之后就不再流转其他渠道。
    用户取消订单:现在已有的预订方式中,用户无法参与到流程中,但是预订流程较长,在后期可能会支持用户自己取消预订中的订单。

  • 稳定性

    一个订单经历的预订方式变多,对系统的稳定性要求也就更高,需要在预订方式内部流转时,和在多个预订方式流转时需要保证订单正确的流转。

3. 流程抽象及实现

在前面的分析中一直强调着预订方式的并行,提到并行,作为开发人员很容易想到计算机中并行的概念。在操作系统中进程线程都会出现并行,且进程之间会有进程通信,线程之间也有线程共享数据。
另外,预订方式的流转很容易让我们联想到unix命令的嵌套,比如tail -500f demo.txt|grep “test”,这就是进程之间数据流转。
借鉴Unix中进程的模型,我们将每个预订方式作为一个进程,进程内部处理自己的数据,当修改到订单预订状态时,就会有进程通信,这样模型就可以简化成下图:

这样每个预订方式都是一个预订渠道,都是一个处理订单的进程,预订渠道之间可以并行处理也可以串行处理,渠道之间通过消息进行通信;渠道将本渠道内部的状态流转及复杂交互都封装在内部,对外暴露的数据只有订单预订状态,这样各渠道之间交互就会变得简单,而且渠道内部也能将问题拆分的更细;渠道抽象也能够很好的支持渠道的增加和删除。

有了这个抽象我们在系统架构上采用这种模式:

在这个架构中有以下要点:

  • 预订渠道之间的通信是通过预订流程服务统一进行的,预订流程服务提供了消息总线的功能,这样在新增渠道的时候,只需要实现与预订流程服务之间的接口即可与其他渠道通信,在扩展时可以降低开发量;
  • 渠道服务解决了内部需求;
  • 预订流程服务中各个模块可以在未来作为微服务实现。

关于该架构的实现可以参照业务系统重构总结