CN114240269A - 兼容多种业务流程的微服务系统和兼容管理方法 - Google Patents

Abstract

本申请涉及一种兼容多种业务流程的微服务系统和一种基于微服务系统的多种业务流程的兼容管理方法，该微服务系统包括至少一个订单通用流程模块、至少一个订单定制流程插件和订单插件管理平台，各订单通用流程模块为面向至少两个业务场景的基于通用业务流程构建的订单流程模块，各订单定制流程插件为面向特定业务场景的基于对应的订单通用流程模块构建的订单流程插件，该订单插件管理平台用于记录各订单通用流程模块和各订单定制流程插件的运行状态信息。从而多个系统中相似的部分共用，节约资源，简化多个对象的操作。

Description

兼容多种业务流程的微服务系统和兼容管理方法

技术领域

本申请涉及微服务技术领域，特别是涉及一种兼容多种业务流程的微服务系统和一种基于微服务系统的多种业务流程的兼容管理方法。

背景技术

运输行业由于其运输工具、承载货物、交付方式等区别，在不同的场景下有不同的业务流程。现有技术中，会针对不同的场景开发独立的系统各自运行以满足各自的业务流。例如，某无车承运人承接新车送货业务的场景下，系统对订单和司机进行匹配后，司机经过取车、短泊、办理临牌、在途运输、交付等环节完成运单任务；某矿业运输管理系统基于产量信息匹配货物和报名车队运力，报名车队基于运输管理系统指令匹配货物，在途运输货物完成运单。两套系统存在一些相似点，但又有角度不同处，现有技术需要研发两套独立的系统分别满足各自的需求，分别运维。

因此，现有技术中存在着多个系统中相似的部分无法共用，造成开发、运维资源浪费的问题；系统运营人员、财务人员、司机面对多个系统带来操作繁琐的问题。

发明内容

基于此，有必要针对上述技术问题，提供一种使得多个系统中相似的部分共用，节约资源，简化多个对象的操作的一种兼容多种业务流程的微服务系统、兼容多种业务流程的微服务系统的构建方法、基于微服务架构的多种业务流程的兼容管理方法、计算机设备和计算机可读存储介质。

一种兼容多种业务流程的微服务系统，所述微服务系统包括至少一个订单通用流程模块、至少一个订单定制流程插件和订单插件管理平台；

各订单通用流程模块为面向至少两个业务场景的基于通用业务流程构建的订单流程模块；

各订单定制流程插件为面向特定业务场景的基于对应的订单通用流程模块构建的订单流程插件；

所述订单插件管理平台用于记录各订单通用流程模块和各订单定制流程插件的运行状态信息。

在其中一个实施例中，所述微服务系统还包括注册中心，所述注册中心用于供各订单通用流程模块和各订单定制流程插件进行注册；

所述订单插件管理平台设置为能够获取各订单通用流程模块和各订单定制流程插件注册后的地址和名称。

在其中一个实施例中，各订单通用流程模块包括订单通用流程模型，各订单定制流程插件包括订单定制流程模型；

所述微服务系统还包括前端展示模块，所述前端展示模块设置有多个页面，各页面设置为能够调用对应订单通用流程模块中的订单通用流程模型和对应订单定制流程插件中的订单定制流程模型，以使对应的订单通用流程模型和订单定制流程模型拼接在一起并展示在当前页面中。

在其中一个实施例中，所述订单通用流程模型包括产品ID信息、当前归属人信息、订单业务流程状态信息。

在其中一个实施例中，所述订单业务流程状态包括：待分配状态、待发车状态、运输中状态、已交付状态、已结算状态。

在其中一个实施例中，所述订单定制流程模型为停车场排队流程模型、临牌办理流程模型、一级审核流程模型、二级审核流程模型、待收车等状态流程模型和状态变更流程模型中的一种。

在其中一个实施例中，各订单通用流程模块还包括订单通用信息录入读取接口，各订单定制流程插件包括订单定制信息录入读取接口；

所述订单通用信息录入读取接口和所述订单定制信息录入读取接口设置为能够与对应的页面连接以调用对应订单通用流程模块中的订单通用流程模型和对应订单定制流程插件中的订单定制流程模型。

在其中一个实施例中，所述订单通用信息录入读取接口包括基于权限和订单通用业务流程的订单数据读写接口、单一查询接口、批量查询接口、聚合计算汇总接口中的至少之一。

一种兼容多种业务流程的微服务系统的构建方法，所述构建方法包括：

将不同业务场景中的通用业务流程分离出来，并由所述通用业务流程构建出订单通用流程模块；

将各业务场景中的特定业务流程分离出来，并在订单通用流程模块的基础上、由所述特定业务流程构建出各业务场景中的订单定制流程插件；

提供所述订单插件管理平台，并在所述订单插件管理平台上运行各订单定制流程插件和对应的订单通用流程模块。

一种基于微服务架构的多种业务流程的兼容管理方法，所述兼容管理方法包括：

接收用户针对业务场景发出的业务请求；

调用与该业务场景对应的订单通用流程模块和订单定制流程插件；

在所述订单插件管理平台上运行订单通用流程模块中的通用流程和订单定制流程插件中的定制流程。

一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

接收用户针对业务场景发出的业务请求；

调用与该业务场景对应的订单通用流程模块和订单定制流程插件；

在所述订单插件管理平台上运行订单通用流程模块中的通用流程和订单定制流程插件中的定制流程。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

接收用户针对业务场景发出的业务请求；

调用与该业务场景对应的订单通用流程模块和订单定制流程插件；

在所述订单插件管理平台上运行订单通用流程模块中的通用流程和订单定制流程插件中的定制流程。

上述兼容多种业务流程的微服务系统，该微服务系统包括至少一个订单通用流程模块、至少一个订单定制流程插件和订单插件管理平台，各订单通用流程模块为面向至少两个业务场景的基于通用业务流程构建的订单流程模块，各订单定制流程插件为面向特定业务场景的基于对应的订单通用流程模块构建的订单流程插件，该订单插件管理平台用于记录各订单通用流程模块和各订单定制流程插件的运行状态信息。其中，将不同业务场景中的通用业务流程分离出来，并由通用业务流程构建出订单通用流程模块，从而多个系统中相似的部分共用，节约资源；将各业务场景中的特定业务流程分离出来，并在订单通用流程模块的基础上，由特定业务流程构建出各业务场景中的订单定制流程插件，解决了多个系统中数据相互隔离，难以基于打通的数据进行数据分析、建模、统计、挖掘形成数据智能的问题；解决了系统运营人员、财务人员、司机面对多个系统带来操作繁琐的问题，简化多个对象的操作；此外，将来新的业务场景出现时，仍能够复用现有的订单通用流程模块，并基于新的业务场景的流程，基于订单通用流程模块继续宁构建，实现新的业务，解决了架构体系难以演进的问题。

附图说明

图1为一个实施例中兼容多种业务流程的微服务系统的结构框图；

图2为一个实施例中基础领域模型所使用的架构设计的示意图；

图3为一个实施例中导航和路径规划、订单匹配算法、排队管理算法等工具类服务采用的架构设计的示意图；

图4为一个实施例中兼容多种业务流程的微服务系统的结构框图；

图5为一个实施例中兼容多种业务流程的微服务系统的结构框图；

图6为一个实施例中一种基于微服务系统的多种业务流程的兼容管理方法的流程示意图；

图7为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在一个实施例中，如图1所示，提供了一种兼容多种业务流程的微服务系统，其特征在于，所述微服务系统包括至少一个订单通用流程模块、至少一个订单定制流程插件和订单插件管理平台；

各订单通用流程模块为面向至少两个业务场景的基于通用业务流程构建的订单流程模块；

各订单定制流程插件为面向特定业务场景的基于对应的订单通用流程模块构建的订单流程插件；

所述订单插件管理平台用于记录各订单通用流程模块和各订单定制流程插件的运行状态信息。

其中，将所有场景下的共性的部分抽象成服务，形成微服务系统。微服务系统包括至少一个订单通用流程模块、至少一个订单定制流程插件和订单插件管理平台。

传统的关于订单和产品的微服务会基于特定的场景进行开发定制，针对特定业务流程中需要添加的状态。例如，停车场排队中、临牌办理中、一级审核、二级审核、待收车等状态和状态变更后应进行的处理，在传统方法中会写入订单模块，但在本申请中，会以订单流程插件的形式按照统一设计的模板和接入点函数进行开发。微服务系统执行订单定制流程插件中预设的方法，以满足具体业务需求。

其中，接入点函数表示需要子类继承并定义具体行为的函数在RequestHandler中被称为接入点函数(Entrypoint)。

在本发明实施例中，构建基于通用业务流程构建的订单通用流程模块，基于订单通用流程模块构建基于特定业务场景的订单定制流程插件，把订单中通用逻辑和定制化逻辑分开，可以面向不同的业务逻辑提供基础的通用订单服务，从而多个系统中相似的部分共用，节约资源；将各业务场景中的特定业务流程分离出来，并在订单通用流程模块的基础上，由特定业务流程构建出各业务场景中的订单定制流程插件，解决了多个系统中数据相互隔离，难以基于打通的数据进行数据分析、建模、统计、挖掘形成数据智能的问题；解决了系统运营人员、财务人员、司机面对多个系统带来操作繁琐的问题，简化多个对象的操作；此外，将来新的业务场景出现时，仍能够复用现有的订单通用流程模块，并基于新的业务场景的流程，基于订单通用流程模块继续宁构建，实现新的业务，解决了架构体系难以演进的问题。

可选地，所述微服务系统还包括注册中心，所述注册中心用于供各订单通用流程模块和各订单定制流程插件进行注册；

所述订单插件管理平台设置为能够获取各订单通用流程模块和各订单定制流程插件注册后的地址和名称。

可选地，各订单通用流程模块包括订单通用流程模型，各订单定制流程插件包括订单定制流程模型；所述订单定制流程模型为停车场排队流程模型、临牌办理流程模型、一级审核流程模型、二级审核流程模型、待收车等状态流程模型和状态变更流程模型中的一种。

传统的关于订单和产品的微服务会基于特定的场景进行开发定制，针对特定业务流程中需要添加的状态。例如，停车场排队中、临牌办理中、一级审核、二级审核、待收车等状态和状态变更后应进行的处理，在传统方法中会写入订单模块，但在本申请中，会以订单流程插件的形式按照统一设计的模板和接入点函数进行开发。微服务系统执行订单定制流程插件中预设的方法，以满足具体业务需求。

所述微服务系统还包括前端展示模块，所述前端展示模块设置有多个页面，各页面设置为能够调用对应订单通用流程模块中的订单通用流程模型和对应订单定制流程插件中的订单定制流程模型，以使对应的订单通用流程模型和订单定制流程模型拼接在一起并展示在当前页面中。

在本发明实施例中，微服务系统包括基础领域模型，基础领域模型包括至少一个订单通用流程模型。

其中，基础领域模型包括司机、企业、支付和流水、产品、财务、工作流等基础领域模型，每个领域针对自身抽象进行建模，实现从微服务注册到注册中心，纳入到搭建好的微服务框架体系中。

其中，注册中心主要涉及到三大角色：服务提供者、服务消费者、注册中心。它们之间的关系如下：各个微服务在启动时，将自己的网络地址等信息注册到注册中心，注册中心存储这些数据。服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。各个微服务与注册中心使用一定机制(例如心跳)通信。

针对基础领域模型的建模，在面向实际运输业务时，有两种方式进行设计开发。一种是面向业务流程，把业务流程上所有相关数据和状态通过代码落地到系统中，在这一过程中归类设计表结构和相应的业务逻辑模块。第二种是在实际设计业务流程前，首先对参与业务的独立实体进行建模，不考虑具体的业务场景和在具体业务场景下的逻辑开发，然后针对每一个独立实体领域开发自身内部的业务逻辑和对外提供的服务。

其中，针对司机的基础领域模型可称之为C类用户基础领域模型包括：登录认证信息，C类用户基本信息，生态等级权益信息，钱包银行卡和余额。C类用户基础领域模型提供通过用户名、id的单用户信息查询接口，自带权限范围控制的数据录入审核管理接口。针对企业的基础领域模型可称之为B类用户基础领域模型包括企业基本信息、联系信息，企业账户和财务相关信息，企业资质证照信息，企业合作模式和业务规则信息，从本系统的角度记录企业余额、评级、分类信息。B类用户基础领域模型提供通过企业名称、id的信息查询接口，自带权限范围控制的数据录入审核管理接口。针对支付和流水的基础领域模型包括统一支付记录，提供对接各支付渠道提供支付接口，调用后保存支付流水数据和状态并提供数据和状态更新接口，基本的查询、组合查询、归类聚集计算能力接口。针对财务的基础领域模型包括不同角色的财务权限控制信息，工作流节点信息，提供财务流程业务接口，工作流引擎接口，相关财务数据计算和查询接口。针对车辆模块的基础领域模型包括车辆基本信息，车况信息，车辆归属信息；提供车辆信息查询、车辆归类分析接口。

其中，基于司机基础领域模型设计内部数据组成结构和对外接口服务如表1所示。

表1

基于企业/组织基础领域模型设计内部数据组成结构和对外接口服务如表2所示。

表2

基于车辆基础领域模型设计内部数据组成结构和对外接口服务如表3所示。

表3

其中，以上模型使用如2所示的架构设计，每个微服务具有独立的数据层，包括库数据和缓存，基于数据层抽象通过业务逻辑层最终对外提供查询、插入、修改、聚合、分析服务等等。

基于支付和流水基础领域模型设计内部数据组成结构和对外接口服务如表3所示。

表4

针对司机、企业、财务、订单流程等进行数据库设计，在数据库基础上进行模块化开发，针对不同的业务形态完成业务流程可以满足业务发展要求。例如，订单流程包括了订单分发、办理临牌、扫码发车、在途运输、交车、等待打款等流程。传统的方式创建符合业务场景的订单模块，包含以上各个节点的所有状态，当状态发生变更时，修改相应的司机、财务相关模块中的数据，形成一套完整的系统。该系统可以符合某个项目的需求，但是系统中涉及的司机、企业、车辆、订单等模块是为该场景定制的，难以用在其他类似项目，且模块是基于数据库和方法调用连接在一起的，在新的场景中需要重新设计数据库和业务模块并独立开发。传统的方式面对类似的多个业务需要开发多套独立的系统。在本发明中采用上述方式构建基础领域模型，这部分开发不进行多个模块之间功能的串联，只单独开发模块自身逻辑和模块对外提供的服务，优点是实现该领域固有的特点，而不为了具体业务流程进行开发，以便于将来新的业务场景出现时，仍能够复用现有模型提供的服务并基于该服务组装实现。

可选地，除了以上领域，系统中还包括了导航和路径规划、订单匹配算法、排队管理算法等工具，整个运输服务中台(即订单通用流程模型和微服务系统)可以不断新增工具和算法，上层业务流程就是对底层领域服务和工具服务的组装。以上构成了运输服务中台，某个具体业务就是基于运输服务中台提供的服务进行组装成业务服务，前端页面提供与用户交互界面调用组装好的业务服务完成所需功能。

其中，基于导航和路线规划基础领域模型设计内部数据组成结构和对外接口服务如表5所示。

表5

其中，以上导航和路径规划、订单匹配算法、排队管理算法等工具类服务采用如图3所示的设计，数据存储抽象层即为所有场景下的共性的部分抽象成服务，对外服务接口为上述描述到的信息查询接口、数据录入审核管理接口、id的信息查询接口、状态更新接口等等。

可选地，所述订单通用流程模型包括产品ID信息、当前归属人信息、订单业务流程状态信息。

可选地，所述订单业务流程状态包括：待分配状态、待发车状态、运输中状态、已交付状态、已结算状态。

可选地，各订单通用流程模块还包括订单通用信息录入读取接口，各订单定制流程插件包括订单定制信息录入读取接口；

所述订单通用信息录入读取接口和所述订单定制信息录入读取接口设置为能够与对应的页面连接以调用对应订单通用流程模块中的订单通用流程模型和对应订单定制流程插件中的订单定制流程模型。

可选地，所述订单定制信息录入读取接口包括基于权限和订单定制业务流程的订单数据读写接口、单一查询接口、批量查询接口、聚合计算汇总接口中的至少之一。

其中，订单通用信息录入读取接口用于对接订单归属企业接口、订单相关变更日志接口、订单相关财务和支付状态接口、订单完成状态接口、以及基于以上关于财务、状态、发单人、司机等信息的聚合信息，聚合信息包括总计数量、均价、最大最小等等。

其中，订单定制信息录入读取接口用于对接地跑相关业务和停车排队相关业务。其中，地跑相关业务包括：订单临牌办理接口、订单背车信息接口、订单短驳信息接口、订单归属车队信息接口、以及基于以上地跑业务场景相关信息的聚合信息(例如，某个车队当前订单总数，历史订单总数等)。停车排队相关业务包括：订单停车场归属接口、订单停车状态接口、订单排队排号接口、以及基于以上停车场排队业务场景相关信息的聚合信息(例如，某个停车场当前订单数量，平均停车时长等)。

在本发明实施例中，某个订单生成时设定了该订单所属的订单定制流程插件，该订单定制流程插件对应的特定订单数据被订单插件管理平台进行管理，订单定制流程插件中设置了插件触发条件，当订单进入基础状态中的某个状态时，触发预设的插件触发条件，将触发后执行的特定订单数据插入到所述微服务系统，并由微服务系统执行订单定制流程插件中预设的方法，以满足具体业务需求。例如，针对特定系统和场景的订单数据(订单状态、相关产品)、针对特定系统和场景的产品数据(主机厂的发运新车、煤、其他货物等)、针对特定系统和场景的产品订单业务刘晨规则数据(相关业务权限数据)，均可作为特定订单数据插入到微服务系统。

可选地，所述微服务系统还包括注册中心、配置中心、API网关、负载均衡器。

其中，注册中心、配置中心、API网关、负载均衡器等是微服务系统的基本技术架构。当前可选的微服务系统包括基于spring cloud的微服务系统，基于dubbo的微服务系统，基于istio的微服务系统。

其中，以微服务的方式组织实现运输服务中台，各服务注册到注册中心，服务之间、前后端之间基于服务名称通过注册中心查找对应服务，无需知道服务实际运行实例地址。各微服务本身可以根据不同开发人员选择不同开发语言，各服务独立运维，独立扩容。

在本发明实施例中，在使用本发明前原有两套系统分别开发，每个系统间共用0％的代码，各自需要10人的后台团队进行开发。采用本发明的方法重构后，15人团队可以完成持续迭代开发，其中通用中台代码9万行，定制化插件代码2万行，复用代码占比82％，如果出现新的业务场景进行开发，那么代码复用带来的资源节省还会增加。

原有两套系统无法打通数据，造成同一个自然人用户在两套系统间要各自登陆，某些功能例如司机历史积分、司机等级、司机评分等无法在多个系统间共享。通过新的方法重构运输中台后，可以形成系统间个人历史数据、财务钱包等通用，从形成多个不同业务场景下用户体系联合的效果。

不同业务场景下的运输系统有相似性，有各异性，把相同的部分剥离出来为不同系统提供服务是基本思想，在这一个过程中公用的部分节省了资源，但同时对公用部分的设计开发质量、高并发能力、可演进性提出了更高的要求，所以当公用带来的成本节省大于共用部分优化和提供插件化各异功能插入系统的开发成本时，使用本发明中采用的方法是有益的。运输系统可共用内容多，不同流程的场景多，且现有场景未来存在多变的可能，当具体场景数大于等于2时可以认为应采用本发明中的方法。

在本发明实施例中，如图4所示的微服务系统，基于微服务系统针对特定场景开发可插入式插件插入微服务系统(即图4中的订单插件扩展平台)，把订单中通用逻辑(即基础订单业务逻辑)和定制化逻辑分开，订单数据抽象层即为所有场景下的共性的部分抽象成服务，对外服务接口为上述描述到的信息查询接口、数据录入审核管理接口、id的信息查询接口、状态更新接口等等。项目1订单插件和项目2订单插件为定制化逻辑，可插入订单插件扩展平台。通过上述架构，将不同业务场景中的通用业务流程分离出来，并由通用业务流程构建出订单通用流程模块，从而多个系统中相似的部分共用，节约资源；将各业务场景中的特定业务流程分离出来，并在订单通用流程模块的基础上，由特定业务流程构建出各业务场景中的订单定制流程插件，解决了多个系统中数据相互隔离，难以基于打通的数据进行数据分析、建模、统计、挖掘形成数据智能的问题；解决了系统运营人员、财务人员、司机面对多个系统带来操作繁琐的问题，简化多个对象的操作；此外，将来新的业务场景出现时，仍能够复用现有的订单通用流程模块，并基于新的业务场景的流程，基于订单通用流程模块继续宁构建，实现新的业务，解决了架构体系难以演进的问题。

在本发明实施例中，微服务的核心特征是把原来适应不同场景的订单拆分成基础订单和场景定制化订单，基础订单主要包含订单权责付款信息，定制化订单包含在具体业务场景下对订单过程和货物的深度管理运营相关信息。通过插件的方式让不同场景下的订单插件通过统一的方式被管理。运输中台提供基础订单数据和服务，在每个特定项目下按照微服务系统提供的模板开发订单插件，从而把系统核心的订单流程一部分进行通用化，每个项目中定制化订单插件的工作量和代码量和通用的基础订单代码量约为3：2(基于不同项目的复杂度有差异)。基础订单部分分离出去后，财务审批、订单付款等和深度业务逻辑不相关环节的服务在不需要修改的情况下可以复用。

在本发明实施例中，如图5所示，为一种兼容多种业务流程的微服务系统的示意图，附图中的内容均在上述各个实施例中有所描述，此处不再加以赘述。

上述兼容多种业务流程的微服务系统中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种兼容多种业务流程的微服务系统的构建方法，所述构建方法包括：

将不同业务场景中的通用业务流程分离出来，并由所述通用业务流程构建出订单通用流程模块；

将各业务场景中的特定业务流程分离出来，并在订单通用流程模块的基础上、由所述特定业务流程构建出各业务场景中的订单定制流程插件；

提供所述订单插件管理平台，并在所述订单插件管理平台上运行各订单定制流程插件和对应的订单通用流程模块。

在一个实施例中，提供了一种基于微服务架构的多种业务流程的兼容管理方法，所述方法包括：

接收用户针对业务场景发出的业务请求；

调用与该业务场景对应的订单通用流程模块和订单定制流程插件；

在所述订单插件管理平台上运行订单通用流程模块中的通用流程和订单定制流程插件中的定制流程。

其中，关于兼容多种业务流程的微服务系统的构建方法和基于微服务架构的多种业务流程的兼容管理方法的具体限定，可以参见上文中对于兼容多种业务流程的微服务系统的限定，在此不再赘述。

在本申请实施例中，如图6所示的一种基于微服务系统的多种业务流程的兼容管理方法的流程示意图，注册中心：基于微服务的中台设计的寻址核心是注册中心，任何微服务包括基础订单服务和扩展订单服务都注册到注册中心。插件id：订单提供一个统一的服务接口面向所有场景，扩展插件可以有多个，基础订单服务只有一个，不同的扩展订单微服务使用不同的插件id。统一订单服务：基础订单服务和各个插件整合在一起提供统一的订单服务，所有服务都包含插件id作为一个参数，如果没有这个参数则只使用基础服务，不匹配相应插件。插件插入和工作过程：统一订单服务分为读和写两类，订单插件把自己的插件id注册到插件读操作触发器和扩展写入触发器，基础订单服务进行读写时由触发器基于插件id从注册中心获取相应微服务地址调用对应微服务。读操作触发器调用订单插件服务，传入从基础订单插件中获取的订单id或id列表，首先进入订单插件触发过滤器，过滤器基于id或其他条件判断是否触发订单插件增强，如果通过了则使用扩展订单抽象层获取扩展的订单数据返回给数据拼接器。数据拼接器把基础订单和插件扩展的数据基于id拼接到一起返回，从而提供统一的可分场景的订单查询服务。扩展写触发器通过基础订单数据抽象成对数据进行插入修改后返回插入或修改的id或id列表以及插入或修改的属性共同作为参数调用订单插件服务。订单插件过滤器基于写入操作的属性和返回的id或id列表判断是否触发订单插件写入。例如，基础订单状态完成时，订单插件的交车状态应为已交车，那么订单插件触发过滤器则根据订单写入的状态为完成进行相关触发，通过扩展订单数据抽象层把需要更新的数据更新到扩展订单的数据库或缓存中。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种快递单打印方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等，还可以是接口，与外部装置相连接，将外部装置发送的数据发送至计算机的处理器等。

本领域技术人员可以理解，图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

构建微服务系统，所述微服务系统包括订单模块；所述订单模块包括订单通用流程模型、微服务系统和业务模型；

将不同业务场景中的通用业务流程分离出来，并由所述通用业务流程构建出订单通用流程模块；

将各业务场景中的特定业务流程分离出来，并在订单通用流程模块的基础上、由所述特定业务流程构建出各业务场景中的订单定制流程插件；

提供所述订单插件管理平台，并在所述订单插件管理平台上运行各订单定制流程插件和对应的订单通用流程模块。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

接收用户针对业务场景发出的业务请求；

调用与该业务场景对应的订单通用流程模块和订单定制流程插件；

在所述订单插件管理平台上运行订单通用流程模块中的通用流程和订单定制流程插件中的定制流程。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

将不同业务场景中的通用业务流程分离出来，并由所述通用业务流程构建出订单通用流程模块；

将各业务场景中的特定业务流程分离出来，并在订单通用流程模块的基础上、由所述特定业务流程构建出各业务场景中的订单定制流程插件；

提供所述订单插件管理平台，并在所述订单插件管理平台上运行各订单定制流程插件和对应的订单通用流程模块。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

接收用户针对业务场景发出的业务请求；

调用与该业务场景对应的订单通用流程模块和订单定制流程插件；

在所述订单插件管理平台上运行订单通用流程模块中的通用流程和订单定制流程插件中的定制流程。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种兼容多种业务流程的微服务系统，其特征在于，所述微服务系统包括至少一个订单通用流程模块、至少一个订单定制流程插件和订单插件管理平台；

各订单通用流程模块为面向至少两个业务场景的基于通用业务流程构建的订单流程模块；

各订单定制流程插件为面向特定业务场景的基于对应的订单通用流程模块构建的订单流程插件；

所述订单插件管理平台用于记录各订单通用流程模块和各订单定制流程插件的运行状态信息。

2.根据权利要求1所述的兼容多种业务流程的微服务系统，其特征在于，

所述微服务系统还包括注册中心，所述注册中心用于供各订单通用流程模块和各订单定制流程插件进行注册；

所述订单插件管理平台设置为能够获取各订单通用流程模块和各订单定制流程插件注册后的地址和名称。

3.根据权利要求1所述的兼容多种业务流程的微服务系统，其特征在于，

各订单通用流程模块包括订单通用流程模型，各订单定制流程插件包括订单定制流程模型；

所述微服务系统还包括前端展示模块，所述前端展示模块设置有多个页面，各页面设置为能够调用对应订单通用流程模块中的订单通用流程模型和对应订单定制流程插件中的订单定制流程模型，以使对应的订单通用流程模型和订单定制流程模型拼接在一起并展示在当前页面中。

4.根据权利要求3所述的兼容多种业务流程的微服务系统，其特征在于，所述订单通用流程模型包括产品ID信息、当前归属人信息、订单业务流程状态信息。

5.根据权利要求3所述的兼容多种业务流程的微服务系统，其特征在于，所述订单定制流程模型为停车场排队流程模型、临牌办理流程模型、一级审核流程模型、二级审核流程模型、待收车等状态流程模型和状态变更流程模型中的一种。

6.根据权利要求3所述的兼容多种业务流程的微服务系统，其特征在于，

各订单通用流程模块还包括订单通用信息录入读取接口，各订单定制流程插件包括订单定制信息录入读取接口；

所述订单通用信息录入读取接口和所述订单定制信息录入读取接口设置为能够与对应的页面连接以调用对应订单通用流程模块中的订单通用流程模型和对应订单定制流程插件中的订单定制流程模型。

7.根据权利要求6所述的兼容多种业务流程的微服务系统，其特征在于，所述订单通用信息录入读取接口包括基于权限和订单通用业务流程的订单数据读写接口、单一查询接口、批量查询接口、聚合计算汇总接口中的至少之一。

8.根据权利要求6所述的兼容多种业务流程的微服务系统，其特征在于，所述订单定制信息录入读取接口包括基于权限和订单定制业务流程的订单数据读写接口、单一查询接口、批量查询接口、聚合计算汇总接口中的至少之一。

9.一种兼容多种业务流程的微服务系统的构建方法，所述构建方法用于构建权利要求1-8中任一项所述的兼容多种业务流程的微服务系统，其特征在于，所述构建方法包括：

将不同业务场景中的通用业务流程分离出来，并由所述通用业务流程构建出订单通用流程模块；

将各业务场景中的特定业务流程分离出来，并在订单通用流程模块的基础上、由所述特定业务流程构建出各业务场景中的订单定制流程插件；

提供所述订单插件管理平台，并在所述订单插件管理平台上运行各订单定制流程插件和对应的订单通用流程模块。

10.一种基于微服务架构的多种业务流程的兼容管理方法，其特征在于，所述兼容管理方法包括：

接收用户针对业务场景发出的业务请求；

调用与该业务场景对应的订单通用流程模块和订单定制流程插件；

在所述订单插件管理平台上运行订单通用流程模块中的通用流程和订单定制流程插件中的定制流程。

Images