软件发布方法与系统与流程

本发明涉及计算机软件领域，尤其涉及一种软件发布方法与系统。

背景技术：

在软件更新时，通常在现有软件的稳定版本的基础上逐步发布过渡版本，直至完全升级到新的稳定版本，从而稳定地实现软件更新。

同时，为了应对软件更新中的问题，有效地控制软件更新所带来的问题的波及范围，防止核心用户流失，在软件更新时，可采用基于用户的更新策略，即对用户进行分类，对于不同类别的用户请求采用不同软件版本进行处理，对于一部分用户请求使用过渡版本，而对另一部分用户请求仍然使用稳定版本。如此，在影响重要业务或用户之前该新版本引入的问题就能被发现，那样就很好地降低了软件升级可能产生的影响范围。

现有技术中的基于用户的软件发布方法中，通常采用基于路由的发布方法。具体而言，该方法在后端系统之前增加一个路由模块，所有访问后端系统的请求首先经过该路由模块。该方法需要同时启动多个后端系统用于应对不同的软件版本，一个软件版本对应一个后端系统。由路由模块解析用户请求后，根据用户请求所对应的软件版本，访问对应版本的后端系统。发布升级软件时，将路由表中需要升级的用户从旧软件版本指向新软件版本，然后路由模块动态加载更新后的路由信息即可。

然而，上述的现有技术需要额外设置路由模块，增加了路由模块的开发与维护成本。现有技术需要同时启动多个后端系统，操作复杂，维护麻烦。

技术实现要素：

本发明的目的在于提供一种软件的发布方法与软件系统，在基于用户进行软件更新时，操作维护简单，不易出错。

根据本发明的一个方面，提供一种软件发布方法，包括步骤：接收用户请求信息；基于用户请求信息，确定与用户请求信息相关联的请求方的特征；基于特征，确定向请求方发布的软件的版本标识；构建带有版本标识以及请求内容的后台请求信息；基于后台请求信息的版本标识，确定相对应的处理函数，不同版本标识绑定不同处理函数；使用与后台请求信息的版本标识相对应的处理函数处理后台请求信息。

根据本发明的另一个方面，提供一种软件系统，包括系统入口，系统入口基于接收的用户请求信息，确定与用户请求信息相关联的请求方的特征，并基于特征，确定向请求方发布的软件的版本标识，系统入口构建带有版本标识以及请求内容的后台请求信息；至少一个后台模块，每一个后台模块包括多个处理函数，每一个后台模块执行至少一个服务，每一个服务调用后台模块中的多个处理函数中的一个或者一组包含多个处理函数的组合，至少一个后台模块接收系统入口发送来的后台请求信息并基于后台请求信息的版本标识，确定相对应的处理函数，使用处理函数处理后台请求信息，其中不同版本标识绑定不同处理函数。

本发明通过系统入口构建带有版本标识以及请求内容的后台请求信息，后台模块通过版本标识确定处理函数，并使用相应的处理函数处理后台请求信息，即不同版本通过版本标识与处理函数绑定。由于存在多个处理函数，通过不同版本标识对应不同处理函数，因此基础版本与过渡版本能通过处理函数的形式同时存在，处理函数通过版本标识被后台模块匹配并使用，从而无需使用路由模块，避免了额外开发维护路由模块的成本。由于同一个后台模块可以同时包括多个处理函数，每次处理时，一个服务调用该后台模块中的多个处理函数中的一个或者一组包含多个处理函数的组合，因此可以仅布置一个服务，即线上只需要运行一个系统进程，而无需布置多个服务或是多套后端系统。

附图说明

以下结合附图和具体实施例对本发明的技术方案进行详细的说明，以使本发明的特性和优点更为明显。

图1为本发明的软件发布方法的一个实例的流程图；

图2为包含本发明的软件系统以及用户的一个实例的数据流向示意图；

图3为本发明的后台请求信息的一个实例的数据结构示意图。

具体实施方式

以下将对本发明的实施例给出详细的说明。尽管本发明将结合一些具体实施方式进行阐述和说明，但需要注意的是本发明并不仅仅只局限于这些实施方式。相反，对本发明进行的修改或者等同替换，均应涵盖在本发明的权利要求范围当中。

一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

图1为本发明的软件发布方法的一个实例的流程图。图2为包含本发明的软件系统以及用户的一个实例的数据流向示意图。

结合图1以及图2所示，通常作为请求方的用户201在其用户设备上装有客户端，客户端可以运行于特定客户端程序，例如安装在移动设备上的APP(application，应用程序)，客户端也可以运行于浏览器。用户201通过客户端向软件系统202发送用户请求信息301，用户请求信息301中包括请求内容，例如结算选中的商品，请求内容通过代码方式表示。需要注意的是，在本实施例中用户请求信息301来自于特定用户，在其他实施例中用户请求信息301也可是来自系统自运行的实例，例如监控系统是否正常工作的实例。

根据如图1所示的软件方法S100，软件系统202主要实施以下步骤：

步骤S101：接收用户请求信息。

步骤S102：确定请求方特征。

步骤S103：确定向所述请求方发布的软件的版本标识。

步骤S104：构建带有所述版本标识以及请求内容的后台请求信息。

步骤S105：确定与后台请求信息的版本标识相对应的处理函数。

步骤S106：使用处理函数处理所述后台请求信息。

步骤S107：构建响应信息返回请求方。

具体而言，首先如步骤S101，软件系统202的系统入口203接收用户请求信息301。

如步骤S102，系统入口203基于用户请求信息301，确定与用户请求信息301相关联的请求方201的特征。这里的特征可以包括用户名、用户IP地址、用户设备通信物理地址、用户客户端版本号、用户历史使用习惯、用户设备操作系统等。软件系统202可以通过读取与用户请求信息相关联的cookie信息、用户设备通信物理地址，解析用户请求信息301，查询数据库等方式获得上述特征。

接着如步骤S103，系统入口203基于步骤S102所确定的特征，根据软件发布策略，匹配特征所对应的向该请求方发布的软件的版本标识(message type ID)。软件发布策略是根据实际需要事先指定的一条或多条规则，例如根据用户名确认该用户为新用户时，则向其发布最新的过渡版本，确定该用户为长期稳定客户时，则向其发布稳定的基础版本。在其他实施例中，用户请求信息301来自于实例时，例如可以通过该实例的重要度评级特征，确定使用过渡版本还是基础版本处理该实例的用户请求信息301。软件发布策略也可以是多个规则的组合，多个规则例如可以根据优先级进行排列，当特征满足多个规则时，根据优先级在先的规则确定向其发布的版本，多个规则也可以通过更为复杂的逻辑进行组合。不同版本的软件通过不同版本标识进行区分，从而根据软件发布策略，匹配特征，从而得到向该请求方发布的软件的版本标识。

例如在本示例中，系统入口203读取用户设备通信物理地址获得用户设备通信物理地址的特征，通过查询数据库确定该用户为首次使用用户，根据软件发布策略，向该用户发布最新的过渡版本。

接着，如步骤S104,系统入口203基于用户请求信息301，构建后台请求信息302，后台请求信息302包括版本标识以及请求内容。图3示出了后台请求信息302的数据结构。如图3所示，后台请求信息302包括信息头401以及信息体402，信息头401中保存版本标识，信息体402中保存请求内容。具体而言，信息体402中包括用户请求信息301中请求内容，例如：结算选中的商品。对于来自不同用户的相同请求内容，信息体402相同。信息头401中包括版本标识字段(message type ID)，message type ID对应当前版本标识，并包括当前版本标识所基于的基础版本的基础版本标识。相同版本message type ID相同，不同版本的message type ID不同。由于message type ID包括基础版本的基础版本标识，因此，通过message type ID不仅可以唯一确定当前软件版本，还能够通过提取message type ID中的基础版本标识，从而得到当前版本所基于的基础版本。

在本实施例中，message type ID符合公式：

message type ID＝X+V*graybase (1)

其中，message type ID为版本标识，X为基础版本标识，V为版号，graybase为基准偏移量，message type ID、V以及graybase均为数值，+表示加法运算，*表示乘法运算。X可取值为0-100000之间的整数，V可为从1开始递增的整数。当V取0时，message type ID表示基础版本。

需要注意的是，基础版本标识X所对应的数值小于基准偏移量graybase所对应的数值，从而便于从message type ID提取基础版本标识X。通常基准偏移量graybase为一个较大的数值，从而保证了加了基准偏移量后的过渡版本的版本标识不会与基础版本标识冲突。

例如，取X为100，取graybase为1000，假设当前版本为在基础版本上的第1版过渡版本，则取版号V为1，根据公式(1)，message type ID＝100+1*1000＝1100。

当需要提取message type ID的基础版本标识X时，只需要根据公式：

X＝message type ID mod graybase (2)

其中mod表示取余数，即message type ID除以graybase后取余数。由于基础版本标识X所对应的数值小于基准偏移量graybase所对应的数值，因此mod运算能够很方便地从message type ID中提取出基础版本标识X。

例如，message type ID为1100，graybase为1000，根据公式(2)，X＝1100 mod 1000＝100。

容易得知的是，当版号V取值为0时，则message type ID对应基础版本。

当出现新的过渡版本时，只需要取新的版号V即可构建新的message type ID。

在其他实施例中也可以使用其他计算公式设定message type ID，只需要满足message type ID对应当前版本标识，并包括当前版本标识所基于的基础版本的基础版本标识即可，例如通过标记符分隔基础版本标识以及版号，例如通过使用字母数字组合等。本实施例中的message type ID的构建规则，即公式(1)，保证了所有的版本标识没有冲突，并可以快速得出基础版本标识。

根据上述的方法步骤，在本实施例中，如图1所示，系统入口203构建得到后台请求信息302.1，根据之前的步骤确定向该用户请求信息对应的请求方发布最新的过渡版本，因此后台请求信息302.1包括最新的过渡版本的版本标识1100，包括请求内容为表示结算选中的商品的代码。

接着，后台模块204对后台请求信息302进行处理，具体而言，如步骤S105，在后台模块204接收到后台请求信息302后，对后台请求信息302进行解析，读取信息头401的message type ID字段获得版本标识，根据版本标识查找并确定对应的处理函数205。每一个后台模块204包括多个处理函数205，每一个后台模块204执行至少一个服务，每一个服务调用该后台模块204中的多个处理函数205中的一个或者一组包含多个处理函数的组合。不同版本标识对应不同处理函数205，即版本标识与处理函数205绑定。这里的不同版本标识对应不同处理函数205，可以是不同版本标识对应不同个的处理函数205，也可以是不同版本标识对应不同组的包含多个处理函数的组合。

过渡版本的版本标识所对应的处理函数205由基础版本标识所对应的处理函数205全量复制并在此基础上修改而得到。可以想到的是，在其他实施例中也可以由其他方法得到过渡版本的版本标识所对应的处理函数205，例如设置通用子函数，在过渡版本的版本标识所对应的处理函数205中仅设置与基础版本标识所对应的处理函数205的区别部分。

如图1所示，在本实施例中，后台模块A204.1执行服务：计算选中商品实行优惠规则后的金额。后台模块A204.1中包括处理函数A1 205.1以及处理函数A2 205.2，版本标识1100为过渡版本，对应处理函数A2 205.2，版本标识100为稳定版本，对应处理函数A1 205.1，处理函数A2 205.2由处理函数A1 205.1全量复制并修改得到。后台模块A204.1读取后台请求信息302.1的信息头401从而获得版本标识为1100，根据版本标识1100确定所使用的处理函数A2 205.2。

如步骤S106，当后台模块204确定所使用的处理函数205后，使用处理函数205处理后台请求信息302。例如，后台模块A 204.1确定使用处理函数A2 205.2后，使用处理函数A2 205.2处理后台请求信息302.1。

在一些情况下，后台模块204在处理后台请求信息302后，根据对后台请求信息302的处理结果，构建响应信息303返回请求方201；在另一些情况下，一个后台模块204根据对后台请求信息302的处理结果，重新构建包括相同版本标识的后台请求信息302，并将重新构建的后台请求信息302发送至其他后台模块204，因此步骤S104-S106可能重复多次执行。需要注意的是，后台模块204之间通过后台请求信息302进行通信，在处理同一次用户请求信息301期间，不同后台模块204的后台请求信息302包括相同版本标识，通过相同的版本标识可以方便地保证各个后台模块204处理的统一性。

如图2所示，在本实施例中，后台模块A204.1处理后台请求信息302.1后，根据处理结果需要重新构建后台请求信息302.2，并将后台请求信息302.2发送到后台模块B204.2。后台请求信息302.2包括与后台请求信息302.1相同的版本标识，即后台模块B204.2读取后台请求信息302.2获得版本标识同样为1100。后台模块B204.2执行服务对选中商品计算累加金额。后台模块B204.2中包括处理函数B1 205.3以及处理函数B2 205.4，版本标识1100为过渡版本，对应处理函数B2 205.4，版本标识100为稳定版本，对应处理函数B1 205.3，处理函数B2 205.4由处理函数B1 205.3全量复制并修改得到。后台模块B204.2获得版本标识为1100后，根据版本标识1100确定所使用的处理函数B2 205.4，进而使用处理函数B2 205.4处理后台请求信息302.2。

需要注意的是，在一些情况下，后台模块204需要仅使用稳定版本，即需要禁用过渡版本。在这种情况下，对后台请求信息302进行解析，并获得版本标识后，根据版本标识提取基础版本标识，根据基础版本标识查找并确定对应的处理函数。

例如，如果对于后台模块204.2需要禁用过渡版本，则当后台模块B204.2获得版本标识为1100后，根据公式(2)提取基础版本标识为100，根据基础版本标识确认所对应的处理函数为处理函数B1 205.3，进而使用处理函数B1 205.3处理后台请求信息302.2。

从以上描述可看出，对任意一个后台模块204可以通过控制版本标识来选择是否进行稳定版本的升级。在现有技术中，由于采用同时启动多个后端系统，一个软件版本对应一个后端系统的方法，因此难以实现选择部分模块进行升级的功能，而通过本发明的方法，简单便捷地实现了对整个软件系统中的部分模块或是部分服务进行升级，而部分模块或是部分服务不进行升级的功能。

当后台请求信息302处理完毕后，如步骤S107，后台模块204构建相应信息303，并将响应信息303发回请求方201。需要注意的是，在其他实施例中，也可以没有步骤S107，即后台模块204处理后台请求信息302后直接完成本次对用户请求信息301的处理。

由以上对于本发明的软件发布方法的描述可看出，由于本发明中的多个软件版本对应的多个处理函数205是同时存在于同一个后台模块204的同一个服务中的，因此可以仅布置一个服务，即线上只需要运行一个系统进程，而无需布置多个服务或是多套后端系统。而现有技术中由于需要同时启动多套后端系统，如果后端系统执行定时任务，则需要同时针对于每套后端系统执行多次任务，另外在发现基础版本有错误时，则需要针对每套后端系统进行修改，维护麻烦。而本发明中由于可以仅布置一个服务，因此在执行定时任务时可以仅执行一次任务，在修复版本错误时，可以一次修改对应多个版本，从而避免了以上现有技术中的问题。

由于本发明采用构建带有版本标识的后台请求信息302，后台模块204通过识别与处理函数绑定的版本标识来加载不同版本，因此不再需要设置现有技术的路由模块，节省了额外的路由模块的开发维护成本。另外，现有技术中由于在后台模块前设置路由模块，用户请求信息通过路由模块进行中转，因此如果用户请求信息需要通过多阶段完成，则可能发生前一阶段的后台模块使用基础版本，后一阶段发生之前版本进行更新，使得后一阶段的后台模块使用过渡版本，从而造成系统处理的不统一。而本发明由于没有路由模块，而是通过具有相同的版本代码的后台请求信息302进行通信，因此保障了统一性。

当过渡版本运行稳定后，所有请求方201的用户请求信息301都逐步通过版本代码而由过渡版本进行处理时，将原来与该过渡版本的版本标识绑定的处理函数205与基础版本的版本标识绑定，并同时删除原基础版本的版本标识所对应的处理函数205，从而实现软件更新的完成。这样的更新方式可以实现新旧基本版本的平滑在线切换，无需重启原有进程。

本发明还提供了一种软件系统202，该软件系统202包括系统入口203以及至少一个后台模块204，系统入口203用于将接收到的用户请求信息301改写为后台请求信息302并发送到后台模块204，至少一个后台模块204接收后台请求信息302并进行处理。软件系统202的具体操作方法以及数据流向已在上文的软件发布方法中描述，此处不再赘述。

以上仅是本发明的具体应用范例，对本发明的保护范围不构成任何限制。除上述实施例外，本发明还可以有其它实施方式。凡采用等同替换或等效变换形成的技术方案，均落在本发明所要求保护的范围之内。