CN111967628B - 订单服务方法及系统 - Google Patents

Abstract

公开了一种订单服务方法及系统。构造多个状态处理器，每个状态处理器对应一种订单状态转换模式，订单状态转换模式用于表征特定订单状态在特定订单事件参数下的订单状态转换，状态处理器用于实现订单状态转换需要执行的操作；根据当前订单状态和当前订单事件参数，从多个状态处理器中选择合适的状态处理器；基于选择的状态处理器执行与订单状态转换对应的操作。由此，通过将订单状态、事件、动作抽离出来，构造多个状态处理器，可以满足订单状态转换过程中多种订单处理逻辑，解决订单处理逻辑的差异化开需求，例如可以解决网约车多租户、多渠道接入、多车型等在差异化需求和场景下的开发诉求，同时可以使订单系统更加易于维护和扩展。

Description

订单服务方法及系统

技术领域

本公开涉及计算机技术领域，特别是涉及一种订单服务方法及系统。

背景技术

随着互联网通信和移动支付技术的普及与发展，传统的线下交易模式逐渐向线上交易模式演变。

线上交易模式存在订单状态多、交易链路长、流程复杂等特点，使得需要对不同订单状态的处理逻辑进行定制化开发，而这需要在代码开发过程中构造一系列条件语句(如if…else语句)以开发不同的订单处理逻辑，造成代码逻辑复杂、可读性低、维护成本高。

另外，SAAS平台多租户模式能够在数据隔离的基础上使多企业用户共用相同的系统架构和服务，但是针对不同企业用户的差异化需求也需要定制化设计和开发，而这也需要在代码开发过程中构造一系列条件语句检查租户ID以开发能够满足不同企业用户的差异化需求的订单处理逻辑，同样也会造成代码逻辑复杂、可读性低、维护成本高。

以网约车订单场景为例，不同渠道接入方、网约车业务线、车型会存在不同的业务发展方向和定制化需要。比如出租车打车通常是需要打表器打表计价，打车价格是受地方物价局监管的；而针对专车、快车计价可以通过互联网技术进行实时计算，根据不同的时间段、路况、起终点等会有不同的计价策略。这种差异性的处理逻辑同样需要定制化开发。

在需要开发多种订单处理逻辑，如需要对订单处理逻辑进行差异化开发时，如何避免出现大量条件语句，以使系统更加易于维护和扩展，是目前亟需解决的问题。

发明内容

本公开要解决的一个技术问题是提供一种能够在满足多种订单处理逻辑开发需求的同时更加易于维护和扩展的订单服务方案。

根据本公开的第一个方面，提供了一种订单服务方法，包括：构造多个状态处理器，每个状态处理器对应一种订单状态转换模式，订单状态转换模式用于表征特定订单状态在特定订单事件参数下的订单状态转换，状态处理器用于实现订单状态转换需要执行的操作；根据当前订单状态和当前订单事件参数，从多个状态处理器中选择合适的状态处理器；基于选择的状态处理器执行与订单状态转换对应的操作。

可选地，状态处理器包括注解组件，注解组件定义了状态处理器所对应的订单状态转换模式所表征的订单状态和订单事件参数。

可选地，从多个状态处理器中选择合适的状态处理器的步骤包括：从多个状态处理器中选择注解组件所定义的订单状态与当前订单状态一致，且注解组件所定义的订单事件参数与当前订单事件参数一致的状态处理器。

可选地，订单事件参数包括以下至少一项：事件类型参数；租户ID参数；渠道来源参数；车型字段参数；路况参数；时间参数；地理位置参数。

可选地，该订单服务方法还包括：构造抽象状态处理器，抽象状态处理器用于提供订单状态转换的通用处理逻辑，其中，基于选择的状态处理器执行与订单状态转换对应的操作的步骤包括：由选择的状态处理器根据当前订单事件参数，判断当前订单状态要转换的下一订单状态，并调用抽象状态处理器完成由当前订单状态到下一订单状态的转换。

可选地，基于选择的状态处理器执行与订单状态转换对应的操作的步骤包括：由选择的状态处理器执行第一操作；将用于表征待执行的第二操作的订单异步消息发送给异步事件处理器，由异步事件处理器执行第二操作，其中，第一操作为需要在订单状态转换过程中执行的操作，第二操作为能够与订单状态转换过程异步执行的操作。

可选地，将用于表征执行第二操作的订单异步消息发送给异步事件处理器的步骤包括：发布订单异步消息，异步事件处理器通过订阅获取订单异步消息。

根据本公开的第二个方面，提供了一种订单服务系统，包括：获取装置，用于从业务方获取当前订单状态和当前订单事件参数；查找装置，用于根据当前订单状态和当前订单事件参数，从预先构造的多个状态处理器中选择合适的状态处理器，其中，每个状态处理器对应一种订单状态转换模式，订单状态转换模式用于表征特定订单状态在特定订单事件参数下的订单状态转换，状态处理器用于实现订单状态转换需要执行的操作；执行装置，用于基于选择的状态处理器执行与订单状态转换对应的操作。

可选地，状态处理器包括注解组件，注解组件定义了状态处理器所对应的订单状态转换模式所表征的订单状态和特定订单事件参数，查找装置从多个状态处理器中选择注解组件所定义的订单状态与当前订单状态一致，且注解组件所定义的订单事件参数与当前订单事件参数一致的状态处理器。

根据本公开的第三个方面，提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行如上述第一方面的方法。

根据本公开的第四个方面，提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上述第一方面的方法。

由此，通过将订单状态、事件、动作抽离出来，构造多个状态处理器，可以满足订单状态转换过程中多种订单处理逻辑，解决订单处理逻辑的差异化开需求，例如可以解决网约车多租户、多渠道接入、多车型等在差异化需求和场景下的开发诉求，同时可以使订单系统更加易于维护和扩展。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示出了根据本公开一个实施例的订单服务方法的示意性流程图。

图2示出了根据本公开一个实施例的订单服务系统的结构框图。

图3示出了根据本公开一个实施例的计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本公开旨在将订单状态、事件、动作抽离出来，对复杂的订单状态流转进行统一管理，来取代大量的条件语句(如if…else逻辑)，优化订单系统，使订单系统在满足多种订单处理逻辑开发需求(如订单处理逻辑的差异化开发需求)的同时，更加易于维护和扩展。

订单状态(State)是指订单所处状态。以网约车订单场景为例，可以包括但不限于新创建订单、司机接单、到达乘客上车点、乘客已上车、开始行程、到达目的地、确认费用、支付费用等多种订单状态。

事件(Event)是指用于促使订单状态发生变化的操作和/或条件。

动作(Action)是指事件发生后要执行的动作，本公开中可以是指订单状态转换过程中需要执行的操作。

订单系统可以是利用多租户技术搭建的用于向多企业用户提供统一订单服务的系统，如可以是支持多租户模式的网约车SAAS平台。多租户技术是一种软件架构技术，是实现如何在面向多企业用户环境下共用相同的系统或程序组件，本公开述及的租户是指接入订单系统的各个企业用户。

以网约车订单场景为例，订单系统作为网约车系统的主要构成部分，可以提供标准的下单、订单状态流转、订单查询等接口，供外部网约车系统接入使用。

下面结合具体实施例就本公开涉及的细节做进一步说明。

图1示出了根据本公开一个实施例的订单服务方法的示意性流程图。图1所示的方法可部分或完全通过计算机程序以软件方式实现，还可通过特定配置的计算装置来执行图1所示的方法。作为示例，图1所示方法可以由为多企业用户提供订单服务的订单系统(如SAAS平台)执行。

参见图1，在步骤S110，构造多个状态处理器。

每个状态处理器对应一种订单状态转换模式，订单状态转换模式用于表征特定订单状态在特定订单事件参数下的订单状态转换，状态处理器用于实现订单状态转换需要执行的操作。

特定订单状态用于表征订单状态转换前的订单状态。特定订单事件参数用于表征促使订单状态发生变化的订单事件参数。作为示例，订单事件参数可以包括两部分：一部分是用于表征特定订单状态将转换为何种订单状态的事件参数，如事件类型参数；另一部分是能够用于表征订单状态转换所对应的订单处理逻辑的差异化定制需求的条件参数，如租户ID参数、渠道来源参数、车型字段参数、路况参数、时间参数、地理位置参数等。其中，订单处理逻辑用于表征随着订单状态转换需要执行的操作。

以网约车订单场景为例，有新创建订单、司机接单、到达乘客上车点、乘客已上车、开始行程、到达目的地、确认费用、支付费用等多种订单状态，每种订单状态的流转都有不同的流程，虽然有流程的差异，但是订单状态的流转又有着严格的限制，比如不能从新创建订单直接流转到支付费用状态，同样也不能从支付费用状态回退到确认费用状态。并且在利用SAAS平台为多租户(即多企业用户)提供共用系统架构和服务的情况下，不同的渠道接入方、网约车业务线、车型会存在不同的业务发展方向和定制化的需要。比如出租车打车通常是需要打表器打表计价，打车价格是受地方物价局监管的；而针对专车、快车计价可以通过互联网技术进行实时计算，根据不同的时间段、路况、起终点等会有不同的计价策略。

此时，订单事件参数既可以包括但不限于事件类型参数、租户ID参数、渠道来源参数、车型字段参数、路况参数、时间参数、地理位置参数等诸多参数中的一种或多种。其中，事件类型参数可以用于表征特定订单状态下乘客或司机通过客户端软件做出的事件的类型，事件类型参数可以用于指示订单状态流转的下一订单状态；租户ID参数可以用于标识接入SAAS平台的企业用户的身份；渠道来源参数可以是指流量输入方，如可以是指外部网约车系统接入使用的渠道类型；车型字段参数可以用于表征车辆车型；路况参数可以用于表征与订单行程对应的道路状况；时间参数可以用于表征时间点或时间段，如可以是乘客下单时间所对应的时间段；地理位置参数可以用于表征乘客上车位置、行程开始位置、目的地位置等。

状态处理器用于实现订单状态转换需要执行的操作，而订单状态转换需要执行的操作又依赖于订单状态转换所对应的订单处理逻辑。不同订单状态转换一般对应不同的订单处理逻辑，并且同一订单状态转换在不同订单事件参数(如不同车型、不同租户ID、不同时间段等)下可以对应不同的订单处理逻辑。

每个状态处理器能够实现特定订单状态在特定订单事件参数下的订单状态转换需要执行的操作。因此，每个状态处理器对应一种订单处理逻辑，多个状态处理器可以视为由抽离出的订单状态、事件、动作组成的一个订单状态机模型，该订单状态机模型可以表示有限个订单状态以及在这有限个订单状态之间进行状态转移和状态转移过程中需要执行的对应于不同订单处理逻辑的动作。

由此，通过将订单状态、事件、动作抽离出来，构造多个状态处理器，在满足订单状态转换过程中多种订单处理逻辑(如订单处理逻辑的差异化定制)开发需求的同时，可以使订单系统更加易于维护和扩展。例如，对于新的订单处理逻辑的定制需求，只需要设计新的状态处理器，而不需要对已有状态处理器进行改动；在需要对既有订单处理逻辑进行修改时，也只需要修改特定的状态处理器。

在步骤S120，根据当前订单状态和当前订单事件参数，从多个状态处理器中选择合适的状态处理器。

从多个状态处理器中选择合适的状态处理器，是指从多个状态处理器中选择能够实现当前订单状态在当前事件参数下的订单状态转换的状态处理器，也即能够实现当前订单状态在当前事件参数下进行订单状态转换需要执行的操作的状态处理器。

为了便于从多个状态处理器中查找合适的状态处理器，步骤S110所构造的状态处理器可以包括注解组件，注解组件定义了状态处理器所对应的订单状态转换模式所表征的订单状态和订单事件参数。如此在执行步骤S120时，可以从多个状态处理器中选择注解组件所定义的订单状态与当前订单状态一致，且注解组件所定义的订单事件参数与当前订单事件参数一致的状态处理器。

在步骤S130，基于选择的状态处理器执行与订单状态转换对应的操作。与订单状态转换对应的操作不仅可以包括状态转移操作，还可以包括状态转移过程中需要执行的其他操作，具体操作事项与业务处理逻辑相关。

作为示例，与订单状态转换对应的操作可以分为需要在订单状态转换过程中执行的操作(为了便于区分，可以称为第一操作)和能够与订单状态转换过程异步执行的操作(为了便于区分，可以称为第二操作)。第一操作例如可以是指必须在订单状态转换过程中成功的操作，第二操作例如可以是允许失败重试且对实时度要求不高的操作。

可以由选择的状态处理器执行第一操作；将用于表征执行第二操作的订单异步消息发送给异步事件处理器，由异步事件处理器执行第二操作，其中，可以通过发布/订阅的方式实现第二操作的执行，即可以发布订单异步消息，异步事件处理器可以通过订阅获取订单异步消息。

本公开还可以构造抽象状态处理器，抽象状态处理器用于提供订单状态转换的通用处理逻辑。例如，抽象状态处理器可以用于实现订单状态转换的主要步骤，如可以包括但不限于数据校验、数据处理、处理后需要执行的操作等。在执行步骤S130时，可以由选择的状态处理器根据当前订单事件参数，判断当前订单状态要转换的下一订单状态，并调用抽象状态处理器完成由当前订单状态到下一订单状态的转换。

由此，抽象状态处理器可以视为订单状态流程的模板，通过流程模板方式、在做订单状态流转业务过程分解的时候，开发人员只需要把精力放设计模式带来的灵活性上，多花时间在对问题分析，结构化分解，最后通过合理的抽象，形成合适的流程步骤上。

上文述及的状态处理器、注解组件、抽象状态处理器可以视为通过编程语言编写的用于实现特定功能的功能模块。下面就从程序设计角度就状态处理器的构造过程进行示例性说明。

针对每种订单状态转换模式可以抽取出一个StateProcessor类，StateProcessor类可以继承AbstractStateProcessor的实现。其中，StateProcessor类对应于上文述及的状态处理器，AbstractStateProcessor对应于上文述及的抽象状态处理器。

每个StateProcessor都有一个对应的继承StateContext类的上下文类和StateEvent事件对象，StateContext用于在状态流转中各方法中的通信，StateEvent用于不同状态流转的事件入参。StateProcessor能够实现transitionState方法，transitionState方法用于基于当前StateContext和StateEvent判断要流转的下一个订单状态类型。其中，当前StateContext能够表征当前订单状态，StateEvent能够表征当前订单事件参数。

AbstractStateProcessor实现StateActionStep接口，StateActionStep接口用于实现订单状态迁移的主要步骤，主要有check(数据校验)、process(数据处理)、after(处理后)等方法组成的业务模板方法。通过流程模板方式、在做订单状态流转业务过程分解的时候，开发人员只需要把精力放设计模式带来的灵活性上，多花时间在对问题分析，结构化分解，最后通过合理的抽象，形成合适的流程步骤(Step)上。

每个StateProcessor可以注册一个StateDefiner注解，StateDefiner中可以定义StateProcessor所关联的订单状态和订单事件参数，StateProcessor所关联的订单状态和订单事件参数，也即StateProcessor对应的订单状态转换模式所表征的订单状态和订单事件参数。例如，StateDefiner中可以定义但不限于订单状态、事件类型、租户ID、渠道来源、车型字段等。其中，StateDefiner对应于上文述及的注解组件。

每一次状态迁移(即状态转换)一般都会伴随着异步处理，因此可以把一个订单状态迁移流程中必须要成功的操作(即上文述及的第一操作)放到一个事务中，把允许失败重试并且对实时度要求不高的操作(即上文述及的第二操作)放到异步消息消费的流程中。可以通过使用EventPublisher(事件发布器)发送订单异步消息，业务消费方(对应于上文述及的异步事件处理器)通过监听异步消息来处理异步的业务流程。异步事件订阅者(也即业务消费方)可以注册一个StateMessageSubscriber注解，该注解中可以定义订单状态和订单事件参数。例如，可以定义订单状态、事件类型、租户ID、渠道来源、车型字段，其中，不同的字段组合可以多次消费一条消息从而实现差异化的业务开发定制。

可以抽象一个OrderFsmEngine类作为订单状态事件执行的入口，主要方法sendEvent通过接收一个StateEvent入参发起订单状态迁移业务，以执行上述订单服务方法中的步骤S120和步骤S130。

下面以下单为例就订单状态迁移业务的执行过程进行示例性说明。

首先启动系统，扫描系统中所有注解了StateDefiner的bean，以获取所有AbstractStateProcessor的实例，然后将所有AbstractStateProcessor的实例装载到以订单状态和订单事件参数为key，以AbstractStateProcessor实例为value的集合中。

下单业务类可以响应于客户端的下单操作，创建一个OrderStateEvent实例CreateEvent，调用OrderFsmEngine的sendEvent方法。OrderFsmEngine根据CreateEvent构建上下文对象StateContext。

根据StateContext中的当前订单状态和事件类型，可以从AbstractStateProcessor集合中选择出对应状态处理器集合，然后再根据租户ID、渠道和车型确认唯一状态处理器CreatedProcessor。

调用CreatedProcessor的模板入口方法action，action会依次执行check(数据校验)、process(数据处理)、after(处理后)完成订单状态迁移。对于异步处理操作，可以通过EventPublisher发送一个异步消息，、异步事件订阅者监听到消息后进行异步业务处理。

至此结合图1就本公开的订单服务方法做了示例性说明。本公开的订单服务方法可以应用于但不限于网约车订单场景。以应用于网约车场景为例，本公开通过结合订单状态机模型，对复杂的状态迁移逻辑进行统一管理，使网约车交易系统中的复杂问题得以解耦，使系统更加易于维护和管理。例如在有效解决网约车场景下多租户、多渠道、多车型在差异化需求场景下的开发诉求的同时，可以降低业务的复杂性。

本公开的订单服务方法还可以实现为一种订单服务系统。图2示出了根据本公开示例性实施例的订单服务系统的结构框图。其中，订单服务系统的功能单元可以由实现本公开原理的硬件、软件或硬件和软件的结合来实现。本领域技术人员可以理解的是，图2所描述的功能单元可以组合起来或者划分成子单元，从而实现上述发明的原理。因此，本文的描述可以支持对本文描述的功能单元的任何可能的组合、或者划分、或者更进一步的限定。

下面就订单服务系统可以具有的功能单元以及各功能单元可以执行的操作做简要说明，对于其中涉及的细节部分可以参见上文相关描述，这里不再赘述。

参见图2，订单服务系统200包括获取装置210、查找装置220以及执行装置230。

获取装置210用于从业务方获取当前订单状态和当前订单事件参数。

查找装置220用于根据当前订单状态和当前订单事件参数，从预先构造的多个状态处理器中选择合适的状态处理器，其中，每个状态处理器对应一种订单状态转换模式，订单状态转换模式用于表征特定订单状态在特定订单事件参数下的订单状态转换，状态处理器用于实现订单状态转换需要执行的操作。

执行装置230用于基于选择的状态处理器执行与订单状态转换对应的操作。

状态处理器可以包括注解组件，注解组件定义了状态处理器所对应的订单状态转换模式所表征的订单状态和特定订单事件参数，查找装置220可以从多个状态处理器中选择注解组件所定义的订单状态与当前订单状态一致，且注解组件所定义的订单事件参数与当前订单事件参数一致的状态处理器。

订单服务系统200还可以预先构造抽象状态处理器，抽象状态处理器用于提供订单状态转换的通用处理逻辑，执行装置230可以调用选择的状态处理器根据当前订单事件参数，判断当前订单状态要转换的下一订单状态，并调用抽象状态处理器完成由当前订单状态到下一订单状态的转换。

作为示例，与订单状态转换对应的操作可以分为需要在订单状态转换过程中执行的操作(为了便于区分，可以称为第一操作)和能够与订单状态转换过程异步执行的操作(为了便于区分，可以称为第二操作)。执行装置230可以调用选择的状态处理器执行第一操作；将用于表征待执行的第二操作的订单异步消息发送给异步事件处理器，由所述异步事件处理器执行所述第二操作。

图3示出了根据本发明一实施例可用于实现上述订单服务方法的计算设备的结构示意图。

参见图3，计算设备300包括存储器310和处理器320。

处理器320可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器320可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器320可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器310可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器320或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器310可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器310可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器310上存储有可执行代码，当可执行代码被处理器320处理时，可以使处理器320执行上文述及的订单服务方法。

上文中已经参考附图详细描述了根据本发明的订单服务方法、订单服务系统及计算设备。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (11)

1.一种订单服务方法，用于向多企业用户提供订单服务，该方法包括：

构造多个状态处理器，每个所述状态处理器对应一种订单状态转换模式，所述订单状态转换模式用于表征特定订单状态在特定订单事件参数下的订单状态转换，所述状态处理器用于实现订单状态转换需要执行的操作，订单状态转换需要执行的操作依赖于订单状态转换所对应的订单处理逻辑，所述订单事件参数包括用于表征特定订单状态将转换为何种订单状态的事件参数和用于表征订单状态转换所对应的订单处理逻辑的差异化定制需求的条件参数；

根据当前订单状态和当前订单事件参数，从所述多个状态处理器中选择合适的状态处理器；

基于选择的状态处理器执行与订单状态转换对应的操作。

2.根据权利要求1所述的订单服务方法，其中，

所述状态处理器包括注解组件，所述注解组件定义了所述状态处理器所对应的订单状态转换模式所表征的订单状态和订单事件参数。

3.根据权利要求2所述的订单服务方法，其中，从所述多个状态处理器中选择合适的状态处理器的步骤包括：

从所述多个状态处理器中选择注解组件所定义的订单状态与当前订单状态一致，且注解组件所定义的订单事件参数与当前订单事件参数一致的状态处理器。

4.根据权利要求2所述的订单服务方法，其中，

所述事件参数包括事件类型参数，

所述条件参数包括以下至少一项：租户ID参数；渠道来源参数；车型字段参数；路况参数；时间参数；地理位置参数。

5.根据权利要求1所述的订单服务方法，还包括：

构造抽象状态处理器，所述抽象状态处理器用于提供订单状态转换的通用处理逻辑，其中，

基于选择的状态处理器执行与订单状态转换对应的操作的步骤包括：由选择的状态处理器根据所述当前订单事件参数，判断当前订单状态要转换的下一订单状态，并调用所述抽象状态处理器完成由当前订单状态到下一订单状态的转换。

6.根据权利要求1所述的订单服务方法，其中，基于选择的状态处理器执行与订单状态转换对应的操作的步骤包括：

由选择的状态处理器执行第一操作；

将用于表征待执行的第二操作的订单异步消息发送给异步事件处理器，由所述异步事件处理器执行所述第二操作，其中，所述第一操作为需要在订单状态转换过程中执行的操作，所述第二操作为能够与订单状态转换过程异步执行的操作。

7.根据权利要求6所述的订单服务方法，其中，将用于表征执行第二操作的订单异步消息发送给异步事件处理器的步骤包括：

发布所述订单异步消息，所述异步事件处理器通过订阅获取所述订单异步消息。

8.一种订单服务系统，用于向多企业用户提供订单服务，该系统包括：

获取装置，用于从业务方获取当前订单状态和当前订单事件参数，所述订单事件参数包括用于表征特定订单状态将转换为何种订单状态的事件参数和用于表征订单状态转换所对应的订单处理逻辑的差异化定制需求的条件参数，订单状态转换需要执行的操作依赖于订单状态转换所对应的订单处理逻辑；

查找装置，用于根据所述当前订单状态和所述当前订单事件参数，从预先构造的多个状态处理器中选择合适的状态处理器，其中，每个所述状态处理器对应一种订单状态转换模式，所述订单状态转换模式用于表征特定订单状态在特定订单事件参数下的订单状态转换，所述状态处理器用于实现订单状态转换需要执行的操作；

执行装置，用于基于选择的状态处理器执行与订单状态转换对应的操作。

9.根据权利要求8所述的订单服务系统，其中，

所述状态处理器包括注解组件，所述注解组件定义了所述状态处理器所对应的订单状态转换模式所表征的订单状态和特定订单事件参数，

所述查找装置从所述多个状态处理器中选择注解组件所定义的订单状态与当前订单状态一致，且注解组件所定义的订单事件参数与当前订单事件参数一致的状态处理器。

10.一种计算设备，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1至7中任何一项所述的方法。

11.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1至7中任何一项所述的方法。

Images