CN117395227A - 业务处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开提出一种业务处理方法、装置、电子设备及存储介质，涉及通信技术领域。具体实现方案为：首先接收第一业务处理请求，并确定运行在各通信网络中的服务器当前的运行状态，然后基于每个服务器当前的运行状态及第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求，之后将第二业务处理请求发送给域名解析服务器，以获取域名解析服务器返回的目标服务器的地址，最后返回目标服务器的地址。由此，通过将对服务器运行状态的监测串行在业务流程中，不引入额外时延，还实现了智能域名解析系统的独立统一，从而提高了域名解析系统的通用性及实用性。

Description

业务处理方法、装置、电子设备及存储介质

技术领域

本公开涉及通信技术领域，具体涉及一种业务处理方法、装置、电子设备及存储介质。

背景技术

随着移动互联网的发展以及各种新兴业务的出现，网络时延对业务的影响愈发凸显，智能域名解析系统应运而生，使得针对不同用户对同一个域名的请求，服务器可以返回不同的IP地址，实现了用户不跨网、就近访问服务器，提升了用户的业务感知。

但是，现有的智能域名解析技术支持的业务范围窄，业务处理时延大，且独立性差。

发明内容

本公开旨在至少在一定程度上解决相关技术中的技术问题之一。

本公开第一方面实施例提出了一种业务处理方法，所述方法由预处理服务器执行，包括：

接收第一业务处理请求，其中，所述第一业务处理请求中包括第一源地址；

确定运行在各通信网络中的服务器当前的运行状态；

基于每个所述服务器当前的运行状态及所述第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求；

将所述第二业务处理请求发送给域名解析服务器，以获取所述域名解析服务器返回的所述目标服务器的地址；

返回所述目标服务器的地址。

本公开第二方面实施例提出了一种业务处理方法，所述方法由域名解析服务器执行，包括：

接收预处理服务器发送的第二业务处理请求，其中，所述第二业务处理请求为预处理服务器基于接收的第一业务处理请求生成的；

对所述第二业务处理请求进行解析，以确定所述第二业务处理请求中包括的第二源地址；

基于所述第二源地址的类型，确定目标服务器的地址；

向所述预处理服务器返回所述目标服务器的地址。

本公开第三方面实施例提出了一种业务处理装置，所述装置配置在预处理服务器中，包括：

第一接收模块，用于接收第一业务处理请求，其中，所述第一业务处理请求中包括第一源地址；

第一确定模块，用于确定运行在各通信网络中的服务器当前的运行状态；

生成模块，用于基于每个所述服务器当前的运行状态及所述第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求；

发送模块，用于将所述第二业务处理请求发送给域名解析服务器，以获取所述域名解析服务器返回的所述目标服务器的地址；

第一返回模块，用于返回所述目标服务器的地址。

本公开第四方面实施例提出了一种业务处理装置，所述装置配置在域名解析服务器中，包括：

第二接收模块，用于接收预处理服务器发送的第二业务处理请求，其中，所述第二业务处理请求为预处理服务器基于接收的第一业务处理请求生成的；

解析模块，用于对所述第二业务处理请求进行解析，以确定所述第二业务处理请求中包括的第二源地址；

第二确定模块，用于基于所述第二源地址的类型，确定目标服务器的地址；

第二返回模块，用于向所述预处理服务器返回所述目标服务器的地址。

本公开第五方面实施例提出了一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如本公开第一方面、第二方面实施例提出的业务处理方法。

本公开第六方面实施例提出了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，实现如本公开第一方面、第二方面实施例提出的业务处理方法。

本公开第七方面实施例提出了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时，实现如本公开第一方面、第二方面实施例提出的业务处理方法。

本公开提供的业务处理方法、装置、计算机设备及存储介质，存在如下有益效果：

本公开实施例中，首先预处理服务器接收第一业务处理请求，并确定运行在各通信网络中的服务器当前的运行状态，然后基于每个服务器当前的运行状态及第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求，之后将第二业务处理请求发送给域名解析服务器。域名解析服务器接收到预处理服务器发送的第二业务处理请求后，对第二业务处理请求进行解析，以确定第二业务处理请求中包括的第二源地址，之后基于第二源地址的类型，确定目标服务器的地址，最后向预处理服务器返回目标服务器的地址，并由预处理服务器返回目标服务器的地址。由此，从而不仅提高了域名解析服务器的强壮性和容灾性，实现了精准调度，保障了用户感知，还实现了智能域名解析系统的独立统一，从而提高了域名解析系统的通用性及实用性。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1为相关技术中智能域名解析系统的结构示意图；

图2为本公开实施例提供的一种智能域名解析系统的结构和功能示意图；

图3为本公开一实施例所提供的一种业务处理方法的流程示意图；

图4为本公开实施例提供的一种预处理服务器的结构和功能示意图；

图5为本公开一实施例所提供的一种业务处理方法的流程示意图；

图6为本公开一实施例所提供的一种业务处理方法的流程示意图；

图7为本公开实施例提供的一种域名解析服务器的结构和功能示意图；

图8为本公开一实施例所提供的一种业务处理装置的结构示意图；

图9为本公开一实施例所提供的一种业务处理装置的结构示意图；

图10示出了适于用来实现本公开实施方式的示例性计算机设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

如图1所示，图1为相关技术中智能域名解析系统的结构示意图，图1中，数字1-10为用户访问服务器的步骤，其中，步骤1为用户发送查询服务器IP地址的请求，步骤2-7为智能域名解析系统迭代查询，得到用户请求的对应的目标服务器IP地址的过程，步骤8为智能域名解析器向用户返回服务器IP地址的过程，步骤9-10为用户与服务器通信交互的过程。如图1所示，智能域名解析系统作为一个孤立的系统，没有在域名解析系统内部与外部进行联动。

部分要求较高的业务会另外在超文本传输协议(Hyper Text TransferProtocol，HTTP)层面设置反向代理，然后代理服务器与互联网内容提供商的多个服务器进行连接，包括超文本传输协议域名系统(Hyper Text Transfer Protocol Domain NameSystem，HTTPDNS)层面或HTTP业务层面，首选的服务器如果不能用，则切换到另一台服务器连接，直到能用为止，保证业务容灾性能。

因此现有的智能域名解析系统存在以下缺点：

1、HTTP反向代理只支持HTTP协议，如果业务使用的是非HTTP协议(如文件传输协议(File Transfer Protocol，FTP)协议)或者加密的超文本传输协议(Hyper TextTransfer Protocol Secure，HTTPS)，则无法支持；

2、HTTP反向代理在传输层使用的是传输控制协议(Transmission ControlProtocol，TCP)，用户到代理服务器、代理服务器到源站服务器建链时均会用到三次握手，一次访问至少用到2次三次握手的时间，时延比较大，如果第一次链接的服务器故障，则这个时延还要更大；

3、独立性差，不属于一个企业可以打包使用的系统。现有方案是在域名解析系统无法做到具备容灾备份能力时，在业务侧搭建一个反向代理的中间服务器用于弥补，且这个需要与运营商进行合作，强制引流到代理服务器，灵活性很弱。

本公开针对上述问题，提出一种业务处理方法，对现有的智能域名解析系统进行优化，如图2所示，图2为本公开实施例提供的一种智能域名解析系统的结构和功能示意图，图2中，Netfilter为网络过滤器，nat为网络地址转换(Network Address Translation，NAT)，DNS为域名系统(Domain Name System，DNS)，假设运行在第一通信网络中的网站服务器的IP地址为a.a.a.a，运行在第二通信网络中的网站服务器的IP地址为b.b.b.b，运行在第三通信网络中的网站服务器的IP地址为c.c.c.c。

1、网站运行状态实时监测能力：通过编写一个监测网站服务器运行状态的程序，比如使用开源Python软件编写监测程序(通过调用Python的三方库Requests，time，os即可实现)，然后再配置一个永久循环，实时监测网站运行状态，并将运行状态作为后续决策开关防火墙(iptables)进程使用。

2、灵活的NAT能力：比如，使用Linux子系统Netfilter所提供的NAT服务，配置多个NAT配置文件，对DNS请求报文按照归属的通信网络来区分源IP地址，把报文的源地址nat为某特定IP地址，便于后端智能权威域名解析模块调度使用。

3、严密的衔接和完善的系统架构：前端实时监测与预处置模块先使用python程序实时监测网站运行状态，再把运行状态输出去决策开关NAT服务，开关NAT服务输出不同的源IP地址，又作为后端智能域名解析模块进行归类判断的依据，回复最优的结果给用户。各流程严密衔接，构造一个完善的系统架构，打造出一个非常实用的全业务不中断的智能域名解析系统。

由此，通过在传统域名解析的前端架设一套对网站所有服务器运行状态的监测装置，并将监测结果与智能域名解析装置进行联动，通过将对服务器运行状态的监测串行在业务流程中，不引入额外时延，还实现了智能域名解析系统的独立统一，从而提高了域名解析系统的通用性及实用性。

下面参考附图描述本公开实施例的业务处理方法、装置、电子设备和存储介质。

下面结合图3以预处理服务器执行为例，对本公开提供的业务处理方法进行详细说明。图3为本公开实施例所提供的一种业务处理方法的流程示意图。如图3所示，该业务处理方法可以包括以下步骤：

步骤301，接收第一业务处理请求，其中，第一业务处理请求中包括第一源地址。

其中，预处理服务器中，可以包括服务器运行状态监测装置及网络地址转换(Network Address Translation，NAT)装置，其可以为一个独立的设备，或者也可以为与域名解析服务器一体设置的一个功能模块，本公开对此不做限定。

其中，第一业务处理请求，为预处理服务器接收的，由用户发送的域名系统(Domain Name System，DNS)请求报文，用来请求某一业务的服务器地址。

其中，第一源地址，为发送第一业务处理请求的用户当前使用的业务的域名地址，比如，第一源地址为www.×××.com。

步骤302，确定运行在各通信网络中的服务器当前的运行状态。

在一些可能的实现形式中，可以首先获取每个用于探测服务器端口的连通状态的测试服务当前的返回值，然后根据每个测试服务当前的返回值，确定每个服务器当前的运行状态。

其中，测试服务，为用来测试服务器端口连通状态的服务。其可以通过向服务器端口发送连接请求，并基于接收到的返回值，确定服务器当前的运行状态。

其中，返回值，为预设的用来表示服务器端口连通状态的标识，其可以通过取特定值的形式来标识服务器端口的连通状态，或者还可以通过其他的实现形式来进行标识。比如，返回值为“0”时，可以认为对应的服务器端口处于非连通状态，返回值为“1”时，可以认为对应的服务器端口处于连通状态，本公开对此不做限定。

本公开中，预处理服务器实时监测部署在各通信网络中的业务服务器的运行状态是否异常，若某一服务器端口处于连通状态，则认为该服务器的运行状态非异常。若某一服务器端口处于非连通状态，则认为该服务器的运行状态异常。

其中，步骤301、步骤302的执行顺序可以互换，或者也可以同时执行。

步骤303，基于每个服务器当前的运行状态及第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求。

其中，第二业务处理请求，为基于第一业务处理请求生成的，用来请求目标服务器地址的域名解析请求。

其中，第一通信网络，为第一源地址所属的通信网络，其可能为任一运营商提供的通信网络。

在一些可能的实现形式中，在每个服务器当前的运行状态非异常的情况下，将第一业务处理请求确定为第二业务处理请求。

本公开中，在每个服务器当前的运行状态非异常的情况下，预处理服务器不对第一业务处理请求做任何处理，直接将第一业务处理请求确定为第二业务处理请求，来为用户请求第一通信网络内的目标服务器的地址。

在一些可能的实现形式中，在任一服务器当前的运行状态异常的情况下，可以确定任一服务器所在的第二通信网络，然后在第二通信网络与第一通信网络相同的情况下，利用预设的第二源地址替换第一业务处理请求中的第一源地址，以获取第二业务处理请求。

其中，预设的第二源地址，为预处理服务器通过调用NAT服务，对第一源地址进行转换后，生成的地址。

需要说明的是，不同的通信网络，对应的NAT服务可以相同也可以不同；或者，不同的NAT服务转换后的第二源地址可以相同也可以不同。

本公开中，在任一服务器当前的运行状态异常的情况下，预处理服务器根据监测结果，发现任一运行状态异常的服务器所在的第二通信网络为第一通信网络，就调用NAT服务，将第一业务处理请求中的第一源地址替换为预设的第二源地址，并生成第二业务处理请求。

在一些可能的实现形式中，在任一服务器当前的运行状态异常的情况下，可以确定任一服务器所在的第二通信网络，然后在第二通信网络与第一通信网络不同的情况下，将第一业务处理请求确定为第二业务处理请求。

本公开中，在任一服务器当前的运行状态异常的情况下，预处理服务器根据监测结果，发现任一运行状态异常的服务器所在的第二通信网络，与第一通信网络不同时，将不对第一业务处理请求进行处理，直接将其确定为第二业务处理请求。

步骤304，将第二业务处理请求发送给域名解析服务器，以获取域名解析服务器返回的目标服务器的地址。

其中，目标服务器，可以为运行在第一通信网络中的服务器，或者也可以为包括运行在每个通信网络中的服务器，本公开对此不做限定。

本公开中，预处理服务器将第二业务处理请求发送给域名解析服务器后，可以获取到域名解析服务器返回的目标服务器的地址。

下面以图4为例，对本公开实施例提供的预处理服务器进行说明，图4为本公开实施例提供的一种预处理服务器的结构和功能示意图。图4中，Netfilter为网络过滤器，NAT为网络地址转换(Network Address Translation，NAT)，DNS为域名系统(Domain NameSystem，DNS)。

本公开提供的预处理服务器，以使用Linux子系统Netfilter搭建NAT服务为例。在服务器运行非异常的情况下，数据转发不经过NAT处理，而当服务器运行状态监测装置监测到某通信网络内的业务服务器运行状态异常时，才对该服务器所归属的通信网络内的用户发送过来的DNS请求报文进行NAT处理，之后将DNS请求报文发送给域名解析服务器。

另外，可以针对各通信网络配置NAT配置文件，其中包含NATStart和NATStop两个文件。例如需要启动某通信网络用户的NAT服务，就调用对应的NATStart文件即可。之后对用户发送过来的DNS请求报文进行NAT处理时，针对源IP命中的通信网络地址的DNS请求报文，把报文的源地址NAT为预处理服务器的出口IP地址d.d.d.d。

进一步的，图中所示的服务器运行状态监测装置，以使用开源Python软件编写的为例。其为一个检测网站在各通信网络内的服务器运行状态的程序，它可以实现永久循环，实时监测，并把测试结果与NAT服务进行联动。假设某网站在第一通信网络、第二通信网络、第三通信网络分别有一台服务器，IP地址分别为a.a.a.a、b.b.b.b、c.c.c.c，以第一通信网络为例，测试a.a.a.a的80端口是否连通。若测试连通性成功，则检测第一通信网络的NAT服务是否已启用，若未启用，则无需执行任何动作，若已启用，则关闭对应的NAT服务。若测试连通性失败，则检测第一通信网络的NAT服务是否已启用，若已启用，则无需执行任何操作，若未启用，则开启对应的NAT服务。同时通过循环实现对服务器状态的不间断追踪。

步骤305，返回目标服务器的地址。

本公开中，预处理服务器接收到域名解析器返回的目标服务器的地址后，就将目标服务器的地址返回给用户。之后用户就可以调用该目标服务器的地址，以获取到相应的服务。

本公开实施例中，首先接收第一业务处理请求，并确定运行在各通信网络中的服务器当前的运行状态，然后基于每个服务器当前的运行状态及第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求，之后将第二业务处理请求发送给域名解析服务器，以获取域名解析服务器返回的所述目标服务器的地址，最后返回目标服务器的地址。由此，通过将对服务器运行状态的监测串行在业务流程中，不引入额外时延，还实现了智能域名解析系统的独立统一，从而提高了域名解析系统的通用性及实用性。

下面结合图5以预处理服务器执行为例，对本公开提供的业务处理方法进行进一步详细说明。图5为本公开实施例所提供的一种业务处理方法的流程示意图。如图5所示，该业务处理方法可以包括以下步骤：

步骤501，接收第一业务处理请求，其中，第一业务处理请求中包括第一源地址。

步骤502，确定运行在各通信网络中的服务器当前的运行状态。

其中，步骤501至步骤502的具体实现形式，可参照本公开中其他各实施例中的详细描述，此处不再具体赘述。

步骤503，在任一服务器当前的运行状态异常的情况下，确定任一服务器所在的第二通信网络。

本公开中，预处理服务器在确定第一源地址对应的在各通信网络中的任一服务器运行状态异常的情况下，需要确定运行状态异常的服务器所在的第二通信网络。

步骤504，在第二通信网络与第一通信网络不同的情况下，将第一业务处理请求确定为第二业务处理请求。

本公开中，当第二通信网络与第一通信网络不同时，预处理服务器不对第一业务处理请求做任何处理，直接将第一业务处理请求确定为第二业务处理请求。

举例来说，第一源地址所属的第一通信网络为通信网络#0，预处理服务器在对各通信网络中的业务服务器进行监测时，发现运行状态异常的服务器所属的第二通信网络不是通信网络#0，与第一通信网络不同，将不对第一业务处理请求中的第一源地址做处理，直接将第一业务处理请求确定为第二业务处理请求。

步骤505，将第二业务处理请求发送给域名解析服务器，以获取域名解析服务器返回的目标服务器的地址。

步骤506，返回目标服务器的地址。

其中，步骤505至步骤506的具体实现形式，可参照本公开中其他各实施例中的详细描述，此处不再具体赘述。

本公开实施例中，首先接收第一业务处理请求，其中，第一业务处理请求中包括第一源地址，同时确定运行在各通信网络中的服务器当前的运行状态，然后在任一服务器当前的运行状态异常的情况下，确定任一服务器所在的第二通信网络，在第二通信网络与第一通信网络不同的情况下，将第一业务处理请求确定为第二业务处理请求，之后将第二业务处理请求发送给域名解析服务器，以获取域名解析服务器返回的目标服务器的地址，最后返回目标服务器的地址。由此，通过将对服务器运行状态的监测串行在业务流程中，不引入额外时延，还实现了智能域名解析系统的独立统一，从而提高了域名解析系统的通用性及实用性。

下面结合图6以域名解析服务器执行为例，对本公开提供的业务处理方法进行详细说明。图6为本公开实施例所提供的一种业务处理方法的流程示意图。如图6所示，该业务处理方法可以包括以下步骤：

步骤601，接收预处理服务器发送的第二业务处理请求，其中，第二业务处理请求为预处理服务器基于接收的第一业务处理请求生成的。

本公开中，域名解析服务器接收到预处理服务器发送的第二业务处理请求后，就对第二业务处理请求进行处理。

步骤602，对第二业务处理请求进行解析，以确定第二业务处理请求中包括的第二源地址。

本公开中，域名解析服务器通过对第二业务处理请求进行解析，获取第二源地址。

步骤603，基于第二源地址的类型，确定目标服务器的地址。

其中，目标服务器，可以为运行在第二源地址所属的通信网络中的服务器，或者还可以为包括运行在每个通信网络中的服务器。

在一些可能的实现形式中，在第二源地址属于任一通信网络的情况下，遍历任一通信网络关联的第一网络接入控制列表，以获取目标服务器的地址。

其中，第一网络接入控制列表，可以为根据业务需要预先配置的，或者还可以为根据历史数据配置的，本公开对此不做限定。

本公开中，在第二源地址属于任一通信网络的情况下，可以认为第二源地址所属的任一通信网络中服务器处于非异常状态，域名解析服务器将会返回第二源地址所属的通信网络内对应的服务器的地址。

举例来说，第二源地址属于通信网络#0，域名解析服务器将会返回通信网络#0内第二源地址对应的服务器地址。

在一些可能的实现形式中，在第二源地址为指定地址的情况下，遍历指定地址关联的第二网络接入控制列表，以获取目标服务器的地址。

其中，指定地址，为对第一源地址进行nat处理后，生成的地址。

其中，第二网络接入控制列表，可以为根据业务需要预先配置的，或者还可以为根据历史数据配置的，本公开对此不做限定。

需要说明的是，若第二源地址为指定地址，可以认为第一源地址所属的通信网络内的服务器运行状态异常，此时对第一源地址进行NAT处理，生成的第二源地址即为指定地址，域名解析服务器基于指定地址，返回各通信网络中的第二源地址对应的所有服务器地址。

举例来说，共有三个通信网络，分别为通信网络#0、通信网络#1、及通信网络#2。第二源地址为指定地址，此时域名解析服务器基于指定地址，返回通信网络#0、通信网络#1、及通信网络#2中的第二源地址对应的所有服务器地址。

步骤604，向预处理服务器返回目标服务器的地址。

本公开中，域名解析服务器获取到目标服务器的地址后，就将目标服务器的地址返回给预处理服务器。

下面以图7为例，对本公开实施例提供的域名解析服务器进行说明，图7为本公开实施例提供的一种域名解析服务器的结构和功能示意图。

本公开提供的域名解析服务器配置了4个网络接入控制列表(Access ControlList，ACL)，其中三个ACL分别用于区分各通信网络的用户，把想要区分的源IP地址划到对应的ACL中去，第四个ACL则用来匹配经过预处理服务器NAT后的地址。

另外，域名解析服务器把想要区分的网站服务器IP地址设置到对应的解析文件中。如配置三个网站服务器IP地址a.a.a.a、b.b.b.b、c.c.c.c，分别位于第一通信网络、第二通信网络、及第三通信网络，假设域名为www.×××.com。前3个配置文件为一对一的精准调度，第四个配置文件继续衔接识别到故障后的处理动作，给用户返回所有的结果，用户拿到结果后按序访问第一个IP地址，如果第一个IP地址不通则会自动切换到第二个，以此类推，实现最终的访问。

进一步地，域名解析服务器还设置了多视图VIEW功能，且均在对应的视图下配置了对应的解析文件，把配置的ACL和要返回的动作进行关联，如图7所示，以四个VIEW为例，第一VIEW返回位于第一通信网络中的网站服务器的IP地址a.a.a.a，第二VIEW返回位于第二通信网络中的网站服务器的IP地址b.b.b.b，第三VIEW返回位于第三通信网络中的网站服务器的IP地址c.c.c.c，第四VIEW则按照故障容灾的需求进行绑定，返回位于各通信网络内的网站服务器的全部地址。

由此，经过以上配置，实现了域名解析服务器的强壮性和容灾性。各通信网络的用户访问网站时，域名解析服务器为其返回位于对应通信网络内的服务器IP地址。域名经NAT处理的用户访问网站时，域名解析服务器为其返回位于所有通信网络内的服务器IP地址a.a.a.a、b.b.b.b、c.c.c.c。

本公开实施例中，首先接收预处理服务器发送的第二业务处理请求，然后对第二业务处理请求进行解析，以确定第二业务处理请求中包括的第二源地址，之后基于第二源地址的类型，确定目标服务器的地址，最后向预处理服务器返回目标服务器的地址。由此，基于第二源地址的类型，向预处理服务器返回对应的目标服务器的地址，从而不仅提高了域名解析服务器的强壮性和容灾性，实现了精准调度，保障了用户感知，还实现了智能域名解析系统的独立统一，从而提高了域名解析系统的通用性及实用性。

为了实现上述实施例，本公开还提出一种业务处理装置，所述装置配置在预处理服务器中。

图8为本公开实施例所提供的业务处理装置的结构示意图。

如图8所示，该业务处理装置800包括：第一接收模块801、第一确定模块802、生成模块803、发送模块804、第一返回模块805。

第一接收模块801，用于接收第一业务处理请求，其中，第一业务处理请求中包括第一源地址；

第一确定模块802，用于确定运行在各通信网络中的服务器当前的运行状态；

生成模块803，用于基于每个服务器当前的运行状态及第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求；

发送模块804，用于将第二业务处理请求发送给域名解析服务器，以获取域名解析服务器返回目标服务器的地址；

第一返回模块805，用于返回目标服务器的地址。

在本公开一种可能的实现方式中，上述第一确定模块802，用于：

获取每个用于探测服务器端口的连通状态的测试服务当前的返回值；

根据每个测试服务当前的返回值，确定每个服务器当前的运行状态。

在本公开一种可能的实现方式中，上述生成模块803，用于：

在每个服务器当前的运行状态非异常的情况下，将第一业务处理请求确定为第二业务处理请求，其中，目标服务器的地址所属的网络为第一通信网络。

在本公开一种可能的实现方式中，上述生成模块803，用于：

在任一服务器当前的运行状态异常的情况下，确定任一服务器所在的第二通信网络；

在第二通信网络与第一通信网络相同的情况下，利用预设的第二源地址替换第一业务处理请求中的第一源地址，以获取第二业务处理请求。

在本公开一种可能的实现方式中，上述生成模块803，用于：

在第二通信网络与第一通信网络不同的情况下，将第一业务处理请求确定为第二业务处理请求。

在本公开一种可能的实现方式中，目标服务器为运行在第一通信网络中的服务器，或目标服务器包括运行在每个通信网络中的服务器。

本公开实施例中的上述各模块的功能及具体实现原理，可参照上述各方法实施例，此处不再赘述。

本公开实施例中，首先接收第一业务处理请求，并确定运行在各通信网络中的服务器当前的运行状态，然后基于每个服务器当前的运行状态及第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求，之后将第二业务处理请求发送给域名解析服务器，以获取域名解析服务器返回的目标服务器的地址，最后返回目标服务器的地址。由此，通过将对服务器运行状态的监测串行在业务流程中，不引入额外时延，还实现了智能域名解析系统的独立统一，从而提高了域名解析系统的通用性及实用性。

为了实现上述实施例，本公开还提出一种业务处理装置，所述装置配置在域名解析服务器中。

图9为本公开实施例所提供的业务处理装置的结构示意图。

如图9所示，该业务处理装置900包括：第二接收模块901、解析模块902、第二确定模块903、第二返回模块904。

第二接收模块901，用于接收预处理服务器发送的第二业务处理请求，其中，第二业务处理请求为预处理服务器基于接收的第一业务处理请求生成的；

解析模块902，用于对第二业务处理请求进行解析，以确定第二业务处理请求中包括的第二源地址；

第二确定模块903，用于基于第二源地址的类型，确定目标服务器的地址；

第二返回模块904，用于向预处理服务器返回目标服务器的地址。

在本公开一种可能的实现方式中，上述第二确定模块903，用于：

在第二源地址属于任一通信网络的情况下，遍历任一通信网络关联的第一网络接入控制列表，以获取目标服务器的地址；或者，

在第二源地址为指定地址的情况下，遍历指定地址关联的第二网络接入控制列表，以获取目标服务器的地址。

在本公开一种可能的实现方式中，目标服务器为运行在第二源地址所属的通信网络中的服务器，或目标服务器包括运行在每个通信网络中的服务器。

本公开实施例中，首先接收预处理服务器发送的第二业务处理请求，然后对第二业务处理请求进行解析，以确定第二业务处理请求中包括的第二源地址，之后基于第二源地址的类型，确定目标服务器的地址，最后向预处理服务器返回目标服务器的地址。由此，基于第二源地址的类型，向预处理服务器返回对应的目标服务器的地址，从而不仅提高了域名解析服务器的强壮性和容灾性，实现了精准调度，保障了用户感知，还实现了智能域名解析系统的独立统一，从而提高了域名解析系统的通用性及实用性。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图10示出了可以用来实施本公开的实施例的示例电子设备1000的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图10所示，设备1000包括计算单元1001，其可以根据存储在只读存储器(ROM)1002中的计算机程序或者从存储单元1008加载到随机访问存储器(RAM)1003中的计算机程序，来执行各种适当的动作和处理。在RAM 1003中，还可存储设备1000操作所需的各种程序和数据。计算单元1001、ROM 1002以及RAM 1003通过总线1004彼此相连。输入/输出(I/O)接口1005也连接至总线1004。

设备1000中的多个部件连接至I/O接口1005，包括：输入单元1006，例如键盘、鼠标等；输出单元1007，例如各种类型的显示器、扬声器等；存储单元1008，例如磁盘、光盘等；以及通信单元1009，例如网卡、调制解调器、无线通信收发机等。通信单元1009允许设备1000通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1001可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1001的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1001执行上文所描述的各个方法和处理，例如业务处理方法。例如，在一些实施例中，业务处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1008。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1002和/或通信单元1009而被载入和/或安装到设备1000上。当计算机程序加载到RAM 1003并由计算单元1001执行时，可以执行上文描述的业务处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元1001可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行业务处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)、互联网及区块链网络。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

本公开实施例中，首先预处理服务器接收第一业务处理请求，并确定运行在各通信网络中的服务器当前的运行状态，然后基于每个服务器当前的运行状态及第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求，之后将第二业务处理请求发送给域名解析服务器。域名解析服务器接收到预处理服务器发送的第二业务处理请求后，对第二业务处理请求进行解析，以确定第二业务处理请求中包括的第二源地址，之后基于第二源地址的类型，确定目标服务器的地址，最后向预处理服务器返回目标服务器的地址，由预处理服务器返回目标服务器的地址。由此，从而不仅提高了域名解析服务器的强壮性和容灾性，实现了精准调度，保障了用户感知，还实现了智能域名解析系统的独立统一，从而提高了域名解析系统的通用性及实用性。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本公开的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。在本公开的描述中，所使用的词语“如果”及“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“在……情况下”。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (14)

1.一种业务处理方法，其特征在于，所述方法由预处理服务器执行，所述方法包括：

接收第一业务处理请求，其中，所述第一业务处理请求中包括第一源地址；

确定运行在各通信网络中的服务器当前的运行状态；

基于每个所述服务器当前的运行状态及所述第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求；

将所述第二业务处理请求发送给域名解析服务器，以获取所述域名解析服务器返回的所述目标服务器的地址；

返回所述目标服务器的地址。

2.如权利要求1所述的方法，其特征在于，所述确定运行在各通信网络中的业务服务器当前的运行状态，包括：

获取每个用于探测所述服务器端口的连通状态的测试服务当前的返回值；

根据每个所述测试服务当前的返回值，确定每个所述服务器当前的运行状态。

3.如权利要求1所述的方法，其特征在于，所述基于每个所述服务器当前的运行状态及所述第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求，包括：

在每个所述服务器当前的运行状态非异常的情况下，将所述第一业务处理请求确定为第二业务处理请求，其中，所述目标服务器的地址所属的网络为所述第一通信网络。

4.如权利要求1所述的方法，其特征在于，所述基于每个所述服务器当前的运行状态及所述第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求，包括：

在任一服务器当前的运行状态异常的情况下，确定所述任一服务器所在的第二通信网络；

在所述第二通信网络与所述第一通信网络相同的情况下，利用预设的第二源地址替换所述第一业务处理请求中的第一源地址，以获取所述第二业务处理请求。

5.如权利要求4所述的方法，其特征在于，在所述确定所述任一服务器所在的第二通信网络之后，还包括：

在所述第二通信网络与所述第一通信网络不同的情况下，将所述第一业务处理请求确定为第二业务处理请求。

6.如权利要求1-5任一所述的方法，其特征在于，所述目标服务器为运行在所述第一通信网络中的服务器，或所述目标服务器包括运行在每个通信网络中的服务器。

7.一种业务处理方法，其特征在于，所述方法由域名解析服务器执行，所述方法包括：

接收预处理服务器发送的第二业务处理请求，其中，所述第二业务处理请求为预处理服务器基于接收的第一业务处理请求生成的；

对所述第二业务处理请求进行解析，以确定所述第二业务处理请求中包括的第二源地址；

基于所述第二源地址的类型，确定目标服务器的地址；

向所述预处理服务器返回所述目标服务器的地址。

8.如权利要求7所述的方法，其特征在于，所述基于所述第二源地址的类型，确定目标服务器的地址，包括：

在所述第二源地址属于任一通信网络的情况下，遍历所述任一通信网络关联的第一网络接入控制列表，以获取所述目标服务器的地址；或者，

在所述第二源地址为指定地址的情况下，遍历所述指定地址关联的第二网络接入控制列表，以获取所述目标服务器的地址。

9.如权利要求7或8所述的方法，其特征在于，所述目标服务器为运行在所述第二源地址所属的通信网络中的服务器，或所述目标服务器包括运行在每个通信网络中的服务器。

10.一种业务处理装置，所述装置配置在预处理服务器中，包括：

第一接收模块，用于接收第一业务处理请求，其中，所述第一业务处理请求中包括第一源地址；

第一确定模块，用于确定运行在各通信网络中的服务器当前的运行状态；

生成模块，用于基于每个所述服务器当前的运行状态及所述第一源地址所属的第一通信网络中的至少一项，生成第二业务处理请求；

发送模块，用于将所述第二业务处理请求发送给域名解析服务器，以获取所述域名解析服务器返回的所述目标服务器的地址；

第一返回模块，用于返回所述目标服务器的地址。

11.一种业务处理装置，所述装置配置在域名解析服务器中，包括：

第二接收模块，用于接收预处理服务器发送的第二业务处理请求，其中，所述第二业务处理请求为预处理服务器基于接收的第一业务处理请求生成的；

解析模块，用于对所述第二业务处理请求进行解析，以确定所述第二业务处理请求中包括的第二源地址；

第二确定模块，用于基于所述第二源地址的类型，确定目标服务器的地址；

第二返回模块，用于向所述预处理服务器返回所述目标服务器的地址。

12.一种电子设备，其特征在于，包括：

至少一个处理器；

以及，与所述至少一个处理器通信连接的存储器；

其中，所述存储器存储有可能被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-9中任一项所述的方法。

13.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-9中任一项所述的方法。

14.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-9中任一项所述的方法。