业务系统切换方法、装置、电子设备及存储介质
技术领域
本公开涉及计算机技术领域,具体涉及一种业务系统切换方法、装置、电子设备及存储介质。
背景技术
业务系统是为用户提供各种业务服务的处理系统。在业务系统的质量指标中,系统服务的可用性是一项关键指标。但是,由于业务需求的不断变化和更新,在现有业务系统无法支撑新业务需求时,必须要对原有的业务系统进行改造升级,这已经成为不可避免的问题。尤其是在基于互联网业务的业务系统,由于业务需求的变更速度更快,导致互联网业务系统的生命周期比其它行业的业务系统要短,因此升级改造的频率更高。
在业务系统切换过程,新业务系统虽然搭建完成,但由于未经使用考验,存在潜在缺陷的风险较大。因此,如何保证系统服务平稳地从原业务系统切换到新业务系统,是系统改造升级时需要考虑的核心问题。
发明内容
本公开实施例提供一种业务系统切换方法、装置、电子设备及存储介质。
第一方面,本公开实施例中提供了一种业务系统切换方法。
具体的,所述业务系统切换方法,包括:
将预设业务流量范围内的业务请求分发给新业务系统;其中,所述业务请求的业务类型与预设业务类型集合中的至少一个相匹配;
根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况;其中,所述预期结果为原业务系统对所述业务请求的处理结果;
根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围。
进一步地,所述将预设业务流量范围内的业务请求分发给新业务系统,包括:
接收所述业务请求;
所述业务请求在所述预设业务流量范围内时,确定所述业务请求的所述业务类型是否与所述预设业务类型集合中的至少一个相匹配;
在所述业务请求的所述业务类型与所述预设业务类型集合中的至少一个相匹配时,将所述业务请求分发给所述新业务系统。
进一步地,根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况,包括:
通过比对所述处理结果和所述预期结果确定所述处理结果是否符合预期。
进一步地,根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况,包括:
根据所述业务请求、所述处理结果和所述预期结果确定所述新业务系统针对所述预设业务类型集合的业务覆盖范围。
进一步地,根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围,包括:
在所述新业务系统针对所述预设业务类型集合的业务覆盖范围达到预设阈值时,从所述预设业务类型集合中剔除已被所述新业务系统覆盖的业务类型。
进一步地,根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围,包括:
响应于接收到的定时事件,根据所述业务覆盖范围从所述预设业务类型集合中剔除已被所述新业务系统覆盖的业务类型。
进一步地,根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围,还包括:
增大所述预设业务流量范围;和/或,
调整所述预设阈值。
进一步地,根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围,还包括:
在所述新业务系统针对所述预设业务类型集合的业务覆盖范围达到最大时,将当前的所述预设业务类型集合替换为新预设业务类型集合;其中,所述新预设业务类型集合中的至少一个还未被新业务系统所覆盖。
进一步地,根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围,还包括:
根据所述新预设业务类型集合重新设定所述预设业务流量范围。
进一步地,根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况之后,所述业务系统切换方法还包括:
根据所述业务处理情况生成可视化的业务处理报表。
第二方面,本公开实施例提供了一种业务系统切换装置,包括:
分发模块,被配置为将预设业务流量范围内的业务请求分发给新业务系统;其中,所述业务请求的业务类型与预设业务类型集合中的至少一个相匹配;
确定模块,被配置为根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况;其中,所述预期结果为原业务系统对所述业务请求的处理结果;
调整模块,被配置为根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围。
进一步地,所述分发模块,包括:
接收子模块,被配置为接收所述业务请求;
第一确定子模块,被配置为所述业务请求在所述预设业务流量范围内时,确定所述业务请求的所述业务类型是否与所述预设业务类型集合中的至少一个相匹配;
分发子模块,被配置为在所述业务请求的所述业务类型与所述预设业务类型集合中的至少一个相匹配时,将所述业务请求分发给所述新业务系统。
进一步地,所述确定模块,包括:
第二确定子模块,被配置为通过比对所述处理结果和所述预期结果确定所述处理结果是否符合预期。
进一步地,所述确定模块,包括:
第三确定子模块,被配置为根据所述业务请求、所述处理结果和所述预期结果确定所述新业务系统针对所述预设业务类型集合的业务覆盖范围。
进一步地,所述调整模块,包括:
第一剔除子模块,被配置为在所述新业务系统针对所述预设业务类型集合的业务覆盖范围达到预设阈值时,从所述预设业务类型集合中剔除已被所述新业务系统覆盖的业务类型。
进一步地,所述调整模块,包括:
第二剔除子模块,被配置为响应于接收到的定时事件,根据所述业务覆盖范围从所述预设业务类型集合中剔除已被所述新业务系统覆盖的业务类型。
进一步地,所述调整模块,还包括:
增大子模块,被配置为增大所述预设业务流量范围;和/或,
调整子模块,被配置为调整所述预设阈值。
进一步地,所述调整模块,包括:
替换子模块,被配置为在所述新业务系统针对所述预设业务类型集合的业务覆盖范围达到最大时,将当前的所述预设业务类型集合替换为新预设业务类型集合;其中,所述新预设业务类型集合中的至少一个还未被新业务系统所覆盖。
进一步地,所述调整模块,还包括:
重新设定子模块,被配置为根据所述新预设业务类型集合重新设定所述预设业务流量范围。
进一步地,所述确定模块之后,所述业务系统切换装置还包括:
生成模块,被配置为根据所述业务处理情况生成可视化的业务处理报表。
所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。
在一个可能的设计中,业务系统切换装置的结构中包括存储器和处理器,所述存储器用于存储一条或多条支持业务系统切换装置执行上述第一方面中业务系统切换方法的计算机指令,所述处理器被配置为用于执行所述存储器中存储的计算机指令。所述业务系统切换装置还可以包括通信接口,用于业务系统切换装置与其他设备或通信网络通信。
第三方面,本公开实施例提供了一种电子设备,包括存储器和处理器;其中,所述存储器用于存储一条或多条计算机指令,其中,所述一条或多条计算机指令被所述处理器执行以实现第一方面所述的方法步骤。
第四方面,本公开实施例提供了一种计算机可读存储介质,用于存储业务系统切换装置所用的计算机指令,其包含用于执行上述第一方面中业务系统切换方法所涉及的计算机指令。
本公开实施例提供的技术方案可以包括以下有益效果:
本公开实施例在接收到业务请求后,将预设业务流量范围内的业务请求发送到新业务系统,并且发送到新业务系统的业务请求的业务类型与预设业务类型集合中的至少一个业务类型相匹配;之后通过确定新业务系统对于业务请求的业务处理情况,对预设业务类型集合和预设业务流量范围进行调整。通过本公开这种方式,通过预设业务流量范围限制分发到新业务系统的业务流量,避免对新业务系统可能造成的过大压力,同时还通过预设业务类型集合以业务类型分批验证新业务系统的可用性,能够在切流过程中实时掌握新业务系统的业务覆盖范围;本公开实施例还能够通过动态调整预设业务流量范围和预设业务类型集合,使得新业务系统能够在有限的时间范围内业务类型的覆盖范围更广,最终实现新业务系统对业务类型的全面覆盖,完成新旧业务系统的切换。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
结合附图,通过以下非限制性实施方式的详细描述,本公开的其它特征、目的和优点将变得更加明显。在附图中:
图1示出根据本公开一实施方式的业务系统切换方法的流程图;
图2示出根据图1所示实施方式的步骤S101的流程图;
图3示出根据本公开一实施方式的业务系统切换装置的结构框图;
图4示出根据图3所示实施方式的分发模块301的结构框图;
图5是适于用来实现根据本公开一实施方式的业务系统切换方法的电子设备的结构示意图。
具体实施方式
下文中,将参考附图详细描述本公开的示例性实施方式,以使本领域技术人员可容易地实现它们。此外,为了清楚起见,在附图中省略了与描述示例性实施方式无关的部分。
在本公开中,应理解,诸如“包括”或“具有”等的术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在,并且不欲排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在或被添加的可能性。
另外还需要说明的是,在不冲突的情况下,本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。
由于业务复杂多样,业务系统在进行升级的过程中可以采用各种切流比对方式:单机对比、多机对比、按业务对比等;验证业务正确性后,再逐渐增大流量,直至全量切换,但对于复杂的业务系统,如何保证切流过程中在不影响正常业务运行的前提下的快速、高效、全面的切换是比较困难的。
已有技术中,在接收到业务请求后,按照业务的标识,对当前业务请求进行路由,确定将当前业务请求给新业务系统执行、原业务系统执行、还是新老业务系统都执行等。执行完成后通过比对新旧业务系统的代码或日志打印来确定新业务执行结果是否符合预期。在业务复杂、业务请求量较大的场景下通过一定时间的切流观察,然后开始进行更大业务范围,更大流量的切换。直至全部业务和流量都切换到新业务系统。
但是,已有技术方案在切流过程中并不知道每一次切流中业务的覆盖情况,每一次切换都是依赖人为经验来判断当前切换是否符合预期,然后进行下一次切换,按照决策业务与流量占比,80%的流量只会覆盖20%业务场景,所以在切流过程小众业务是否被覆盖并不清楚,同时也不知道当前切流后新业务系统已经覆盖的业务场景。
基于已有技术中存在的上述问题,本公开实施例提出了一种业务系统切换方法。该业务系统切换方法包括:将预设业务流量范围内的业务请求分发给新业务系统;其中,所述业务请求的业务类型与预设业务类型集合中的至少一个相匹配;根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况;其中,所述预期结果为原业务系统对所述业务请求的处理结果;根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围。
图1示出根据本公开一实施方式的业务系统切换方法的流程图。如图1所示,所述业务系统切换方法包括以下步骤S101-S103:
在步骤S101中,将预设业务流量范围内的业务请求分发给新业务系统;其中,所述业务请求的业务类型与预设业务类型集合中的至少一个相匹配;
在步骤S102中,根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况;其中,所述预期结果为原业务系统对所述业务请求的处理结果;
在步骤S103中,根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围。
在下文中将对步骤S101、S102和S103分别做进一步的描述。
步骤S101
业务切换的目的是将原业务系统替换成新业务系统,由新业务系统为用户提供业务服务。本实施例中,业务系统可以是任何业务系统,如数据业务系统、金融业务系统等。在新业务系统运行之初,原业务系统也在运行,在新业务系统的可用性被验证通过后,新业务系统正式上线,所有在线业务流量都分发到新业务系统,而原业务系统下线。本实施例中,预先根据实际情况设定预设业务流量范围和预设业务类型集合。预设业务类型集合包括一种或多种业务的类型标识,每个业务类型具有唯一的业务标识,每个业务请求都会携带被赋予的业务类型标识。
在一实施例中,可以将具有共同特效的多种业务类型组成一个集合,并在对新业务系统进行切流时,从中选择一个或多个集合作为预设业务类型集合,在对新业务系统进行验证时,仅将业务类型与预设业务类型集合中的至少一个相匹配的业务请求分发到新业务系统,实现新业务系统验证过程中业务的分流。
本实施例中,业务分流时,除了利用业务类型之外,还通过预设业务流量范围限定分发到新业务系统的业务流量。预设业务流量范围是指实时业务流量的占比。例如,实时业务流量为A,预设业务流量范围为50%,那么在业务系统切换方法中,预设业务范围内的业务请求为实时流量A的50%范围内的业务请求。设置预设业务流量范围,其中一个原因是针对预设业务类型集合中的业务类型在对新业务系统进行验证时,如果全部业务流量都切到新业务系统,可能会存在一种情况,即某些业务类型由于较为常见,相应的业务请求会被新业务系统在短事件内执行无数次,会造成新业务系统的资源浪费,并且该业务类型的瞬间业务流量如果较大的话,可能会造成新业务系统的奔溃。预设业务流量范围可以根据实际情况设定,例如一开始可以设定较小的预设业务流量范围,而随着时间的增加,可以慢慢加大切到新业务系统的流量,也即增大预设业务流量范围。
本实施例中,对于接收到的业务请求,首先要判断该业务请求是否属于切到新业务系统的那部分业务流量,也即该业务请求是否为预设业务流量范围内的;其次,还要判断该业务请求的业务类型是否与预设业务类型集合中的至少一个相匹配;只有在上述两个条件都满足的情况下,才将业务请求分发到新业务系统中。
步骤S102
本实施例中,新业务系统接收到业务请求后,对该业务请求进行相应地处理。在新业务系统的验证过程中,所有的业务请求都会分发到原业务系统,由原业务系统进行相应地处理,而对于业务类型与预设业务类型集中的至少一个相匹配的业务请求,如果是预设业务流量范围内的,同时也会分发给新业务系统。而真正响应用户业务请求的实际上是原业务系统,在新业务系统正式上线之前,新业务系统对业务请求的处理结果仅是用来确定新业务系统的业务处理情况的。
对于新业务系统所处理的业务请求,原业务系统也进行同样的处理。因此可以根据原业务系统得到的预期结果,与新业务系统对同一业务请求进行处理得到的处理结果来确定新业务系统的处理结果是否符合预期,并且可以结合新业务系统对其他业务类型的业务请求的处理情况,确定新业务针对预设业务类型集合的业务处理情况。业务处理情况可以是新业务系统对业务请求进行处理后,根据处理结果分析得到的一些信息,可以包括但不限于业务系统对业务请求的处理结果是否符合预期的结论信息、新业务系统对预设业务类型集合中业务类型的覆盖范围(也即新业务系统处理过预设业务类型集合中哪些业务类型对应的业务请求)以及其他相关处理情况。
步骤S103
本实施例中,可以根据新业务系统对业务请求的业务处理情况动态调整预设业务类型集合和预设业务流量范围。在一实施例中,如果新业务系统对业务请求的处理结果符合预期,则可以确定新业务系统能够正确处理相同业务类型的业务请求,因此后续可以不再对该业务类型进行验证,也即后续可以不再将该业务类型的业务请求分发到新业务系统上。而为了不再对已经验证通过的业务类型进行重复验证,可以将该业务类型从预设业务类型集合中剔除。这样,下次接收到该业务类型的业务请求时,将不再分发到新业务系统,节省了新业务系统的资源。
本实施例中,还可以根据新业务系统对业务请求的处理情况调整预设业务流量范围。在一实施例中,可以根据新业务系统对业务请求的处理情况,加大或者减少预设业务流量范围。如果对应预设业务类型集合中业务类型的业务请求较多,而设置的预设业务流量范围又过大,则可能会造成新业务系统的压力过大,因此可以相应地将预设业务流量范围调小,而如果对应预设业务集合中业务类型的业务请求较少,如果预设业务流量范围过小的话,可能会造成新业务系统空闲时间较长,降低运行效率,这时可以通过增加预设业务流量范围,提高新业务系统的运行效率。
本公开实施例的上述业务切换方式,通过预设业务流量范围限制分发到新业务系统的业务流量,避免对新业务系统可能造成的过大压力,同时还通过预设业务类型集合以业务类型分批验证新业务系统的可用性,能够在切流过程中实时掌握经过新业务系统验证的业务覆盖范围;本公开实施例还能够通过动态调整预设业务流量范围和预设业务类型集合,使得新业务系统能够在有限的时间范围内业务类型的覆盖范围更广,最终实现新业务系统对业务类型的全面覆盖,完成新旧业务系统的切换。
在本实施例的一个可选实现方式中,如图2所示,所述步骤S101,即所述将预设业务流量范围内的业务请求分发给新业务系统的步骤,进一步包括以下步骤S201-S202:
在步骤S201中,接收所述业务请求;
在步骤S202中,所述业务请求在所述预设业务流量范围内时,确定所述业务请求的所述业务类型是否与所述预设业务类型集合中的至少一个相匹配;
在步骤S203中,在所述业务请求的所述业务类型与所述预设业务类型集合中的至少一个相匹配时,将所述业务请求分发给所述新业务系统。
该可选的实现方式中,接收到业务请求后,首先确定该业务请求是否是切到新业务系统的那部分业务流量中的,也即该业务请求是否在预设业务流量范围内,如果在的话,那么再确定该业务请求的业务类型是否与预设业务类型集合中的业务类型相匹配。业务请求的业务类型可以通过业务标识来确定,每个业务请求都会携带自身的业务标识。预设业务类型集合可以包括一个或者多个业务的类型标识,在接收到业务请求后,解析业务请求中的业务标识,进而与预设业务类型集合进行匹配。在当前接收到的业务请求的业务类型与预设业务类型集合中的至少一个相匹配时,再将该业务请求分发到新业务系统。
预设业务流量范围可以根据实际情况设定,并且能够根据新业务系统对业务类型的覆盖情况动态调整。例如,实时业务流量为A,而预设业务流量范围为10%,那么可以将实时业务流量A中的10%切到新业务系统,而切到新业务系统的该10%的业务流量中,如果业务请求的业务类型与预设业务类型集合中的至少一个相匹配,才将该业务请求分发给新业务系统。通过这种方式,可以根据预设业务流量范围限制分发到新业务系统上的流量,避免在一些情况下由于分发到新业务系统上的业务请求过多,造成新业务系统的压力过大,同时还能够通过预设业务类型集合的设置有针对性的调整当前由新业务系统所验证的业务类型,通过预设业务流量范围和预设业务类型集合的配合使用,使得新业务系统能够在有限时间范围内,尽量多地覆盖业务类型。
在本实施例的一个可选实现方式中,所述步骤S102,即根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况的步骤,进一步包括以下步骤:
通过比对所述处理结果和所述预期结果确定所述处理结果是否符合预期。
该可选的实现方式中,可以通过新业务系统对业务请求的处理结果与预期结果的比对,确定新业务系统对业务请求的处理结果是否符合预期,也即新业务系统是否能够正确处理该业务请求。在一实施例中,新业务系统对业务请求的处理结果可以是处理过程中产生的日志数据,预期结果也是原业务系统对同一业务请求的处理过程中产生的日志数据,可以通过比较两个日志数据确定两者是否一致。而在另一实施例中,新业务系统对业务请求的处理结果可以是处理过程中调用的代码流程,而预期结果也是原业务系统对同一业务请求的处理过程中调用的代码流程,可以通过比较两个代码流程确定两者是否一致。如果新业务系统的处理结果与预期结果一致,则认为新业务系统对该业务请求所属业务类型的处理结果是符合预期的。通过这种方式,可以通过简单的对比就能确定新业务系统能否按照预期处理某种业务类型的业务请求。
在本实施例的一个可选实现方式中,所述步骤S102,即根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况的步骤,进一步包括以下步骤:
根据所述业务请求、所述处理结果和所述预期结果确定所述新业务系统针对所述预设业务类型集合的业务覆盖范围。
该可选的实现方式中,新业务系统针对预设业务类型集合的业务覆盖范围可以认为是在预设业务类型集合中,通过新业务系统验证过的业务类型所占的比例或者数量,也即如果新业务系统处理过预设业务类型集合中的某一个业务类型的业务请求,则可以认为新业务系统覆盖了该业务类型,而如果新业务系统没有处理过预设业务类型集合中的某一个业务类型的业务请求,则可以认为该新业务系统未覆盖该业务类型。在一实施例中,业务覆盖范围可以按照已覆盖业务类型数量与预设业务类型集合中业务类型总数之比确定。在一实施例中,业务覆盖范围可以只考虑被新业务系统所覆盖且通过了验证的业务类型,因为如果某一业务类型未通过验证,也即新业务系统对该业务类型的业务请求处理得到的处理结果与预期结果不符,那么后续需要针对该情况对新业务系统进行修正,并且在修正后还需要对该业务类型进行验证,因此这种业务类型可以认为在新业务系统的业务覆盖范围之外。而在另一实施例中,被新业务系统处理过业务请求的业务类型,无论是否通过验证,都认为该业务类型在新业务系统的业务覆盖范围内。通过本公开实施例,可以确定新业务系统针对预设业务类型结合的业务覆盖范围,能够直观地确定新业务系统的覆盖范围以及通过率。
在本实施例的一个可选实现方式中,所述步骤S103,即根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围的步骤,进一步包括以下步骤:
在所述新业务系统针对所述预设业务类型集合的业务覆盖范围达到预设阈值时,从所述预设业务类型集合中剔除已被所述新业务系统覆盖的业务类型。
在该可选的实现方式中,在新业务系统针对预设业务类型集合的业务覆盖范围达到一定程度,也即业务覆盖范围超过预设阈值时,可以调整预设业务类型集合,以将被新业务系统覆盖了的业务类型从预设业务类型集合中剔除,避免新业务系统对业务类型的重复验证,节省新业务系统的资源。如果每处理完一个业务请求,就对预设业务类型集合进行调整,由于预设业务集合的调整过于频繁,会增加成本,同时也会影响到新业务系统的实时性。因此,通过设置预设阈值,仅在新业务系统的覆盖范围超过预设阈值之后,再将已被覆盖的业务类型从预设业务类型集合中剔除,减少新业务系统的压力的同时,提高新业务系统的处理效率。
在本实施例的一个可选实现方式中,所述步骤S103,即根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围的步骤,进一步包括以下步骤:
响应于接收到的定时事件,根据所述业务覆盖范围从所述预设业务类型集合中剔除已被所述新业务系统覆盖的业务类型。
该可选的实现方式中,在定时事件的触发下,调整预设业务类型集合,以将被新业务系统覆盖了的业务类型从预设业务类型集合中剔除,避免新业务系统对业务类型的重复验证,节省新业务系统的资源。定时事件可以在预设业务类型集合初始设置完成后,新业务系统经过预定时间的运行后触发,也即在新业务系统针对当前预设业务类型集合的业务请求处理经过预定时间后触发。定时事件还可以在上一定时事件触发后经过预定时间后再触发,也即预设业务类型集合被调整后经过预定时间再触发。在一实施例中,初始设定预设业务类型集合,或者每调整一次预设业务类型集合,都可以设置一定时器,新业务系统经过一段时间的运行后,可能覆盖了预设业务类型集合中的部分业务类型,在定时器被触发后,可以将预设业务类型集合中被新业务系统覆盖的业务类型剔除,以减少对新业务系统的压力,提高新业务系统的处理效率。
在本实施例的一个可选实现方式中,所述步骤S103,即根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围的步骤,进一步包括以下步骤:
增大所述预设业务流量范围;和/或,
调整所述预设阈值。
该可选的实现方式中,针对预设业务类型集合,新业务系统处理了一段时间的业务请求后,被新业务系统所覆盖的业务类型一般是较为常见的,而一些不太常见的业务类型可能还未被覆盖,为了能够尽快覆盖这些不常见的业务类型,可以增大预设业务流量范围,这样被分流到新业务系统的业务流量中未被覆盖的业务类型的业务请求出现概率会增大,进而可以缩短预设业务类型集合的整个验证周期。在定时时间或者覆盖范围达到预设阈值时,由于被覆盖的业务类型已从预设业务类型集合中被剔除,因此即使加大预设业务流量范围,也不会对新业务系统造成很大的压力。例如,在新业务系统对预设业务类型集合中的业务类型进行验证之初,预设业务类型集合中包括100个业务类型(或是业务场景),而预设业务流量设置为总流量的10%,在经过一段时间的运行,新业务系统已经覆盖了40个业务类型,也即新业务系统已经处理过的业务请求的业务类型覆盖了预设业务类型集合中40个业务类型;那么可以将预设业务类型集合中的该40个业务类型剔除,并将预设业务流量范围加大,比如预设业务流量范围调整为总流量的40%;这是因为上述40个业务类型是较为常见的,即使在预设业务流量范围较小的情况下也能够短时间内覆盖住,而剩下的60个业务类型可能不太常见,如果预设业务流量依然较小的话,可能在很大一部分时间里新业务系统都是空闲的,会花费较长的时间才能覆盖住剩余60个业务类型,会导致整个验证周期较长。
在一实施例中,预设阈值也可以动态调整。例如,预设业务类型集合中业务类型数量较多时,可以将预设阈值设置的较小,而在预设业务类型集合被调整后,所剩余的业务类型数量变少后,可以将预设阈值增大。通过预设阈值的动态调整,可以在预设业务类型集合中业务类型数量较多的情况下,能够及时对预设业务类型集合进行调整,而在业务类型数量较少的情况下,对预设业务类型集合的调整也不会过于频繁。
在本实施例的一个可选实现方式中,所述步骤S103,即根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围的步骤,进一步包括以下步骤:
在所述新业务系统针对所述预设业务类型集合的业务覆盖范围达到最大时,将当前的所述预设业务类型集合替换为新预设业务类型集合;其中,所述新预设业务类型集合中的至少一个还未被新业务系统所覆盖。
该可选的实现方式中,预设业务类型集合中包括的业务类型可以为具有共同特性的一组业务类型,在新业务系统切流时,可以作为一个整体对新业务系统进行验证。例如对于金融业务系统,淘宝平台的所有金融业务类型可以组成一个预设业务类型集合,天猫平台的所有金融业务类型也可以组成一个预设业务类型集合。新业务系统运行之初,可以设置当前有效的预设业务类型集合,有新的业务请求时,通过与当前的预设业务类型集合进行匹配,决定是否将该业务请求分发到新业务系统。随着时间的增加,新业务系统覆盖了当前预设业务类型集合中越来越多的业务类型,并且被覆盖的这些业务类型也在动态地从预设业务类型集合中被剔除,而在新业务系统覆盖了预设业务类型集合中的全部业务类型或者绝大多数业务类型时,可以认为新业务系统覆盖了当前的预设业务类型集合,也即无需再针对预设业务类型集合进行新业务系统验证,这时可以切换到下一个新预设业务类型集合。新预设业务类型集合中的至少一个还未被新业务系统所覆盖,在将当前的预设业务类型集合替换成新预设业务类型集合后,继续针对该新预设业务类型集合进行同样的验证过程。
在一实施例中,新业务系统针对预设业务类型集合的业务覆盖范围达到最大包括但不限于:新业务系统覆盖了预设业务类型集合中的所有业务类型或者新业务系统覆盖了预设业务类型集合中的绝大多数的业务类型(也即新业务系统所覆盖的业务类型数量超过了预设数量)。通过这种方式,可以将业务类型进行分组,并使得新业务系统分别针对不同业务类型组合进行验证,能够灵活调整切流策略,且能够全面了解新业务系统在验证过程中的业务覆盖情况。
在本实施例的一个可选实现方式中,所述步骤S103,即根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围的步骤,进一步包括以下步骤:
根据所述新预设业务类型集合重新设定所述预设业务流量范围。
在该可选的实施例中,在将原来的预设业务类型集合替换成新预设业务类型集合后,可以根据新预设业务类型集合的实际情况重新设定预设业务流量范围。针对原来的预设业务类型集合进行新业务系统验证时,由于随着新业务系统对原来的预设业务类型集合的业务覆盖范围的增大,预设业务流量范围也在动态调整,而替换成新预设业务类型集合后,当前的预设业务流量范围可能已经不再适用于新预设业务类型集合,因此可以将预设业务流量范围调整为原始的预设业务流量范围,也可以根据新预设业务类型集合的实际情况重新设定预设业务流量范围,以便在不对新业务系统造成太大压力的情况下,使得新业务系统尽可能快的覆盖新预设业务类型集合中的业务类型。
在本实施例的一个可选实现方式中,所述步骤S102,即根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况之后,所述业务系统切换方法还进一步包括以下步骤:
根据所述业务处理情况生成可视化的业务处理报表。
该可选的实现方式中,在新业务系统处理完业务请求后,可以根据新业务系统的处理结果与预期结果的一致性、新业务系统所覆盖的业务类型、新业务系统未覆盖的业务类型以及新业务系统已覆盖但未验证通过的业务类型等生成各种可视化的业务处理报表。可视化的业务处理报表可以提供给相关人员,相关人员能够从可视化业务处理报表快速直观地了解到新业务系统的当前业务覆盖情况,并且为动态调整切流策略提供了数据支撑。业务处理报表可以包括但不限于:业务类型覆盖范围报表、业务流量分流比例报表和未覆盖业务类型报表等。业务类型覆盖范围报表用于可视化地显示新业务系统所覆盖的业务类型的比例;业务流量分流比例报表可以可视化地显示当前分流到新业务系统的流量占总流量的比例,也即当前的预设业务流量范围;未覆盖业务类型报表可以包括未被新业务类型覆盖的业务类型数量、类型标识等。通过从多维度建立可视化业务处理报表,有利于高效、快捷的验证新业务系统,并最终实现新业务系统的切换。
下述为本公开装置实施例,可以用于执行本公开方法实施例。
图3示出根据本公开一实施方式的业务系统切换装置的结构框图,该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图3所示,所述业务系统切换装置包括分发模块301、确定模块302和调整模块303:
分发模块301,被配置为将预设业务流量范围内的业务请求分发给新业务系统;其中,所述业务请求的业务类型与预设业务类型集合中的至少一个相匹配;
确定模块302,被配置为根据预期结果和所述新业务系统对所述业务请求的处理结果,确定所述新业务系统针对所述预设业务类型集合的业务处理情况;其中,所述预期结果为原业务系统对所述业务请求的处理结果;
调整模块303,被配置为根据所述业务处理情况调整所述预设业务类型集合和所述预设业务流量范围。
在下文中将对分发模块301、确定模块302和调整模块303分别做进一步的描述。
分发模块301
在一实施例中,可以将具有共同特效的多种业务类型组成一个集合,并在对新业务系统进行切流时,从中选择一个或多个集合作为预设业务类型集合,分发模块301在对新业务系统进行验证时,仅将业务类型与预设业务类型集合中的至少一个相匹配的业务请求分发到新业务系统,实现新业务系统验证过程中业务的分流。
本实施例中,业务分流时,除了利用业务类型之外,分发模块301还通过预设业务流量范围限定分发到新业务系统的业务流量。预设业务流量范围是指实时业务流量的占比。例如,实时业务流量为A,预设业务流量范围为50%,那么在业务系统切换方法中,预设业务范围内的业务请求为实时流量A的50%范围内的业务请求。设置预设业务流量范围,其中一个原因是针对预设业务类型集合中的业务类型在对新业务系统进行验证时,如果全部业务流量都切到新业务系统,可能会存在一种情况,即某些业务类型由于较为常见,相应的业务请求会被新业务系统在短事件内执行无数次,会造成新业务系统的资源浪费,并且该业务类型的瞬间业务流量如果较大的话,可能会造成新业务系统的奔溃。预设业务流量范围可以根据实际情况设定,例如一开始可以设定较小的预设业务流量范围,而随着时间的增加,可以慢慢加大切到新业务系统的流量,也即增大预设业务流量范围。
本实施例中,对于接收到的业务请求,分发模块301首先要判断该业务请求是否属于切到新业务系统的那部分业务流量,也即该业务请求是否为预设业务流量范围内的;其次,分发模块301还要判断该业务请求的业务类型是否与预设业务类型集合中的至少一个相匹配;只有在上述两个条件都满足的情况下,才将业务请求分发到新业务系统中。
确定模块302
本实施例中,新业务系统接收到业务请求后,对该业务请求进行相应地处理。在新业务系统的验证过程中,所有的业务请求都会分发到原业务系统,由原业务系统进行相应地处理,而对于业务类型与预设业务类型集中的至少一个相匹配的业务请求,如果是预设业务流量范围内的,同时也会分发给新业务系统。而真正响应用户业务请求的实际上是原业务系统,在新业务系统正式上线之前,新业务系统对业务请求的处理结果仅是用来确定新业务系统的业务处理情况的。
对于新业务系统所处理的业务请求,原业务系统也进行同样的处理。因此,确定模块302可以根据原业务系统得到的预期结果,与新业务系统对同一业务请求进行处理得到的处理结果来确定新业务系统的处理结果是否符合预期,并且可以结合新业务系统对其他业务类型的业务请求的处理情况,确定新业务针对预设业务类型集合的业务处理情况。业务处理情况可以是新业务系统对业务请求进行处理后,根据处理结果分析得到的一些信息,可以包括但不限于业务系统对业务请求的处理结果是否符合预期的结论信息、新业务系统对预设业务类型集合中业务类型的覆盖范围(也即新业务系统处理过预设业务类型集合中哪些业务类型对应的业务请求)以及其他相关处理情况。
调整模块303
本实施例中,调整模块303可以根据新业务系统对业务请求的业务处理情况动态调整预设业务类型集合和预设业务流量范围。在一实施例中,如果新业务系统对业务请求的处理结果符合预期,则可以确定新业务系统能够正确处理相同业务类型的业务请求,因此后续可以不再对该业务类型进行验证,也即后续可以不再将该业务类型的业务请求分发到新业务系统上。而为了不再对已经验证通过的业务类型进行重复验证,调整模块303可以将该业务类型从预设业务类型集合中剔除。这样,下次接收到该业务类型的业务请求时,将不再分发到新业务系统,节省了新业务系统的资源。
本实施例中,调整模块303还可以根据新业务系统对业务请求的处理情况调整预设业务流量范围。在一实施例中,调整模块303可以根据新业务系统对业务请求的处理情况,加大或者减少预设业务流量范围。如果对应预设业务类型集合中业务类型的业务请求较多,而设置的预设业务流量范围又过大,则可能会造成新业务系统的压力过大,因此可以相应地将预设业务流量范围调小,而如果对应预设业务集合中业务类型的业务请求较少,如果预设业务流量范围过小的话,可能会造成新业务系统空闲时间较长,降低运行效率,这时可以通过增加预设业务流量范围,提高新业务系统的运行效率。
本公开实施例的上述业务切换方式,通过预设业务流量范围限制分发到新业务系统的业务流量,避免对新业务系统可能造成的过大压力,同时还通过预设业务类型集合以业务类型分批验证新业务系统的可用性,能够在切流过程中实时掌握经过新业务系统验证的业务覆盖范围;本公开实施例还能够通过动态调整预设业务流量范围和预设业务类型集合,使得新业务系统能够在有限的时间范围内业务类型的覆盖范围更广,最终实现新业务系统对业务类型的全面覆盖,完成新旧业务系统的切换。
在本实施例的一个可选实现方式中,如图4所示,所述分发模块301,包括:
接收子模块401,被配置为接收所述业务请求;
第一确定子模块402,被配置为所述业务请求在所述预设业务流量范围内时,确定所述业务请求的所述业务类型是否与所述预设业务类型集合中的至少一个相匹配;
分发子模块403,被配置为在所述业务请求的所述业务类型与所述预设业务类型集合中的至少一个相匹配时,将所述业务请求分发给所述新业务系统。
该可选的实现方式中,接收子模块401接收到业务请求后,第一确定子模块402首先确定该业务请求是否是切到新业务系统的那部分业务流量中的,也即该业务请求是否在预设业务流量范围内,如果在的话,那么再确定该业务请求的业务类型是否与预设业务类型集合中的业务类型相匹配。业务请求的业务类型可以通过业务标识来确定,每个业务请求都会携带自身的业务标识。预设业务类型集合可以包括一个或者多个业务的类型标识,在接收到业务请求后,解析业务请求中的业务标识,进而与预设业务类型集合进行匹配。在当前接收到的业务请求的业务类型与预设业务类型集合中的至少一个相匹配时,分发子模块403再将该业务请求分发到新业务系统。
预设业务流量范围可以根据实际情况设定,并且能够根据新业务系统对业务类型的覆盖情况动态调整。例如,实时业务流量为A,而预设业务流量范围为10%,那么可以将实时业务流量A中的10%切到新业务系统,而切到新业务系统的该10%的业务流量中,如果业务请求的业务类型与预设业务类型集合中的至少一个相匹配,才将该业务请求分发给新业务系统。通过这种方式,可以根据预设业务流量范围限制分发到新业务系统上的流量,避免在一些情况下由于分发到新业务系统上的业务请求过多,造成新业务系统的压力过大,同时还能够通过预设业务类型集合的设置有针对性的调整当前由新业务系统所验证的业务类型,通过预设业务流量范围和预设业务类型集合的配合使用,使得新业务系统能够在有限时间范围内,尽量多地覆盖业务类型。
在本实施例的一个可选实现方式中,所述确定模块302,包括:
第二确定子模块,被配置为通过比对所述处理结果和所述预期结果确定所述处理结果是否符合预期。
该可选的实现方式中,第二确定子模块可以通过新业务系统对业务请求的处理结果与预期结果的比对,确定新业务系统对业务请求的处理结果是否符合预期,也即新业务系统是否能够正确处理该业务请求。在一实施例中,新业务系统对业务请求的处理结果可以是处理过程中产生的日志数据,预期结果也是原业务系统对同一业务请求的处理过程中产生的日志数据,第二确定子模块可以通过比较两个日志数据确定两者是否一致。而在另一实施例中,新业务系统对业务请求的处理结果可以是处理过程中调用的代码流程,而预期结果也是原业务系统对同一业务请求的处理过程中调用的代码流程,第二确定子模块可以通过比较两个代码流程确定两者是否一致。如果新业务系统的处理结果与预期结果一致,则认为新业务系统对该业务请求所属业务类型的处理结果是符合预期的。通过这种方式,可以通过简单的对比就能确定新业务系统能否按照预期处理某种业务类型的业务请求。
在本实施例的一个可选实现方式中,所述确定模块,包括:
第三确定子模块,被配置为根据所述业务请求、所述处理结果和所述预期结果确定所述新业务系统针对所述预设业务类型集合的业务覆盖范围。
该可选的实现方式中,新业务系统针对预设业务类型集合的业务覆盖范围可以认为是在预设业务类型集合中,通过新业务系统验证过的业务类型所占的比例或者数量,也即如果新业务系统处理过预设业务类型集合中的某一个业务类型的业务请求,则可以认为新业务系统覆盖了该业务类型,而如果新业务系统没有处理过预设业务类型集合中的某一个业务类型的业务请求,则可以认为该新业务系统未覆盖该业务类型。在一实施例中,业务覆盖范围可以按照已覆盖业务类型数量与预设业务类型集合中业务类型总数之比确定。在一实施例中,业务覆盖范围可以只考虑被新业务系统所覆盖且通过了验证的业务类型,因为如果某一业务类型未通过验证,也即新业务系统对该业务类型的业务请求处理得到的处理结果与预期结果不符,那么后续需要针对该情况对新业务系统进行修正,并且在修正后还需要对该业务类型进行验证,因此这种业务类型可以认为在新业务系统的业务覆盖范围之外。而在另一实施例中,被新业务系统处理过业务请求的业务类型,无论是否通过验证,都认为该业务类型在新业务系统的业务覆盖范围内。通过本公开实施例,可以确定新业务系统针对预设业务类型结合的业务覆盖范围,能够直观地确定新业务系统的覆盖范围以及通过率。
在本实施例的一个可选实现方式中,所述调整模块,包括:
第一剔除子模块,被配置为在所述新业务系统针对所述预设业务类型集合的业务覆盖范围达到预设阈值时,从所述预设业务类型集合中剔除已被所述新业务系统覆盖的业务类型。
在该可选的实现方式中,在新业务系统针对预设业务类型集合的业务覆盖范围达到一定程度,也即业务覆盖范围超过预设阈值时,第一剔除子模块可以调整预设业务类型集合,以将被新业务系统覆盖了的业务类型从预设业务类型集合中剔除,避免新业务系统对业务类型的重复验证,节省新业务系统的资源。如果每处理完一个业务请求,就对预设业务类型集合进行调整,由于预设业务集合的调整过于频繁,会增加成本,同时也会影响到新业务系统的实时性。因此,通过设置预设阈值,第一剔除子模块仅在新业务系统的覆盖范围超过预设阈值之后,再将已被覆盖的业务类型从预设业务类型集合中剔除,减少新业务系统的压力的同时,提高新业务系统的处理效率。
在本实施例的一个可选实现方式中,所述调整模块,包括:
第二剔除子模块,被配置为响应于接收到的定时事件,根据所述业务覆盖范围从所述预设业务类型集合中剔除已被所述新业务系统覆盖的业务类型。
该可选的实现方式中,在定时事件的触发下,第二剔除子模块调整预设业务类型集合,以将被新业务系统覆盖了的业务类型从预设业务类型集合中剔除,避免新业务系统对业务类型的重复验证,节省新业务系统的资源。定时事件可以在预设业务类型集合初始设置完成后,新业务系统经过预定时间的运行后触发,也即在新业务系统针对当前预设业务类型集合的业务请求处理经过预定时间后触发。定时事件还可以在上一定时事件触发后经过预定时间后再触发,也即预设业务类型集合被调整后经过预定时间再触发。在一实施例中,初始设定预设业务类型集合,或者每调整一次预设业务类型集合,都可以设置一定时器,新业务系统经过一段时间的运行后,可能覆盖了预设业务类型集合中的部分业务类型,在定时器被触发后,第二剔除子模块可以将预设业务类型集合中被新业务系统覆盖的业务类型剔除,以减少对新业务系统的压力,提高新业务系统的处理效率。
在本实施例的一个可选实现方式中,所述调整模块,还包括:
增大子模块,被配置为增大所述预设业务流量范围;和/或,
调整子模块,被配置为调整所述预设阈值。
该可选的实现方式中,针对预设业务类型集合,新业务系统处理了一段时间的业务请求后,被新业务系统所覆盖的业务类型一般是较为常见的,而一些不太常见的业务类型可能还未被覆盖,为了能够尽快覆盖这些不常见的业务类型,增大子模块可以增大预设业务流量范围,这样被分流到新业务系统的业务流量中未被覆盖的业务类型的业务请求出现概率会增大,进而可以缩短预设业务类型集合的整个验证周期。在定时时间或者覆盖范围达到预设阈值时,由于被覆盖的业务类型已从预设业务类型集合中被剔除,因此即使加大预设业务流量范围,也不会对新业务系统造成很大的压力。例如,在新业务系统对预设业务类型集合中的业务类型进行验证之初,预设业务类型集合中包括100个业务类型(或是业务场景),而预设业务流量设置为总流量的10%,在经过一段时间的运行,新业务系统已经覆盖了40个业务类型,也即新业务系统已经处理过的业务请求的业务类型覆盖了预设业务类型集合中40个业务类型;那么可以将预设业务类型集合中的该40个业务类型剔除,并将预设业务流量范围加大,比如预设业务流量范围调整为总流量的40%;这是因为上述40个业务类型是较为常见的,即使在预设业务流量范围较小的情况下也能够短时间内覆盖住,而剩下的60个业务类型可能不太常见,如果预设业务流量依然较小的话,可能在很大一部分时间里新业务系统都是空闲的,会花费较长的时间才能覆盖住剩余60个业务类型,会导致整个验证周期较长。
在一实施例中,预设阈值也可以动态调整。例如,预设业务类型集合中业务类型数量较多时,调整子模块可以将预设阈值设置的较小,而在预设业务类型集合被调整后,所剩余的业务类型数量变少后,调整子模块可以将预设阈值增大。通过预设阈值的动态调整,可以在预设业务类型集合中业务类型数量较多的情况下,能够及时对预设业务类型集合进行调整,而在业务类型数量较少的情况下,对预设业务类型集合的调整也不会过于频繁。
在本实施例的一个可选实现方式中,所述调整模块,包括:
替换子模块,被配置为在所述新业务系统针对所述预设业务类型集合的业务覆盖范围达到最大时,将当前的所述预设业务类型集合替换为新预设业务类型集合;其中,所述新预设业务类型集合中的至少一个还未被新业务系统所覆盖。
该可选的实现方式中,预设业务类型集合中包括的业务类型可以为具有共同特性的一组业务类型,在新业务系统切流时,可以作为一个整体对新业务系统进行验证。例如对于金融业务系统,淘宝平台的所有金融业务类型可以组成一个预设业务类型集合,天猫平台的所有金融业务类型也可以组成一个预设业务类型集合。新业务系统运行之初,可以设置一当前有效的预设业务类型集合,有新的业务请求时,通过与当前的预设业务类型集合进行匹配,决定是否将该业务请求分发到新业务系统。随着时间的增加,新业务系统覆盖了当前预设业务类型集合中越来越多地业务类型,并且被覆盖的这些业务类型也在动态地从预设业务类型集合中被剔除,而在新业务系统覆盖了预设业务类型集合中的全部业务类型或者绝大多数业务类型时,可以认为新业务系统覆盖了当前的预设业务类型集合,也即无需再针对预设业务类型集合进行新业务系统验证,这时可以切换到下一个新预设业务类型集合。新预设业务类型集合中的至少一个还未被新业务系统所覆盖,在将当前的预设业务类型集合替换成新预设业务类型集合后,继续针对该新预设业务类型集合进行同样的验证过程。
在一实施例中,新业务系统针对预设业务类型集合的业务覆盖范围达到最大包括但不限于:新业务系统覆盖了预设业务类型集合中的所有业务类型或者新业务系统覆盖了预设业务类型集合中的绝大多数的业务类型(也即新业务系统所覆盖的业务类型数量超过了预设数量)。通过这种方式,可以将业务类型进行分组,并使得新业务系统分别针对不同业务类型组合进行验证,能够灵活调整切流策略,且能够全面了解新业务系统在验证过程中的业务覆盖情况。
在本实施例的一个可选实现方式中,所述调整模块,还包括:
重新设定子模块,被配置为根据所述新预设业务类型集合重新设定所述预设业务流量范围。
在该可选的实施例中,在将原来的预设业务类型集合替换成新预设业务类型集合后,重新设定子模块可以根据新预设业务类型集合的实际情况重新设定预设业务流量范围。针对原来的预设业务类型集合进行新业务系统验证时,由于随着新业务系统对原来的预设业务类型集合的业务覆盖范围的增大,预设业务流量范围也在动态调整,而替换成新预设业务类型集合后,当前的预设业务流量范围可能已经不再适用于新预设业务类型集合,因此重新设定子模块可以将预设业务流量范围调整为原始的预设业务流量范围,也可以根据新预设业务类型集合的实际情况重新设定预设业务流量范围,以便在不对新业务系统造成太大压力的情况下,使得新业务系统尽可能快的覆盖新预设业务类型集合中的业务类型。
在本实施例的一个可选实现方式中,所述确定模块之后,所述业务系统切换装置还包括:
生成模块,被配置为根据所述业务处理情况生成可视化的业务处理报表。
该可选的实现方式中,在新业务系统处理完业务请求后,生成模块可以根据新业务系统的处理结果与预期结果的一致性、新业务系统所覆盖的业务类型、新业务系统未覆盖的业务类型以及新业务系统已覆盖但未验证通过的业务类型等生成各种可视化的业务处理报表。可视化的业务处理报表可以提供给相关人员,相关人员能够从可视化业务处理报表快速直观地了解到新业务系统的当前业务覆盖情况,并且为动态调整切流策略提供了数据支撑。业务处理报表可以包括但不限于:业务类型覆盖范围报表、业务流量分流比例报表和未覆盖业务类型报表等。业务类型覆盖范围报表用于可视化地显示新业务系统所覆盖的业务类型的比例;业务流量分流比例报表可以可视化地显示当前分流到新业务系统的流量占总流量的比例,也即当前的预设业务流量范围;未覆盖业务类型报表可以包括未被新业务类型覆盖的业务类型数量、类型标识等。通过从多维度建立可视化业务处理报表,有利于高效、快捷的验证新业务系统,并最终实现新业务系统的切换。
图5是适于用来实现根据本公开实施方式的业务系统切换方法的电子设备的结构示意图。
如图5所示,电子设备500包括中央处理单元(CPU)501,其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行上述图1所示的实施方式中的各种处理。在RAM503中,还存储有电子设备500操作所需的各种程序和数据。CPU501、ROM502以及RAM503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。
以下部件连接至I/O接口505:包括键盘、鼠标等的输入部分506;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507;包括硬盘等的存储部分508;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器510上,以便于从其上读出的计算机程序根据需要被安装入存储部分508。
特别地,根据本公开的实施方式,上文参考图1描述的方法可以被实现为计算机软件程序。例如,本公开的实施方式包括一种计算机程序产品,其包括有形地包含在及其可读介质上的计算机程序,所述计算机程序包含用于执行图1的方法的程序代码。在这样的实施方式中,该计算机程序可以通过通信部分509从网络上被下载和安装,和从可拆卸介质511被安装。
附图中的流程图和框图,图示了按照本公开各种实施方式的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,路程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和流程图中的每个方框、以及框图和流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开实施方式中所涉及到的单元或模块可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中,这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。
作为另一方面,本公开还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施方式中所述装置中所包含的计算机可读存储介质;也可以是单独存在,未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序,所述程序被一个或者一个以上的处理器用来执行描述于本公开的方法。
以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本公开中所涉及的发明范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离所述发明构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。