CN111914194A - 一种业务系统变更方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请公开了一种业务系统变更方法、装置、电子设备及存储介质，该业务系统变更方法由业务服务器执行，包括：获取业务系统的变更请求，根据变更请求确定过滤规则；接收访问指定业务接口的第二网络请求；将所述第二网络请求与所述过滤规则中的所述第一网络请求进行匹配，若匹配成功，则根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址，所述目标接口地址与所述第二网络请求指向的接口地址不同。本申请实施例避免了业务系统的接口全量更新导致线上服务中断的技术问题，降低了线上故障的风险，提升了业务系统变更的稳定性。

Description

一种业务系统变更方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种业务系统变更方法、装置、电子设备及存储介质。

背景技术

由于使用年限的增加、产品需求的变化、代码开发的不规范等原因，一些业务系统的项目层级冗余繁杂，系统架构混乱，亟需进行更新重构，差错处理系统就是其中之一。差错处理系统是处理资金差错业务的系统，在网络支付业务中，如果出现资金差错则需要通过差错处理系统进行相应的信息沟通和账务调整。

发明内容

本申请实施例提供了一种业务系统变更方法、装置、电子设备及存储介质，以降低业务系统变更时线上故障风险，提升业务系统变更的稳定性。

本申请实施例采用下述技术方案：

第一方面，本申请实施例提供一种业务系统变更方法，由业务服务器执行，所述方法包括：

获取业务系统的变更请求，根据变更请求确定过滤规则，所述过滤规则中包括业务系统中用于访问目标业务接口的第一网络请求，所述目标业务接口与所述变更请求对应；

接收访问指定业务接口的第二网络请求；

将所述第二网络请求与所述过滤规则中的所述第一网络请求进行匹配，若匹配成功，则根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址，所述目标接口地址与所述第二网络请求指向的接口地址不同。

可选地，所述第二网络请求具体为统一资源定位符URL请求，所述根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址包括：重写所述URL请求的路径并保持所述URL请求的参数不变，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址。

可选地，重写所述URL请求的路径具体包括：根据业务系统中各业务接口的原接口地址确定重写标识；在所述URL请求的路径中添加所述重写标识。

可选地，所述根据变更请求确定过滤规则包括：根据变更请求获取业务系统中各业务接口在预设评价指标上的得分，确定得分满足得分阈值的目标业务接口；将用于访问所述目标业务接口的第一网络请求添加到网络请求集合中，得到本次迭代使用的过滤规则。

可选地，将所述第二网络请求与所述过滤规则中的第一网络请求进行匹配包括：

将所述第二网络请求与所述过滤规则中的各第一网络请求进行比对，如果存在与所述第一网络请求相同的第二网络请求，则确定匹配成功。

可选地，将所述第二网络请求与所述过滤规则中的各第一网络请求进行比对包括：从本地内存中或Redis服务器中读取状态标志寄存器的值；在所述状态标志寄存器的值为第一目标值的情况下，将所述第二网络请求与所述第一网络请求进行比对。

可选地，方法还包括：在所述状态标志寄存器的值为第二目标值的情况下，将所述第二网络请求转发至该指定业务接口的原接口地址。

可选地，该方法还包括：在第三网络请求指向所述指定业务接口的目标接口地址的过程中出现故障的情况下，修改所述状态标志寄存器的值为所述第二目标值。

第二方面，本申请实施例还提供一种业务系统变更装置，由业务服务器执行，所述装置用于实现本申请实施例第一方面所述方法。

第三方面，本申请实施例还提供一种电子设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行本申请实施例第一方面所述方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行本申请实施例第一方面所述方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：通过获取业务系统的变更请求，根据变更请求确定过滤规则，过滤规则中包括业务系统中用于访问目标业务接口的第一网络请求，所述目标业务接口与所述变更请求对应，实现了将业务系统的业务接口分批迭代的效果，避免了业务接口全量更新容易导致线上服务中断的技术问题。进一步的，将第二网络请求与第一网络请求进行匹配，若匹配成功，则根据预设的重写规则对第二网络请求进行重写，以使重写得到的第三网络请求指向指定业务接口的目标接口地址，目标接口地址与第二网络请求指向的接口地址不同，从而通过重写网络请求，在线上服务出现故障时将网络请求切换至安全的业务逻辑，降低了线上故障的风险，提升业务系统变更的稳定性。

附图说明

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

图1为本申请一个实施例的业务系统变更方法的流程示意图；

图2为本申请另一个实施例的业务系统变更方法的流程示意图；

图3为本申请又一个实施例的业务系统变更方法的流程示意图；

图4为本申请实施例中的业务系统变更装置的框图；

图5为本申请实施例中的电子设备的结构示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

随着使用年限的增加，差错处理系统的项目层级冗余繁杂，代码臃肿，需要对差错处理系统进行整体的重构(重构是通过调整程序代码改善软件的质量和性能，使程序的设计模式和架构更趋合理的一种方式)。

针对这一需求，本申请实施例的业务系统变更方案对应有两种应用场景，分别是：场景一，业务系统由旧版本更新到新版本的更新以及场景二，业务系统由新版本变更到旧版本。换句话说，本申请实施例的业务系统变更更具体的，变更请求包括业务系统的业务接口从旧版本变更到新版本的第一变更请求，以及业务系统的业务接口从新版本变更到旧版本的第二变更请求。

相应的，当变更请求为第一变更请求时，根据第一变更请求确定本次迭代使用的过滤规则；所述过滤规则包括由目标业务接口的第一网络请求组成的网络请求集合，所述目标业务接口是符合从旧版本变更到新版本这一过滤条件的业务接口。当变更请求为第二变更请求时，根据第二变更请求确定本次迭代使用的过滤规则，过滤规则包括由目标业务接口的第一网络请求组成的网络请求集合，所述目标业务接口是符合新版本变更到旧版本这一过滤条件的业务接口。

业务系统两种变更的流程相同，只是内容(比如，目标业务接口、目标接口地址)不同，为保持简要，本申请实施例主要以业务系统的业务接口从旧版本变更到新版本为例进行说明，可以理解，当业务系统的业务接口从新版本变更到旧版本时可参照业务系统的业务接口从旧版本变更到新版本的变更流程。

对于业务系统的业务接口从旧版本变更到新版本，有一种业务系统变更方案是采用基于全量重构的上线方案：将系统重新进行架构设计与代码开发，重构完成后整体提测，进行测试验证，验证完成后进行小流量灰度上线，线上验证没有问题则进行全量发布，完成系统更新。然而，在重构过程中，如果对差错处理系统直接进行完整重构后提测上线，那么无论是开发的时间进度，测试的完备还是上线的风险，都非常的不可控。

基于以上原因，结合业务系统变更对迭代次数的要求与线上生产安全性的约束，本申请实施例提出了对差错处理系统进行分批更新的设计，保证开发的进度与测试的完备。此外，为了实现对上线造成的影响最小，本申请实施例在保留差错处理系统原有工程架构的基础上，通过重写网络请求，将网络请求指向更新后的服务，如遇到线上问题，也能将服务即时切换回到旧版本业务逻辑，最大程度保证了线上服务的安全稳定。

实施例1

图1为本申请一个实施例的业务系统变更方法的流程示意图，参见图1，本申请实施例中的业务系统变更方法，由业务服务器执行，包括以下步骤：

步骤S120，获取业务系统的变更请求，根据变更请求确定过滤规则，所述过滤规则中包括业务系统中用于访问目标业务接口的第一网络请求，所述目标业务接口与所述变更请求对应。

步骤S140，接收访问指定业务接口的第二网络请求。比如，接收客户端发送的访问指定业务接口的第二网络请求。

步骤S160，将所述第二网络请求与所述过滤规则中的所述第一网络请求进行匹配，若匹配成功，则根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址，所述目标接口地址与所述第二网络请求指向的接口地址不同。

由图1所示可知，本申请实施例的这种业务系统变更方法，根据业务系统变更请求确定过滤规则，针对访问指定业务接口的第二网络请求，根据过滤规则确定是否需要改写第二网络请求，如果第二网络请求与过滤规则中的第一网络请求匹配成功则需要改写第二网络请求，即对第二网络请求进行重写，使重写后得到第三网络请求指向该指定业务接口的目标接口地址，目标接口地址与第二网络请求指向的接口地址不同。如此，通过过滤规则过滤业务接口，通过重写第二网络请求得到第三网络请求使第三网络请求指向接口的目标接口地址，实现了将业务系统的业务接口分批更新的目的，避免了业务接口全量更新容易导致线上服务中断的技术问题，提升了业务系统变更的稳定性。

需要说明的是，实施例1所提供方法的各步骤的执行主体均可以是同一设备，比如业务服务器，或者，该方法也由不同设备作为执行主体。比如，步骤S120的执行主体可以为设备一，步骤S140和步骤S160的执行主体可以为设备二；又比如，步骤S140的执行主体可以为设备一，步骤S120和步骤S160的执行主体可以为设备二。

以下以差错处理系统这一业务系统为例，对本申请实施例的业务系统变更方法在业务接口从旧版本变更到新版本过程中的具体应用和实现步骤进行说明。可以理解，本申请实施例的业务系统不限于差错处理系统，业务系统也可以是交易转接业务系统、身份认证及签约业务系统、资金预存业务系统等需要进行版本变更的各种系统。

实际应用中，考虑到差错处理系统的业务接口数量较多，并且各业务接口的重要性程度、上线后的影响程度等不尽相同，本申请实施例在对差错处理系统更新时采用业务接口分批更新的方式。比如，本申请实施例中根据业务系统变更请求，确定过滤规则。实际应用中可根据指示业务系统变更请求的重构代码，确定本次迭代使用的过滤规则，也可以将业务接口的新版本业务逻辑的重构代码与相应业务接口的旧版本业务逻辑的代码解耦，与采用基于接口方法中设置标志位状态的业务系统更新方案相比，这种将业务接口的新旧版本业务逻辑的代码完全分离，实现解耦的方案，便于更新完成(比如业务接口全部更新完毕且保持稳定一定时间)后一次性、快速去除旧版本业务逻辑对应的代码。

本申请实施例的过滤规则包括由符合过滤条件的目标业务接口的第一网络请求。相应的，将所述第二网络请求与所述过滤规则中的第一网络请求进行匹配包括：将所述第二网络请求与所述过滤规则中的各第一网络请求进行比对，如果存在与所述第一网络请求相同的第二网络请求，则确定匹配成功。

实际应用中，业务系统的业务接口都对应有第一网络请求，比如目标业务接口1的第一网络请求URL为：http://www.123.net/commerce/123456，将目标业务接口1的URL放入过滤规则(即网络请求集合)，之后当收到访问指定业务接口的第二网络请求(比如http://www.123.net/commerce/123456)时，第二网络请求与网络请求集合中的每个第一网络请求进行匹配，经过对比可知，第二网络请求与网络请求集合中目标业务接口1的第一网络请求一致，则认为匹配成功。

如前述，本申请实施例在每次迭代过程中，确定本次迭代所使用的过滤规则。过滤规则例如是网络请求集合，网络请求集合包括第一网络请求，第一网络请求限定了一次迭代过程中对应更新的目标业务接口，即，每次迭代都可以对过滤规则进行更新，从而达到业务接口分批迭代的目的，符合敏捷开发的规则，便于管理和控制风险。

本申请实施例中确定目标业务接口的具体实施方式之一是：根据变更请求获取业务系统中各业务接口在预设评价指标上的得分，确定得分满足得分阈值的目标业务接口；将目标业务接口的第一网络请求添加到网络请求集合中，得到本次迭代使用的过滤规则。

也就是说，在差错处理系统更新过程中，根据具体的指示业务系统更新的变更请求确定待更新的业务接口，比如，根据业务系统变更请求确定全部的业务接口：第1业务接口至第30业务接口均为待更新业务接口，对待更新的第1业务接口至第30业务接口，计算各业务接口(第1业务接口至第30业务接口)在预设评价指标上的得分，预设评价指标比如是：业务接口的优先级、更新耗费的资源、接口更新上线后的影响等指标之一或组合，将得分不大于得分阈值的业务接口作为目标业务接口，相应的，将目标业务接口的第一网络请求添加到网络请求集合中。

举例而言，经过计算，第1业务接口在业务接口优先级这一指标上的得分为30分，得分阈值为50，比较可知，第1业务接口的得分不大于得分阈值，则将第1业务接口对应的第一网络请求添加到第一次迭代使用的网络请求集合中，以此类推，将30个业务接口的得分均与得分阈值进行比较，确定出迭代次数以及每次迭代使用的过滤规则，即网络请求集合，进一步地，可以将过滤规则添加到差错处理系统的web.xml的配置文件中以便后续执行更新时使用。

可以理解，一次迭代使用的过滤规则包括的第一网络请求数量可以相同也可以不同，比如，第一次迭代时过滤规则中包括10个目标业务接口的第一网络请求，第二次迭代时从剩余的20个接口中选择4个目标业务接口，将4个目标业务接口的第一网络请求放入过滤规则，即，第二次迭代时过滤规则中包括4个目标业务接口各自的第一网络请求。可知，两次迭代过滤规则中的第一网络请求的数量不等。

本申请实施例在此示出了前述根据变更请求确定过滤规则的一种具体实现方式。当然，应理解，根据变更请求确定过滤规则的步骤也可以采用其它的方式实现，本申请实施例对此不作限制。

需要说明的是，考虑到差错处理更新可能对线上服务的影响，本申请实施例优先对不太重要的、优先级权重低的业务接口进行更新，待这些业务接口更新完成后再逐步对优先级权重高的、上线后影响小的业务接口进行更新，从而降低业务系统变更时线上故障风险。

对于业务系统的业务接口从新版本变更到旧版本的需求，本申请实施例的业务系统变更方法的实现步骤大致相同，具体包括，

首先，获取业务系统由新版本变更到旧版本的降级变更请求，根据降级变更请求确定用于过滤待降级的业务接口的过滤规则。

比如，与前述确定待更新的目标业务接口类似，根据业务系统降级变更请求在执行新版本业务逻辑的第1业务接口至第30业务接口中通过计算各业务接口在预设评价指标上的得分，预设评价指标比如是：业务接口的优先级、降级耗费的资源、接口变更后的线上影响等指标之一或组合，将得分不大于得分阈值的业务接口作为目标业务接口，相应的，将目标业务接口的第一网络请求添加到网络请求集合中，得到过滤规则。

需要说明的是，与前述业务系统的业务接口从旧版本变更到新版本的情况下第一网络请求与业务接口旧版本接口地址对应不同，这里的目标业务接口的第一网络请求是业务接口新版本接口地址对应。

其次，接收访问指定业务接口的第二网络请求。

接着，将第二网络请求与过滤规则中的第一网络请求进行匹配，若匹配成功，则根据预设的重写规则对第二网络请求进行重写，以使重写得到的第三网络请求指向指定业务接口的目标接口地址(目标接口地址即旧版本业务逻辑对应的接口地址)。

至此，对于业务系统的业务接口从新版本变更到旧版本的情况，本申请实施例的业务系统变更方法采用业务接口分批处理方式，降低了系统线上故障风险，提高了业务系统变更稳定性。

实施例2

需要说明的是，实施例2与实施例1中的部分步骤相同，实施例2对实施例1中步骤S160的具体实施方式进行重点说明，其他内容可以参见实施例1中的说明，这里不再赘述。

图2为本申请另一个实施例的业务系统变更方法的流程示意图，参见图2，本申请实施例的业务系统变更方法的实现流程如下：

步骤S220，接收访问指定业务接口的第二网络请求。

在差错处理系统的web层接收访问指定业务接口的第二网络请求，这里的第二网络请求具体为统一资源定位符URL(Uniform Resource Locator)请求。

通常URL请求中包括协议类型(比如超文本传输协议HTTP(Hyper Text TransferProtocol))、请求路径(比如“../getUserList/”)以及请求方法(比如get和post)。其中，get和post的主要区别表现在数据传递上，get是在URL后面以？的形式加上发给服务器的参数，多个参数之间用符号&隔开，post则是将发给服务器的参数全部放在请求体中。需要说明的是，参数是指传递给服务器的具体数据，比如登录时的账号、密码。

步骤S240，判断指定业务接口的版本。

这里的版本包括指定业务接口所使用的新版本业务逻辑和旧版本业务逻辑。本申请实施例中，判断指定业务接口所使用的业务逻辑版本是根据过滤规则来确定，具体的包括：将访问指定业务接口的第二网络请求与网络请求集合中的各个第一网络请求进行比对，如果存在与第一网络请求相同的第二网络请求，则确定匹配成功，即指定业务接口所使用的业务逻辑的版本为新版本。也就是说，访问指定业务接口的第二网络请求是需要被重写的网络请求。

参见图2，如果在判断指定业务接口的版本这一步骤中的判断结果为新版本业务逻辑，那么本申请实施例中根据预设的重写规则对所述第二网络请求进行重写，以使重写后得到的第三网络请求指向该指定业务接口的目标接口地址。需要说明的是，目标接口地址与所述第二网络请求指向的接口地址不同，具体到本申请实施例中，目标接口地址即指定业务接口的新版本业务逻辑的接口地址，第二网络请求指向的接口地址是指定业务接口的旧版本业务逻辑的接口地址。

这里，根据预设的重写规则对所述网络请求进行重写包括：根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址包括：重写所述URL请求的路径并保持所述URL请求的参数不变，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址。比如，重写所述URL请求的路径具体包括：根据业务系统中各业务接口的原接口地址确定重写标识；在所述URL请求的路径中添加重写标识。

也就是说，URL重写是在过滤规则匹配后将访问指定业务接口的原URL中的请求路径进行改写，而不改变原URL的post/get请求中所涉及的参数。

接上例，根据业务系统中第1至第30业务接口的原接口地址确定重写标识，遍历这30个业务接口的原接口地址(或称旧版本业务逻辑所用的接口地址)，根据遍历结果确定一个与这这30个业务接口的原接口地址包含的内容均不同标识作为重写标识。

示例性的，以“/dal”作为重写标识为例，对下列原始的第一网络请求http://……/get？username＝xxx&pwd＝xx进行重写，重写后得到的第三网络请求为：http://……/dal/get？username＝xxx&pwd＝xx。这样，重写后的URL路径与任一业务接口旧版本业务逻辑的接口地址均无关联，避免了重写后的URL路径与业务接口旧版本业务逻辑的接口地址发生关联，递归访问旧版本业务逻辑的接口地址导致更新失败的技术问题。

需要说明的是，本申请实施例中是对业务接口的新版本业务逻辑进行重构和更新，差错处理系统的原有公共服务可以继续调用，不受影响，比如图2所示，不论是新版本业务逻辑还是旧版本业务逻辑都连接至同一数据库，在确定指定业务接口所使用的业务逻辑的版本，将URL请求指向指定业务接口的新版本业务逻辑的接口地址或者旧版本业务逻辑的接口地址之后，新旧版本业务逻辑被调用时均能够访问数据库进行处理，返回处理结果，即新旧版本业务逻辑与数据库之间的服务和调用保持不变，如此，减轻了系统更新的工作量，提高了更新效率。

由上可知，本申请实施例的业务系统变更方法，根据业务系统变更请求对过滤规则进行更新并分批实现业务接口从旧版本到新版本的变更，对于访问指定业务接口(比如第1业务接口)的URL请求，判断是否需要重写，当需要重写时，根据业务系统中各业务接口的原接口地址确定重写标识，在第二URL请求的路径中添加重写标识，使重写后得到的第三URL请求指向第1业务接口的新版本业务逻辑的目标接口地址，完成第1业务接口的更新。

由于设置了过滤规则对业务接口进行分批过滤，通过重写第二URL请求的路径并保持第二URL请求的参数不变，使重写得到的第三网络请求指向所指定业务接口的目标接口地址，避免了业务接口全量更新导致线上服务中断的问题，通过重写URL请求指向新版本业务逻辑的接口地址，如遇到线上问题，能将服务即时切回旧版本的业务逻辑，保证线上服务的安全稳定。

实施例3

图3为本申请又一个实施例的业务系统变更方法的流程示意图，本申请实施例的业务系统变更方法包括下列流程步骤：

参见图3，步骤S300，接收访问指定业务接口的第二网络请求。

步骤S320，读取状态标志寄存器的值。

状态标志寄存器的值有两种情况，分别等于第一目标值或第二目标值，本申请实施例中，将第二网络请求与过滤规则中的各第一网络请求进行比对，具体包括：从本地内存中或Redis服务器中读取状态标志寄存器的值，在所述状态标志寄存器的值为第一目标值的情况下，将所述第二网络请求与所述第一网络请求进行比对。

在所述状态标志寄存器的值为第二目标值的情况下，将所述第二网络请求转发至该指定业务接口的原接口地址，该指定业务接口的原接口地址为旧版本业务逻辑对应的接口地址。这种情况下，直接将第二网络请求转发至指定业务接口的原接口地址，无需重写第二网络请求。考虑到业务系统更新中的各种状况和故障，在一次更新迭代中当状态标志位的值设置为第二目标值时，不对接收的第二网络请求重写，避免引发系统故障。

参见图3，步骤S340，判断指定业务接口的版本。

在所述状态标志寄存器的值为第一目标值的情况下，判断指定业务接口的版本，根据判断结果的不同，分别基于指定业务接口的新版本业务逻辑访问数据库，或基于指定业务接口的旧版本业务逻辑访问数据库。

需要说明的是，实施例3与实施例2的主要区别在于增加了读取状态标志寄存器并根据状态标志寄存器的取值分别执行相关步骤，本申请实施例之所以设置状态标志寄存器并在业务系统变更过程中读取状态标志寄存器的值进而根据状态标志寄存器值进行不同处理是因为：一旦指定业务接口的新版本业务逻辑线上出现问题，仅需要进行状态开关改变即可及时切换到旧版本业务逻辑，避免了系统回滚，提高可用性，降低线上故障风险，上线后对业务几乎没有影响。

由于实施例3与实施例2中的部分步骤相同，所以以下重点对判断状态标志寄存器的值的相关步骤进行说明，其他内容可以参见实施例2中的说明，这里不再赘述。

如前述，本申请实施例，从本地内存中或保存在Redis服务器中读取状态标志寄存器的值，在所述状态标志寄存器的值为第一目标值(比如true)的情况下，将所述第二网络请求与所述第一网络请求进行比对。在所述状态标志寄存器的值为第二目标值的情况下(比如false)时，将所述第二网络请求转发至该指定业务接口的原接口地址。

可以理解，状态标志寄存器(即状态标志位)相当于开关，状态标志寄存器的值默认为第一目标值，以便后续根据过滤规则确定指定业务接口所使用的业务逻辑的版本，并在指定业务接口的版本为新版本业务逻辑时重写URL请求，从而实现差错处理系统的更新。如果重写后的网络请求指向该指定业务接口的新版本业务逻辑的接口地址的过程中出现故障，则修改状态标志寄存器的值为第二目标值。即，一旦接口的新版本业务逻辑线上出现问题，通过开关改变(修改状态标志寄存器的值为第二目标值)即可及时切换到旧版本的业务逻辑，提高可用性，降低了线上故障风险。

为了防止状态标志寄存器的数据丢失，本申请实施例将状态标志寄存器保存在本地内存中或保存在Redis服务器中。需要说明的是，Redis是一个远程数据结构服务器，它的内存存储比较高效。

基于以上说明可知，通过设置状态标志寄存器，并在发生新服务故障时，修改状态标志寄存器的值，即可将访问指定业务接口的网络请求转发至旧版本业务逻辑的接口地址，提高了差错处理系统线上可用性和安全性。

实施例4

本申请实施例还提供了一种业务系统变更装置，由业务服务器执行，装置用于实现前述任一实施例所述的方法。图4为本申请实施例中的业务系统变更装置的框图，参见图4，业务系统变更装置400包括：

获取模块420，用于获取业务系统的变更请求，根据变更请求确定过滤规则，所述过滤规则中包括业务系统中用于访问目标业务接口的第一网络请求，所述目标业务接口与所述变更请求对应；

接收模块440，用于接收访问指定业务接口的第二网络请求；

变更模块460，用于将所述第二网络请求与所述过滤规则中的所述第一网络请求进行匹配，若匹配成功，则根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址，所述目标接口地址与所述第二网络请求指向的接口地址不同。

在本申请的一个实施例中，第二网络请求具体为统一资源定位符URL请求，变更模块460，具体应用于重写所述URL请求的路径并保持所述URL请求的参数不变，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址。

在本申请的一个实施例中，变更模块460，具体根据业务系统中各业务接口的原接口地址确定重写标识；在所述URL请求的路径中添加所述重写标识。

在本申请的一个实施例中，获取模块420具体用于根据变更请求获取业务系统中各业务接口在预设评价指标上的得分，确定得分满足得分阈值的目标业务接口；将用于访问所述目标业务接口的第一网络请求添加到网络请求集合中，得到本次迭代使用的过滤规则。

在本申请的一个实施例中，变更模块460具体用于将所述第二网络请求与所述过滤规则中的各第一网络请求进行比对，如果存在与所述第一网络请求相同的第二网络请求，则确定匹配成功。

在本申请的一个实施例中，变更模块460用于从本地内存中或Redis服务器中读取状态标志寄存器的值；在所述状态标志寄存器的值为第一目标值的情况下，将所述第二网络请求与所述第一网络请求进行比对。

在本申请的一个实施例中，业务系统变更装置还用于所述状态标志寄存器的值为第二目标值的情况下，将所述第二网络请求转发至该指定业务接口的原接口地址。

在本申请的一个实施例中，业务系统变更装置还用于在第三网络请求指向所述指定业务接口的目标接口地址的过程中出现故障的情况下，修改所述状态标志寄存器的值为所述第二目标值。

能够理解，上述业务系统变更装置，能够实现前述实施例中提供的由业务服务器执行的业务系统变更方法的各个步骤，关于业务系统变更方法的相关阐释均适用于业务系统变更装置，此处不再赘述。

图5为本申请实施例中的电子设备的结构示意图。请参考图5，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成业务系统变更装置。

处理器，执行存储器所存放的程序，并具体用于执行以下操作：

获取业务系统的变更请求，根据变更请求确定过滤规则，所述过滤规则中包括业务系统中用于访问目标业务接口的第一网络请求，所述目标业务接口与所述变更请求对应；

接收访问指定业务接口的第二网络请求；

将所述第二网络请求与所述过滤规则中的所述第一网络请求进行匹配，若匹配成功，则根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址，所述目标接口地址与所述第二网络请求指向的接口地址不同。

上述如本申请图1所示实施例揭示的业务系统变更装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图1中业务系统变更装置执行的方法，并实现业务系统变更装置在图4所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图1所示实施例中业务系统变更装置执行的方法，并具体用于执行：

获取业务系统的变更请求，根据变更请求确定过滤规则，所述过滤规则中包括业务系统中用于访问目标业务接口的第一网络请求，所述目标业务接口与所述变更请求对应；

接收访问指定业务接口的第二网络请求；

将所述第二网络请求与所述过滤规则中的所述第一网络请求进行匹配，若匹配成功，则根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址，所述目标接口地址与所述第二网络请求指向的接口地址不同。

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

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

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

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

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

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

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

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

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

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

Claims (11)

1.一种业务系统变更方法，由业务服务器执行，其中，所述方法包括：

获取业务系统的变更请求，根据变更请求确定过滤规则，所述过滤规则中包括业务系统中用于访问目标业务接口的第一网络请求，所述目标业务接口与所述变更请求对应；

接收访问指定业务接口的第二网络请求；

将所述第二网络请求与所述过滤规则中的所述第一网络请求进行匹配，若匹配成功，则根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址，所述目标接口地址与所述第二网络请求指向的接口地址不同。

2.如权利要求1所述方法，其中，所述第二网络请求具体为统一资源定位符URL请求，

所述根据预设的重写规则对所述第二网络请求进行重写，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址包括：

重写所述URL请求的路径并保持所述URL请求的参数不变，以使重写得到的第三网络请求指向所述指定业务接口的目标接口地址。

3.如权利要求2所述方法，其中，重写所述URL请求的路径具体包括：

根据业务系统中各业务接口的原接口地址确定重写标识；

在所述URL请求的路径中添加所述重写标识。

4.如权利要求1所述方法，其中，所述根据变更请求确定过滤规则包括：

根据变更请求获取业务系统中各业务接口在预设评价指标上的得分，确定得分满足得分阈值的目标业务接口；

将用于访问所述目标业务接口的第一网络请求添加到网络请求集合中，得到本次迭代使用的过滤规则。

5.如权利要求1所述方法，其中，将所述第二网络请求与所述过滤规则中的第一网络请求进行匹配包括：

将所述第二网络请求与所述过滤规则中的各第一网络请求进行比对，如果存在与所述第一网络请求相同的第二网络请求，则确定匹配成功。

6.如权利要求5所述方法，其中，将所述第二网络请求与所述过滤规则中的各第一网络请求进行比对包括：

从本地内存中或Redis服务器中读取状态标志寄存器的值；

在所述状态标志寄存器的值为第一目标值的情况下，将所述第二网络请求与所述第一网络请求进行比对。

7.如权利要求6所述方法，其中，所述方法还包括：

在所述状态标志寄存器的值为第二目标值的情况下，将所述第二网络请求转发至该指定业务接口的原接口地址。

8.如权利要求7所述方法，其中，该方法还包括：

在第三网络请求指向所述指定业务接口的目标接口地址的过程中出现故障的情况下，修改所述状态标志寄存器的值为所述第二目标值。

9.一种业务系统变更装置，由业务服务器执行，其中，所述装置用于实现权利要求1～8之任一所述方法。

10.一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行所述权利要求1～8之任一所述方法。

11.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行所述权利要求1～8之任一所述方法。

Images