一种基于状态机的订单流转的灰度发布方法与流程

1.本发明涉及boss系统的灰度发布技术领域，并且更具体地，涉及一种基于状态机的订单流转的灰度发布方法。


背景技术：

2.电信行业boss系统十分庞大且关系错综复杂，一个完整的业务流程关联的系统特别多，同时电信行业随市场发展，需求变更非常频繁；虽然现有系统部署了业务受理端的灰度发布环境，但是在订单创建后，订单流转串联的业务流程未实现灰度发布，且这部分流程占了整个业务流程2/3以上，无法实现全链路端到端的灰度，以下几个方面的短板表现比较突出：
3.订单流转调用业务服务时报错，会导致订单无法归档；
4.订单流转指令激活失败，导致功能无法使用；
5.订单流转数据同步计费失败，会导致无法正常收费；
6.大量的异常单、在途单会影响客户的后续业务受理；
7.运维人员长期压力大，需深入到后台各个子系统处理数据；
8.开发人员凌晨蹲守现场发布版本，并兼并业务验证测试。


技术实现要素：

9.针对上述问题，本发明提出了一种基于状态机的订单流转的灰度发布方法，包括：
10.boss系统中各业务中心服务在受理业务时，根据灰度判断规则生产订单创建报文时，对订单做灰度打标，订单创建时，判断订单埋点灰度打标的值，在订单报文拆分写入订单流转表时做分流，灰度订单写入灰度订单流转表，生产订单写入生产订单流转表；
11.将订单流转程序按灰度订单和生产订单两套部署，通过流转程序入参做区分；
12.灰度订单流转时，服务调度指向灰度服务集群，消息发送指向灰度的消息主题；
13.订单等待关系灰度订单与生产订单不单独区分，统一做合并计算。
14.可选的，boss系统的订单中心制作一套灰度订单流转的表，部署一套灰度订单流转的应用程序集群，并创建一套灰度订单流转所需的消息中间件的消息主题。
15.可选的，boss系统的各渠道各业务中心在调用订单创建服务时，将订单创建的服务解析后，传递给订单中心的业务报文的灰度节点标识，以识别所述订单是否分流并按规则写入相应的订单流转表，以实现灰度订单与生产订单分流。
16.可选的，基于状态机对灰度订单进行流转。
17.可选的，订单在撤单、中断激活、重派、冲正时，应用程序自动识别订单为生产订单或灰度订单，并更新不同的订单流转表数据。
18.可选的，订单等待计算规则需和生产订单做合并计算。
19.可选的，订单组内不同子订单可能存在生产订单和灰度订单，制定统一规则。
20.可选的，所述订单中心提供灰度订单的运营采集页面。
21.本发明打通了boss系统与业务受理灰度的链接，并实现了订单流转与各环节系统的灰度应用的衔接，从而提供一套快捷、有效的端到端全链路的灰度验证环境，从而控制了上线影响范围，提升了产品质量和客户满意度，实现了产品(需求+项目)的高效迭代，减少了开发人员和运维人员的生产压力，实现了人员合理分配。
附图说明
22.图1为本发明方法的流程图；
23.图2为本发明方法的原理图。
具体实施方式
24.现在参考附图介绍本发明的示例性实施方式，然而，本发明可以用许多不同的形式来实施，并且不局限于此处描述的实施例，提供这些实施例是为了详尽地且完全地公开本发明，并且向所属技术领域的技术人员充分传达本发明的范围。对于表示在附图中的示例性实施方式中的术语并不是对本发明的限定。在附图中，相同的单元/元件使用相同的附图标记。
25.除非另有说明，此处使用的术语(包括科技术语)对所属技术领域的技术人员具有通常的理解含义。另外，可以理解的是，以通常使用的词典限定的术语，应当被理解为与其相关领域的语境具有一致的含义，而不应该被理解为理想化的或过于正式的意义。
26.本发明提出了一种基于状态机的订单流转的灰度发布方法，如图1所示，包括：
27.boss系统中各业务中心服务在受理业务时，根据灰度判断规则生产订单创建报文时，对订单做灰度打标，订单创建时，判断订单埋点灰度打标的值，在订单报文拆分写入订单流转表时做分流，灰度订单写入灰度订单流转表，生产订单写入生产订单流转表；
28.将订单流转程序按灰度订单和生产订单两套部署，通过流转程序入参做区分；
29.灰度订单流转时，服务调度指向灰度服务集群，消息发送指向灰度的消息主题；
30.订单等待关系灰度订单与生产订单不单独区分，统一做合并计算。
31.其中，boss系统的订单中心制作一套灰度订单流转的表，部署一套灰度订单流转的应用程序集群，并创建一套灰度订单流转所需的消息中间件的消息主题。
32.其中，boss系统的各渠道各业务中心在调用订单创建服务时，将订单创建的服务解析后，传递给订单中心的业务报文的灰度节点标识，以识别所述订单是否分流并按规则写入相应的订单流转表，以实现灰度订单与生产订单分流。
33.其中，基于状态机对灰度订单进行流转。
34.其中，订单在撤单、中断激活、重派、冲正时，应用程序自动识别订单为生产订单或灰度订单，并更新不同的订单流转表数据。
35.其中，订单等待计算规则需和生产订单做合并计算。
36.其中，订单组内不同子订单可能存在生产订单和灰度订单，制定统一规则。
37.其中，所述订单中心提供灰度订单的运营采集页面。
38.下面结合实施例对本发明进行进一步的说明：
39.本发明的原理如图2所示，具体的实现步骤如下：
40.各业务中心服务在受理业务时，根据一定灰度判断规则在生产订单创建报文时，
做灰度打标；订单创建时，判断订单埋点打标的值，在订单报文拆分写入订单流转表时做分流，灰度订单写灰度订单流转表，生产订单写生产订单流转表。
41.订单流转程序按灰度和生产分两套部署，程序共用，通过流转程序入参做区分。
42.灰度订单流转时，服务调度指向灰度服务集群，消息发送指向灰度的消息主题，这样能将各业务中心的灰度系统链接起来，生产订单流转保持不变。
43.订单等待关系灰度订单与生产订单不单独区分，统一做合并计算。
44.其中，boss系统的订单中心提供一套灰度订单流转的表(订单中心数据库与生产共用)，单独部署一套灰度订单流转的应用程序集群，单独创建一套灰度订单流转所需的消息中间件的消息主题。
45.其中，各渠道各业务中心在调用订单创建服务(流程和逻辑保持不变)，由订单创建服务解析传递给订单中心的业务报文的灰度节点标识，以此来识别该订单是否分流并按规则写入相应的订单流转表(订单流转有灰度订单流转表和普通订单流转表)，从而实现灰度订单与生产订单分流。
46.其中，基于状态机实现灰度订单流转，核心是通过独立部署的灰度订单流转程序来实现，灰度流转程序主要与灰度订单表数据做交互。灰度订单在流转调度时，如涉及调用业务侧服务的环节，则自动指向业务侧的灰度服务集群，如涉及消息交互环节，则自动与消息中间件的灰度消息主题做交互，从而实现订单创建上游与订单流转下游的端到端全链路灰度系统的业务串联。
47.其中，订单在撤单、中断激活、重派、冲正等应用程序，需支撑自动识别订单是生产订单和灰度订单，从而更新不同的订单流转表数据。
48.其中，订单等待计算规则需和生产订单做合并计算(不单独区分计算)，从而让业务侧无感知，也保障了同一用户不同订单的执行顺序一致，确保数据无混乱。
49.其中，订单组内不同子订单可能存在生产订单和灰度订单，制定统一规则，以订单组第一个子订单所归属的订单流转分类标识为准，后续的子订单若订单流转分类标识不一致，则在订单创建时默认重置为第一个子订单的订单流转分类标识，以此达到订单组能在同一套订单流转表正常流转并归档，保障业务的正确性。
50.其中，订单中心提供灰度订单的运营采集页面，以便各业务中心快捷提取灰度系统的灰度订单的执行情况，从而为灰度转生产提供数据指导。
51.本发明打通了boss系统与业务受理灰度的链接，并实现了订单流转与各环节系统的灰度应用的衔接，从而提供一套快捷、有效的端到端全链路的灰度验证环境，从而控制了上线影响范围，提升了产品质量和客户满意度，实现了产品(需求+项目)的高效迭代，减少了开发人员和运维人员的生产压力，实现了人员合理分配。
52.本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本发明实施例中的方案可以采用各种计算机语言实现，例如，面向对象的程序设计语言java和直译式脚本语言javascript等。
53.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程
图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
54.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
55.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
56.尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
57.显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。