一种业务发布方法、装置及设备与流程

本申请涉及计算机技术领域，尤其涉及一种业务发布方法、装置及设备。

背景技术：

随着信息技术的发展，业务提供方(诸如：网站、银行、电信运营商等)可向用户提供不同的业务服务。在实际应用中，业务提供方可能推出新的业务服务，以取代原有的业务服务。

对于此情况，现有技术中，通常会针对每一种需要发布的业务，设置一套独立的发布规则。

基于现有技术，我们需要一种更为有效的业务发布方式。

技术实现要素：

本申请实施例提供一种业务发布方法、装置及设备，用以提供一种更为有效的业务发布方式。

本申请实施例提供的一种业务发布方法，所述方法包括：

获取对应于待发布业务的业务信息；

根据所述业务信息以及预设的通用发布模型，发布所述待发布业务。

本申请实施例提供的一种业务发布装置，所述装置包括：

获取模块，获取对应于待发布业务的业务信息；

发布处理模块，根据所述业务信息以及预设的通用发布模型，发布所述待发布业务。

本申请实施例提供的一种业务发布设备，包括：

存储器，存储业务发布程序；

处理器，调用所述存储器中存储的业务发布程序，并执行：

获取对应于待发布业务的业务信息；

根据所述业务信息以及预设的通用发布模型，发布所述待发布业务。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

对于新上线、或需要进行迁移的各类业务而言，采用一种通用的发布模型来发布这些业务，从而能够在一定程度上减少为每一种待发布业务都设置一套发布逻辑的繁琐操作，提升了对待发布业务的发布效率和便捷性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本说明书实施例提供的业务发布所基于的架构示意图；

图2为本说明书实施例提供的业务发布过程；

图3a为本说明书实施例提供的在实际的业务场景下的通用发布模型的使用架构示意图；

图3b为本说明书实施例提供的详细业务发布过程；

图4a为本说明书实施例提供的在实际业务场景下的业务逻辑示意图；

图4b为本说明书实施例提供的在实际业务场景下的另一种业务逻辑示意图；

图5为本说明书实施例提供的业务发布装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本说明书的一个或多个实施例中，所述的业务发布过程，可认为是一种“灰度发布”的过程，也即，业务提供方针对部分用户提供(即，发布)新上线的业务，其余的用户仍使用原来的业务，并逐步将新上线的业务代替原来的业务。

需要说明的是，这里所述的业务，可包括各类软件产品或互联网服务等软件性质的业务，如：app客户端、软件程序、金融产品、云计算服务、云存储服务等等。

此外，在实际应用中的某些业务场景下，与业务相关的硬件设备，也可属于本说明实施例中所述“业务”的涵盖范围内。所述的与业务相关的硬件设备，可包括诸如业务服务器(或服务器集群)、数据库(或数据库集群)、区块链网络等。还可以包括一些设备内部的硬件组件，诸如中央处理器(centralprocessingunit，cpu)、内存、硬盘、设备上的物理接口等等。

在本说明书实施例中的业务发布方法可以采用如图1所示的架构。在图1中可见，架构包括：业务系统及通用发布模型。

其中，所述的业务系统，可认为是业务提供方后台用于提供业务产品或业务服务的系统，例如：支付业务系统，用于提供各类支付服务；金融业务系统，用于提供各类金融产品。在实际应用中，业务系统内可包括集群式或分布式的业务服务器，此外，还可包括区块链网络形式的业务设备。

所述的通用发布模型，可认为是一种普遍适用于不同业务的发布模型，也即，通过其中的发布逻辑，可以实现对不同业务的发布。采用通用发布的模型的意义在于，可以无需针对每一种新上线的业务进行单独编辑各自的发布逻辑，能够提供业务发布的效率。当然，在实际应用中，所述的通用发布模型可以运行在相应的设备中(如：运行在服务器中)。

通过上述的通用发布模型，可以将各类新上线的业务发布给用户进行使用，并逐步更替原有业务，实现业务的灰度发布。

当然，图1仅是一种简单的架构示例，在不同的业务场景中，架构中可能还会包括用户数据库(用户数据库中通常可存储使用业务的用户所对应的数据，如：用户id、用户使用业务的历史数据等)。具体采用何种架构将根据实际应用的需要所确定，这里并不应作为对本申请的限定。

基于如图1所示的架构，本申请实施例提供的业务发布过程如图2所示，该过程具体包括以下步骤：

步骤s201：获取对应于待发布业务的业务信息。

在本说明书实施例中，所述的待发布业务，可认为是需要进行发布的业务。在实际的业务场景中，对于待发布业务而言可能包含多种情况，例如：情况一、新业务(如：某种软件产品)需要上线发布(即，还未进行发布)；情况二、新业务已经针对部分用户发布，但还需要向其他用户进行发布推广；情况三、已经投入使用的业务需要进行迁移(如：迁移至新的业务系统中)。

上述情况中所提及的业务，均可看作是本说明书实施例中所述待发布业务的涵盖范围。

对于所述的业务信息而言，在实际的业务场景中，当用户使用了相应的业务之后，业务系统将会生成相应的、与用户有关的信息，例如：业务流水号(或单号)、业务详情信息等，这些信息可认为是本说明书实施例所述的业务信息的涵盖范围内。应注意的是，如上述的内容，某些待发布业务是未上线投入使用的业务，对于此情况，考虑到需要发布的业务可能会代替某些原有业务，所以，可通过原有业务的相关业务信息进行新业务的灰度发布。故，所述的业务信息，还包括原有业务的业务信息。

当然，在实际应用中，上述的业务信息中还可包含待发布业务自身的发布配置信息(即，该待发布业务自身的发布逻辑)。

以上内容并不应构成对本申请的限定。

步骤s203：根据所述业务信息以及预设的通用发布模型，发布所述待发布业务。

如前所述，所述的通用发布模型适用于各种新上线的业务。具体而言，在可行的实施例中，通用发布模型中可包含新上线业务与用户行为相关的判断逻辑、用户所使用的业务服务记录的判断逻辑等等，从而进一步决定新上线业务的发布方式。

那么，在获取到业务信息的基础上，便可以使用通用发布模型来发布新上线的业务。

通过上述步骤，对于新上线、或需要进行迁移的各类业务而言，采用一种通用的发布模型来发布这些业务，从而能够在一定程度上减少为每一种待发布业务都设置一套发布逻辑的繁琐操作，提升了对待发布业务的发布效率和便捷性。

对于上述如图2所示的业务发布方法，在实际应用时具有更为具体的执行过程。这里需要说明的是，在实际应用中通用发布模型的使用时机可如图3a所示。在图3a中，对于用户而言，用户无需获知业务新旧业务的区别，只需正常发出相应的业务操作。对于通用发布模型而言，当用户发出相应的业务操作后，可以获取归属于该用户的历史业务信息(如：用户在以前使用业务的业务id、所产生的业务单号、用户id等)。这样一来，通用发布模型便可以根据历史业务信息执行相应的业务发布逻辑，实现业务的发布。

下面将详细描述使用通用发布模型对待发布业务的发布过程。该过程可如图3b所示，可包括以下步骤：

步骤s301：获取待发布业务所对应的业务信息，并根据所述业务信息判断该业务是否携带自身的独立发布逻辑，若是，则执行步骤s303；否则，则执行步骤s305。

作为在实际应用场景中的一种实现方式，如果某一业务自身具有独立的发布逻辑，那么，通常会以发布逻辑配置信息的方式进行存储，而所述的发布逻辑配置信息属于上述业务信息中的一种。这样一来，便可以通过读取待发布业务的业务信息，来判断其中是否包含发布逻辑配置信息(也即，是否携带独立的发布逻辑)。

如果待发布业务具有独立的发布逻辑，那么，则可以按照其独立的发布逻辑进行业务的发布。否则，将运用通用的发布逻辑进行业务发布。

步骤s303：根据该业务的独立发布逻辑发布该业务。

步骤s305：判断待发布业务是否依赖用户的业务操作，若是，则执行步骤s307；否则，执行步骤s309。

这里需要说明的是，对于实际业务场景中的部分业务而言，一个完整的业务可能包含多个环节，而业务的不同环节可认为是调用不同的业务服务。如图4a所示，假设一个业务在实际的执行过程中，当接收到用户发出的业务操作后，业务系统需要调用相应的服务a、b/c，可完整地执行该业务。通过图4a所示的架构可知，业务系统是否调用服务a～c，往往与用户发出的业务操作有关(即，依赖于用户的业务操作)

更为具体地，在一个简单示例中：假设上述的业务是一种保险产品x，而该保险产品x的使用分为投保和理赔两个环节。对于保险业务系统，在投保环节将调用相应的投保服务a，实现用户的在线投保；在退保环节将调用相应的退保服务b，实现用户的在线退保；而理赔环节则将调用相应的理赔服务c，实现用户的在线理赔。

基于此，在本说明书实施例中，针对图4a所示的架构，如果业务系统在原有业务基础上，发布了一种新的业务(包含新的服务a’～c’)，形成如图4b所示的架构，那么，在业务执行时是否调用新业务的服务a’～c’，通常与用户的业务操作相关。正如上例：如果保险业务系统发布了新的保险产品y(其中包含新的投保服务a’、退保服务b’、理赔服务c’)，那么，具体执行何种保险产品的服务，就与用户之前所购买的保险产品相关(即，该示例中的保险产品依赖于用户的行为)。假设用户前次购买的保险产品是产品a’，那么，当用户发出退保操作时，通用发布模型将为该用户发布退保服务b’，供用户使用。

因此在本步骤s305中，如果一个需要发布的业务依赖于用户的操作，那么，就需要进一步确定出该业务操作所对应的业务服务的发布状态(即，执行步骤s307)。而如果待发布业务并不依赖于用户的操作，那么，就可直接执行下述步骤s309。

步骤s307：判断所述业务操作所对应的业务服务是否属于待发布的业务服务，若是，则执行步骤s311；否则，则执行步骤s309。

对于步骤s307而言，如果用户的业务操作所对应的业务服务属于待发布业务服务，那么，可认为该用户与待发布业务相关。反之，则可认为用户与待发布业务不相关。

步骤s309：判断所述业务操作是否依赖发布标识，若是，则执行步骤s313；否则，则执行步骤s315。

在步骤s309中，所述的发布标识，可认为是针对新业务的受众用户所生成的标识，也就是说，如果发出业务操作的用户具有该发布标识，也就表明其使用的业务是新发布的业务，业务系统也就会调用新发布业务的相关服务处理该业务操作。

这里所述新发布的业务服务，可理解为待发布业务所对应的业务服务，此时，待发布业务通常已经面向部分用户发布。

类似于上述步骤s307，若经过步骤s309判断出业务操作依赖发布标识，则可认为用户与待发布业务相关，反之，不相关。

步骤s311：调用新发布的业务服务处理所述业务操作。

步骤s313：判断所述用户是否具有发布标识，若是，则执行步骤s311；否则，则执行步骤s315。

正如在步骤s309中所描述，如果用户具有发布标识，则表明该用户是新发布的业务的受众用户，反之，该用户并未使用新发布的业务。

步骤s315：根据预设的发布条件为用户发布所述待发布业务。

作为本说明书实施例中的一种可行方式，这里的预设的发布条件，可以进一步包括依据白名单的发布条件或依据用户比例的发布条件。

其中，白名单中通常可记录用户的标识信息，如：用户id。对于被添加至白名单中的用户而言(即，满足白名单条件)，可以向这些用户发布所述的待发布业务。在实际应用中，可以按照随机选择的方式将用户添加至白名单中，也可以按照用户对业务使用的频率和程度作为添加至白名单的权重。当然，如何将用户添加至白名单中并不应作为对本申请的限定，这里便不再过多赘述。

在使用白名单条件的情况下，可在所述白名单中查询所述用户，将查询到的所述用户确定为目标用户，并针对所述用户发布所述待发布业务。

而用户比例的条件通常可认为至待发布业务的受众用户所占整体用户的比例达到某个值。具体而言，在依据用户比例的发布条件的情况下，可统计所述用户发出所述业务请求时刻目标用户与用户总量的比例，并在所述比例未超过设定的比例阈值时，将所述用户确定为目标用户，并发布所述待发布业务。

当然，基于用户比例的发布条件的使用方式并不限于此，在一种可能的实施例中，还可以根据用户id中某些字符的取值作为受众用户的确定条件，如：根据用户id最后一位的奇偶数来选定受众用户(各占50％)。这里仅是一种简单示例，并不应作为本申请的限定。

应理解，本说明书上述提及的业务发布方法能够应用在新产品上线或产品迁移的过程中，实现灰度发布。

以上为本申请实施例提供的业务发布方法，基于同样的思路，本申请实施例还提供一种业务发布装置，如图5所示。所述装置包括：

获取模块501，获取对应于待发布业务的业务信息；

发布处理模块502，根据所述业务信息以及预设的通用发布模型，发布所述待发布业务。

具体地，所述获取模块501，确定所述待发布业务对应的原有业务，获取所述原有业务的业务信息，并确定为对应于所述待发布业务的业务信息。

更为具体地，所述获取模块501，接收使用原有业务的用户所发出的业务请求，根据所述业务请求，确定所述用户的历史业务信息，作为所述原有业务的业务信息。

所述发布处理模块502，根据用户的所述历史业务信息，判断所述待发布业务是否与所述用户相关，若是，则将所述待发布业务发布给所述用户；否则，则根据设定的发布条件将所述待发布业务发布给所述用户。

所述发布处理模块502，判断所述待发布业务是否与所述用户的前次业务操作相关，若是，则确定所述待发布业务与所述用户相关；否则，则确定所述待发布业务与所述用户不相关。

所述发布处理模块502，查询用户的所述历史信息中包含的发布标识，若查询到所述发布标识，则确定所述用户与所述待发布业务相关，若为查询到所述发布标识，则确定所述用户与所述待发布业务不相关；

其中，所述发布标识是针对使用待发布业务的受众用户所生成。

此外，所述发布条件可包括：用户白名单条件和/或用户比例条件；

在此基础上，所述发布处理模块502，在所述白名单中查询所述用户，将查询到的所述用户确定为目标用户，并针对所述用户发布所述待发布业务，或，

统计所述用户发出所述业务请求时刻目标用户与用户总量的比例，并在所述比例未超过设定的比例阈值时，将所述用户确定为目标用户，并发布所述待发布业务。

所述装置还包括：独立发布模块503，在获取到的所述业务信息中，确定属于所述待发布业务的发布配置信息，当确定出所述发布配置信息时，根据所述发布配置信息发布所述待发布业务。其中，所述发布配置信息用于定义所述待发布业务自身的发布逻辑。

在如图5所示的业务发布装置的基础上，本说明书实施例还提供一种业务发布设备，包括：

存储器，存储业务发布程序；

处理器，调用所述存储器中存储的业务发布程序，并执行：

获取对应于待发布业务的业务信息；

根据所述业务信息以及预设的通用发布模型，发布所述待发布业务。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和介质类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可，这里就不再一一赘述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤或模块可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。