数据转发方法、装置、存储介质及电子设备与流程

1.本公开涉及计算机技术领域，尤其涉及一种数据转发方法、数据转发装置、存储介质及电子设备。


背景技术：

2.nginx(高性能的http和反向代理web服务器)作为开源的反向代理软件代表，被广泛应用。企业内部生产环境中，接入层使用nginx做流量转发，需要非常高的可靠性，并且对于实例变更和流量调度管理都有很高的要求。
3.当前nginx默认支持的典型的两种流量转发的方案：一种是upstream(数据转发)模块使用域名的方式实现转发，这种情况下nginx服务启动后server(服务)信息不能动态变更，必须配合resolver(解析器)支持dns(domain name system，域名系统)动态解析功能才能进行；另一种是使用ip(internet protocol，网络之间互连的协议)列表的方式，利用配置文件动态变更，但不仅时效性上满足不了需求，频繁变更配置文件也容易引入生产环境异常。
4.需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。


技术实现要素：

5.本公开的目的在于提供一种数据转发方法、数据转发装置、存储介质及电子设备，旨在解决反向代理服务数据转发时后端服务数据不能动态变更的问题。
6.本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。
7.根据本公开实施例的一方面，提供了一种数据转发方法，包括：响应于服务启动指令，解析名字服务配置文件得到配置了名字服务的扩展服务名称；获取名字服务中所述扩展服务名称对应的实际服务数据，基于所述实际服务数据配置转发服务数据，并创建定时器以完成服务启动；响应于所述定时器的触发任务，获取当前时刻下所述名字服务中所述扩展服务名称对应的实际服务数据；基于当前时刻下的所述实际服务数据更新所述转发服务数据，以利用更新后的转发服务数据进行数据转发。
8.根据本公开的一些实施例，基于前述方案，所述获取名字服务中所述扩展服务名称对应的实际服务数据，包括：通过名字服务软件开发工具获取所述实际服务数据；其中，所述名字服务软件开发工具是基于所述名字服务创建的。
9.根据本公开的一些实施例，基于前述方案，在所述响应于服务启动指令之前，所述方法还包括：获取原生配置文件；以及基于反向代理服务和名字服务定义预设数据结构；按照所述预设数据结构对所述原生配置文件进行参数修改，得到所述名字服务配置文件。
10.根据本公开的一些实施例，基于前述方案，所述按照所述预设数据结构对所述原生配置文件进行参数修改，得到所述名字服务配置文件，包括：将所述原生配置文件中的原
始服务名称修改为所述扩展服务名称；创建所述扩展服务名称对应的格式服务数据，得到所述名字服务配置文件。
11.根据本公开的一些实施例，基于前述方案，所述基于所述实际服务数据配置转发服务数据，包括：将所述实际服务数据替换所述格式服务数据，以得到所述转发服务数据。
12.根据本公开的一些实施例，基于前述方案，在所述获取名字服务中所述扩展服务名称对应的实际服务数据之后，所述方法还包括：将所述实际服务数据更新至预先创建的共享内存。
13.所述基于所述当前时刻下的实际服务数据更新所述转发服务数据，包括：在所述实际服务数据和所述转发服务数据不一致，且所述实际服务数据包含可用实例时，将所述转发服务数据替换为所述实际服务数据；以及在所述实际服务数据和所述转发服务数据一致时，或者在所述实际服务数据不包含可用实例时，维持所述转发服务数据不变以完成更新。
14.根据本公开实施例的第二方面，提供了一种数据转发装置，包括，解析模块，用于响应于服务启动指令，解析名字服务配置文件得到配置了名字服务的扩展服务名称；配置模块，用于获取名字服务中所述扩展服务名称对应的实际服务数据，基于所述实际服务数据配置转发服务数据，并创建定时器以完成服务启动；获取模块，用于响应于所述定时器的触发任务，获取当前时刻下所述名字服务中所述扩展服务名称对应的实际服务数据；更新模块，用于基于当前时刻下的所述实际服务数据更新所述转发服务数据，以利用更新后的转发服务数据进行数据转发。
15.根据本公开实施例的第三方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述实施例中的数据转发方法。
16.根据本公开实施例的第四方面，提供了一种电子设备，其特征在于，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中的数据转发方法。
17.本公开示例性实施例可以具有以下部分或全部有益效果：
18.在本公开的一些实施例所提供的技术方案中，能够联动反向代理服务和名字服务，基于名字服务的服务发现功能定时获取最新的实际数据来对反向代理服务中的upstream转发服务数据进行动态更新，以确保将最新更新的服务数据进行转发。一方面，结合了名字服务自身提供的能力，实现接入层upstream的动态变更和流量调度，进而解决实例异常的动态感知能力，提供稳定高可靠的反向代理能力；另一方面，还能够充分利用反向代理服务器的upstream模块自身的功能实现动态化的运维管理需求。
附图说明
19.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
20.图1示意性示出本公开示例性实施例中一种数据转发方法的流程示意图；
21.图2示意性示出本公开示例性实施例中一种名字服务配置文件的示意图；
22.图3示意性示出本公开示例性实施例中一种原生配置文件的示意图；
23.图4示意性示出本公开示例性实施例中一种服务启动的组成示意图；
24.图5示意性示出本公开示例性实施例中一种更新转发服务数据方法的组成示意图；
25.图6示意性示出本公开示例性实施例中一种数据转发装置的组成示意图；
26.图7示意性示出本公开示例性实施例中一种计算机可读存储介质的示意图；
27.图8示意性示出本公开示例性实施例中一种电子设备的计算机系统的结构示意图。
具体实施方式
28.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
29.此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。
30.附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
31.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
32.nginx作为开源的反向代理软件代表，被广泛应用。企业内部生产环境中，接入层使用nginx做流量转发，需要非常高的可靠性，并且对于实例变更和流量调度管理都有很高的要求。同时，接入层服务需要转发很多后端服务流量，配置复杂度也比较高。
33.当前nginx默认支持的有两种典型的流量转发方案：
34.方案一：upstream模块使用域名的方式实现转发。对于域名的方式，后端服务实例变化也需要联动域名变更，域名记录变更需要和服务管理模块进行联动，达到实例变更的目的。其局限性在于：
35.1)默认情况下，nginx upstream模块支持域名，但是nginx服务启动后server信息不动态变更，必须配合resolver支持dns动态解析功能进行，与dns服务器和dns配置强关联，生效周期相对较长，如果为了更好的时效性，则需要搭建维护专门的dns服务器进行劫持解析；
36.2)dns默认使用udp协议，如果网络有抖动，关键时刻的实例变更准确性无法保障；
37.3)内部生产环境，接入层转发的服务规模较大，服务管理模块需要和域名变更功能进行联动，设计架构上额外增加改模块以及域名维护，复杂度增高。
38.方案二：使用ip列表的方式实现转发。对于ip列表的方式，其本身是静态的，对于
变更场景，只能通过配置更新的方式进行。存在以下的局限性：
39.1)时效性不满足需求，有实例异常或者局部流量异常的时候，再发起变更，不能满足快速止损的管理要求。
40.2)频繁变更配置文件，和正常的配置文件变更需求可能存在冲突，对用户管理的难度也会变大，变更也教容易引入生产环境异常。
41.因此，针对现有技术的缺点，本公开提供一种数据转发方法，基于内部服务发现的基础上，结合nginx插件接口，实现一个服务发现的upstream插件，根据服务发现提供的实例变更的能力，代替使用域名解析或者配置文件热加载的方式变更upstream的功能，在后端服务实例异常、实例屏蔽、流量切换等场景下动态更新upstream server变量的能力。
42.图1示意性示出本公开示例性实施例中一种数据转发方法的流程示意图。如图1所示，该数据转发方法包括步骤s101至步骤s104：
43.步骤s101，响应于服务启动指令，解析名字服务配置文件得到配置了名字服务的扩展服务名称；
44.步骤s102，获取名字服务中所述扩展服务名称对应的实际服务数据，基于所述实际服务数据配置转发服务数据，并创建定时器以完成服务启动；
45.步骤s103，响应于所述定时器的触发任务，获取所述名字服务中当前时刻下所述扩展服务名称对应的当前实际服务数据；
46.步骤s104，基于所述当前实际服务数据更新所述转发服务数据，以利用更新后的转发服务数据进行数据转发。
47.在本公开的一些实施例所提供的技术方案中，能够将反向代理服务和名字服务相结合，基于名字服务的服务发现功能定时获取最新的实际数据来对反向代理服务中的upstream转发服务数据进行更新，以确保将最新更新的服务数据进行转发。一方面，结合了名字服务自身提供的能力，实现接入层upstream的动态变更和流量调度，进而解决实例异常的动态感知能力，提供稳定高可靠的反向代理能力；另一方面，还能够充分利用反向代理服务器的upstream模块提供的负载均衡相关能力，根据实际服务数据适时调整来做差异化流量调度和容错功能支持，实现压测、容量预估等其他运维管理需求。
48.下面，将结合附图及实施例对本示例实施方式中的数据转发方法的各个步骤进行更详细的说明。
49.具体地，步骤s101至步骤s104可以应用于反向代理服务器，例如nginx，是一个高性能的http和反向代理web服务器。反向代理服务器中包括upstream模块，用于完成网络数据的转发功能，将请求转发到后端服务器从而得到相应的返回，是反向代理服务器的核心模块之一。
50.在步骤s101中，响应于服务启动指令，解析名字服务配置文件得到配置了名字服务的扩展服务名称。
51.具体地，反向代理服务器构建完成后，接收到服务启动指令后，即可进行反向代理服务器的服务启动过程。在服务启动时加载反向代理服务器的配置文件，即名字服务配置文件。
52.名字服务配置文件是在服务构建时对原生配置文件进行修改后得到的，其中包括了配置了名字服务的扩展服务名称，以及扩展服务名称对应的格式服务数据。
53.其中，名字服务(naming service，ns)，能够提供内部服务注册和服务发现的能力，支持各种开发语言的sdk以及相关工具支持。根据企业接入的不同，对应的名字服务有不同的数据，在本公开中为了介绍方便，统一采用m公司的mns为例进行说明。
54.服务发现即为使服务调用方通过服务的名字就能够找到服务提供方，提供了一种服务发布与查找的协调机制，能够具备动态感知服务实例变更的能力。
55.图2示意性示出本公开示例性实施例中一种名字服务配置文件的示意图。参考图2所示，使用了mns之后，名字服务配置文件包括了扩展服务名称“upstream backend_mns_name”，以及格式服务数据“server 10.0.0.1:8201”。
56.对名字服务配置文件进行解析后可以得到扩展服务名称。扩展服务名称即反向代理服务器nginx的upstream模块管理的后端服务器的服务名称。与现有的静态配置文件中的服务名称不同，本公开中解析的得到的扩展服务名称已经配置了名字服务，也就是与mns节点名称一致。解析得到的扩展服务名称可以有一个或多个。
57.在步骤s102中，获取名字服务中所述扩展服务名称对应的实际服务数据，基于所述实际服务数据配置转发服务数据，并创建定时器以完成服务启动。
58.其中，由于扩展服务名称与名字服务mns节点名称一致，因此可以基于扩展服务名称与名字服务mns交互，进而获取到mns中这些扩展服务名称所对应的实际服务数据，即后端server的实例信息。当扩展服务名称有多个时，遍历所有的扩展服务名称，以获取各扩展服务名称分别对应的实际服务数据。
59.转发服务数据也就是nginx所代理的实际的后端服务器，以server列表的形式呈现。在获取到实际服务数据之后，通过实际服务数据与upstream模块对应的转发服务数据之间的映射关系，将实际服务数据关联到upstream模块的后端server的数据结构，得到转发服务数据，进而用于后续按照upstream模块的转发服务数执行流量转发。
60.在加载了实际服务数据作为转发服务数据之后，创建用于动态更新的定时器并启动。定时器中包括了更新间隔时间，按照更新间隔时间定时触发更新转发服务数据的任务。更新间隔时间可以根据需要配置不同的数值，也可以采用默认时长。
61.这样一来，在nginx进行服务启动时，nginx的内存中包括了配置了名字服务的扩展服务名称，以及通过扩展服务名称加载的实际服务数据作为的转发服务数据，并且启动了定时器用于后续转发服务数据的更新，这部分的扩展启动过程完成后，进入nginx的正常启动流程，完成服务启动。
62.需要说明的是，可以结合nginx插件接口，实现一个服务发现的upstream插件，进而利用该插件完成基于名字服务配置文件进行解析、获取以及替换得到转发服务数据的功能。
63.在步骤s103中，响应于所述定时器的触发任务，获取当前时刻下所述名字服务中所述扩展服务名称对应的实际服务数据。
64.具体而言，按照定时器中的更新间隔时间定时触发任务，在接收到定时器的触发任务时，提取已经解析过的扩展服务名称，进而通过扩展服务名称与mns交互得到当前时刻下的实际服务数据，实际服务数据即所有配置了mns的upstream的服务名称对应的后端实例信息。
65.其中，获取当前时刻下的实际服务数据与步骤s102中的获取方法相同，只是数据
内容的时间戳不同。
66.在步骤s104中，基于当前时刻下的所述实际服务数据更新所述转发服务数据，以利用更新后的转发服务数据进行数据转发。
67.具体地，转发服务数据是预置在反向代理服务器中的服务数据，而当前时刻下的实际服务数据是基于名字服务获取的最新的服务数据。可以通过数据对比，将最新的服务数据保留，进而使得反向代理服务器的upstream模块管理的转发服务数据定时更新，从而基于更新后的转发服务数据进行数据转发。
68.由于当前时刻下的所述实际服务数据时不断变化的，因此nginx便可根据服务发现提供的实例变更的能力，代替使用域名解析或者配置文件热加载的方式变更upstream的功能，在后端服务实例异常、实例屏蔽、流量切换等场景下动态更新upstream server变量的能力。
69.基于上述方法，反向代理服务器中upstream模块对应的后端服务信息由定时器结合名字服务的服务发现进行定时更新来保障，实现接入层upstream的动态变更和流量调度；数据转发则由其本身的upstream模块负载均衡相关的策略保障，能够充分利用nginx upstream模块自身的功能实现动态化的运维管理需求，例如按照实时服务数据进行差异化流量、压测、容量预估等。
70.在本公开的一个实施例中，所述获取名字服务中所述扩展服务名称对应的实际服务数据，包括：通过名字服务软件开发工具获取所述实际服务数据；其中，所述名字服务软件开发工具是基于所述名字服务创建的。
71.具体而言，可以通过名字服务软件开发工具，即名字服务sdk，来获取实际服务数据。名字服务sdk可以是根据名字服务mns创建开发的，通过名字服务sdk可以与名字服务mns交互，进而根据扩展服务名称查询到服务提供方，返回实际服务数据。
72.基于上述方法，名字服务自身通过名字服务sdk具备服务发现的各类能力，如流量调度，实例剔除，权重修改等，接入简单方便，满足企业内部的服务治理和稳定性管理要求，很大程度的降低了接入层服务管理的维护成本。
73.在本公开的一个实施例中，在所述响应于服务启动指令之前，所述方法还包括：获取原生配置文件；以及基于反向代理服务和名字服务定义预设数据结构；按照所述预设数据结构对所述原生配置文件进行参数修改，得到所述名字服务配置文件。
74.具体而言，在服务启动之前，在进行服务构建时需要将反向代理服务器的原生配置文件转换为名字服务配置文件，即将原生的nginx upstream模块需要的配置，替换为mns_module需要的配置。
75.即在nginx create main configuration阶段，首先获取原生配置文件。图3示意性示出本公开示例性实施例中一种原生配置文件的示意图，参考图3所示，原生配置文件中包括服务数据，其中有server列表，以及各server的参数数据。
76.然后基于反向代理服务和名字服务定义预设数据结构。具体地，可以通过http模块开发核心接口，用来定义ngx-mns的预设数据结构，构造ngx_http_upstream_mns_main_conf_t数据结构。其中预设数据结构中可以包括配置了名字服务的扩展服务名称，以及格式服务数据。
77.其中，格式服务数据记为设定的一个虚拟服务数据，这是因为在nginx服务启动时
需要进行配置文件完整度的检查，其中一项检查项记为服务数据，为了使得nginx正常进行服务启动，所以需要将虚拟服务数据作为nginx服务启动的检查项。
78.最后，在create完成后，按照ngx_http_upstream_mns_init_main对原生配置文件进行参数修改，得到所述名字服务配置文件。具体的过程如下：将所述原生配置文件中的原始服务名称修改为所述扩展服务名称；创建所述扩展服务名称对应的格式服务数据，得到所述名字服务配置文件。
79.图3示出了原生配置文件，图2示出了修改后的名字服务配置文件，参考图2和图3所示，在配置文件变化时，将原始服务名称修改为所述扩展服务名称，即将“upstream backend”修改为“upstream backend_mns_name”，并配置名字服务“use_mns”，以及配置格式服务数据“sever 10.1.1.1:8201”。
80.在本公开的一个实施例中，所述基于所述实际服务数据配置转发服务数据，包括：将所述实际服务数据替换所述格式服务数据，以得到所述转发服务数据。
81.具体地，参考图2所示，名字服务配置文件中包括了作为nginx服务启动检查项的格式服务数据，这个格式服务数据本身是无数据含义的，在得到实际服务数据之后，将实际服务数据替换掉格式服务数据，就可以得到转发服务数据。
82.需要说明的是，在服务构建时，将原生配置文件转化为名字服务配置文件，在服务启动时，经过解析扩展服务名称、获取实际服务数据以及替换得到转发服务数据之后，在内存中服务数据的格式与原生配置文件中的服务数据的格式相同，即本公开中的数据转发方法仅是对加载转发服务数据进行了拦截，并没有改变nginx本身的数据转发逻辑。
83.在本公开的一个实施例，在所述获取名字服务中所述扩展服务名称对应的实际服务数据之后，所述方法还包括：将所述实际服务数据更新至预先创建的共享内存。
84.具体地，可以在获取实际服务数据之后，将实际服务数据更新到服务发现组件与反向代理服务器进行数据共享的共享内存中，以便通过共享内存实现对服务数据共享。
85.图4示意性示出本公开示例性实施例中一种服务启动的组成示意图。参考图4所示，服务启动的具体步骤如下：
86.步骤s401，配置转发服务数据；其中，步骤s401中又包括以下内容：
87.步骤s4011，通过http模块开发核心接口；
88.步骤s4012，定义ngx-mns数据结构；
89.步骤s4013，通过名字服务sdk获取当前时刻的实际服务数据，具体地，首先通过init_mns_module解析名字服务配置文件得到扩展服务名称，然后针对每个扩展服务名称，通过名字服务sdk获取每一个扩展服务名称对应的实际服务数据；
90.步骤s4014，将实际服务数据配置为转发服务数据，即可以通过init_mns_process处理获取到的实际服务数据，更新upstream的转发服务数据，并配置包括weight、backup、max_fails等nginx原生支持的策略；
91.步骤s402，在转发服务数据配置完成后，创建定时器，即可以通过mns_add_timers创建定时器，并且由upstream_mns_update_handler进行回调函数处理，整个启动流程就完成了。
92.在本公开的一个实施例中，所述基于所述当前时刻下的实际服务数据更新所述转发服务数据，包括：在所述实际服务数据和所述转发服务数据不一致，且所述实际服务数据
包含可用实例时，将所述转发服务数据替换为所述实际服务数据；以及在所述实际服务数据和所述转发服务数据一致时，或者在所述实际服务数据不包含可用实例时，维持所述转发服务数据不变以完成更新。
93.具体而言，在得到当前时刻下的实际服务数据之后，需要根据实际服务数据和转发服务数据的比较结果，以及实际服务数据中是否包含可用实例来进行数据更新。
94.图5示意性示出本公开示例性实施例中一种更新转发服务数据方法的组成示意图。参考图5所示，更新转发服务数据方法的具体步骤如下：
95.步骤s501，通过upstream_mns_update_handler，定时器按照预设时间间隔触发数据更新的任务；
96.步骤s502，通过名字服务sdk获取实际服务数据，需要遍历所以的扩展服务名字；
97.然后通过upstream_update_server执行步骤s503至步骤s506的更新过程：
98.步骤s503，判断扩展服务名字对应的实际服务数据与nginx中的转发服务数据是否存在diff，如果存在diff，则意味着数据不一致，执行步骤s504，如果不存在diff，则数据一致，直接执行步骤s506，其中，扩展服务名字可能存在多个，在更新时也应当以扩展服务名字为单元分别进行处理；
99.步骤s504，判断实际服务数据知否有可用实例，若有则执行步骤s505，若没有则执行步骤s506。
100.步骤s505，将当前时刻的实际服务数据更新为转发服务数据，新的流量转发将负载到新的转发服务数据中的后端；
101.步骤s506，不做任何动作，即保持上一次的后端不变。
102.之后则重复上述过程，等待定时任务触发，以此循环完成动态更新的过程。
103.基于上述方法，本公开提供了一种数据转发方法，能够结合内部名字服务的特性进行upstream动态转发的功能，通过服务启动时结合nginx开放的扩展开发钩子得到扩展服务名称，以及服务发现sdk获取服务数据并动态更新两个核心的流程，实现了nginx动态upstream的实现。
104.一方面，结合了名字服务自身提供的能力，如服务发现、流量调度、实例剔除，权重修改等，实现接入层upstream的动态变更和流量调度，解决实例异常的动态感知能力和局部(单可用区)流量异常时的流量切换能力，管理纬度和名字服务保持一致，无需引入域名解析等第三方服务，提供稳定高可靠的反向代理能力，满足企业内部的服务治理和稳定性管理要求，很大程度的降低了接入层服务管理的维护成本；
105.另一方面，能够充分利用反向代理服务器的upstream模块提供的后端server的负载均衡相关能力，做差异化流量调度和容错功能支持，实现压测、容量预估等其他运维管理需求。
106.图6示意性示出本公开示例性实施例中一种数据转发装置的组成示意图，如图6所示，该数据转发装置600可以包括解析模块601、配置模块602、获取模块603以及更新模块604。其中：
107.解析模块601，用于响应于服务启动指令，解析名字服务配置文件得到配置了名字服务的扩展服务名称；
108.配置模块602，用于获取名字服务中所述扩展服务名称对应的实际服务数据，基于
所述实际服务数据配置转发服务数据，并创建定时器以完成服务启动；
109.获取模块603，用于响应于所述定时器的触发任务，获取当前时刻下所述名字服务中所述扩展服务名称对应的实际服务数据；
110.更新模块604，用于基于当前时刻下的所述实际服务数据更新所述转发服务数据，以利用更新后的转发服务数据进行数据转发。
111.根据本公开的示例性实施例，配置模块602还用于通过名字服务软件开发工具获取所述实际服务数据；其中，所述名字服务软件开发工具是基于所述名字服务创建的。
112.根据本公开的示例性实施例，该数据转发装置600还可以包括修改模块，用于获取原生配置文件；以及基于反向代理服务和名字服务定义预设数据结构；按照所述预设数据结构对所述原生配置文件进行参数修改，得到所述名字服务配置文件。
113.根据本公开的示例性实施例，修改模块还用于将所述原生配置文件中的原始服务名称修改为所述扩展服务名称；创建所述扩展服务名称对应的格式服务数据，得到所述名字服务配置文件。
114.根据本公开的示例性实施例，配置模块602还用于将所述实际服务数据替换所述格式服务数据，以得到所述转发服务数据。
115.根据本公开的示例性实施例，配置模块602还用于在所述获取名字服务中所述扩展服务名称对应的实际服务数据之后，将所述实际服务数据更新至预先创建的共享内存。
116.根据本公开的示例性实施例，更新模块604还用于在所述实际服务数据和所述转发服务数据不一致，且所述实际服务数据包含可用实例时，将所述转发服务数据替换为所述实际服务数据；以及在所述实际服务数据和所述转发服务数据一致时，或者在所述实际服务数据不包含可用实例时，维持所述转发服务数据不变以完成更新。
117.上述的数据转发装置600中各模块的具体细节已经在对应的数据转发方法中进行了详细的描述，因此此处不再赘述。
118.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
119.在本公开的示例性实施例中，还提供了一种能够实现上述方法的存储介质。图7示意性示出本公开示例性实施例中一种计算机可读存储介质的示意图，如图7所示，描述了根据本公开的实施方式的用于实现上述方法的程序产品700，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如手机上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
120.在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。图8示意性示出本公开示例性实施例中一种电子设备的计算机系统的结构示意图。
121.需要说明的是，图8示出的电子设备的计算机系统800仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
122.如图8所示，计算机系统800包括中央处理单元(central processing unit，cpu)801，其可以根据存储在只读存储器(read-only memory，rom)802中的程序或者从存储部分
808加载到随机访问存储器(random access memory，ram)803中的程序而执行各种适当的动作和处理。在ram 803中，还存储有系统操作所需的各种程序和数据。cpu 801、rom 802以及ram 803通过总线804彼此相连。输入/输出(input/output，i/o)接口805也连接至总线804。
123.以下部件连接至i/o接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(cathode ray tube，crt)、液晶显示器(liquid crystal display，lcd)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如lan(local area network，局域网)卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至i/o接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。
124.特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(cpu)801执行时，执行本公开的系统中限定的各种功能。
125.需要说明的是，本公开实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(erasable programmable read only memory，eprom)、闪存、光纤、便携式紧凑磁盘只读存储器(compact disc read-only memory，cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
126.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规
定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
127.描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
128.作为另一方面，本公开还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。
129.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
130.通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。
131.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。
132.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

技术特征：
1.一种数据转发方法，其特征在于，包括：响应于服务启动指令，解析名字服务配置文件得到配置了名字服务的扩展服务名称；获取名字服务中所述扩展服务名称对应的实际服务数据，基于所述实际服务数据配置转发服务数据，并创建定时器以完成服务启动；响应于所述定时器的触发任务，获取当前时刻下所述名字服务中所述扩展服务名称对应的实际服务数据；基于当前时刻下的所述实际服务数据更新所述转发服务数据，以利用更新后的转发服务数据进行数据转发。2.根据权利要求1所述的数据转发方法，其特征在于，所述获取名字服务中所述扩展服务名称对应的实际服务数据，包括：通过名字服务软件开发工具获取所述实际服务数据；其中，所述名字服务软件开发工具是基于所述名字服务创建的。3.根据权利要求1所述的数据转发方法，其特征在于，在所述响应于服务启动指令之前，所述方法还包括：获取原生配置文件；以及基于反向代理服务和名字服务定义预设数据结构；按照所述预设数据结构对所述原生配置文件进行参数修改，得到所述名字服务配置文件。4.根据权利要求3所述的数据转发方法，其特征在于，所述按照所述预设数据结构对所述原生配置文件进行参数修改，得到所述名字服务配置文件，包括：将所述原生配置文件中的原始服务名称修改为所述扩展服务名称；创建所述扩展服务名称对应的格式服务数据，得到所述名字服务配置文件。5.根据权利要求4所述的数据转发方法，其特征在于，所述基于所述实际服务数据配置转发服务数据，包括：将所述实际服务数据替换所述格式服务数据，以得到所述转发服务数据。6.根据权利要求1所述的数据转发方法，其特征在于，在所述获取名字服务中所述扩展服务名称对应的实际服务数据之后，所述方法还包括：将所述实际服务数据更新至预先创建的共享内存。7.根据权利要求1所述的数据转发方法，其特征在于，所述基于所述当前时刻下的实际服务数据更新所述转发服务数据，包括：在所述实际服务数据和所述转发服务数据不一致，且所述实际服务数据包含可用实例时，将所述转发服务数据替换为所述实际服务数据；以及在所述实际服务数据和所述转发服务数据一致时，或者在所述实际服务数据不包含可用实例时，维持所述转发服务数据不变以完成更新。8.一种数据转发装置，其特征在于，包括：解析模块，用于响应于服务启动指令，解析名字服务配置文件得到配置了名字服务的扩展服务名称；配置模块，用于获取名字服务中所述扩展服务名称对应的实际服务数据，基于所述实际服务数据配置转发服务数据，并创建定时器以完成服务启动；
获取模块，用于响应于所述定时器的触发任务，获取当前时刻下所述名字服务中所述扩展服务名称对应的实际服务数据；更新模块，用于基于当前时刻下的所述实际服务数据更新所述转发服务数据，以利用更新后的转发服务数据进行数据转发。9.一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如权利要求1至7任一项所述的数据转发方法。10.一种电子设备，其特征在于，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至7任一项所述的数据转发方法。

技术总结
本公开涉及计算机技术领域，具体涉及一种数据转发方法、数据转发装置、存储介质及电子设备。该数据转发方法包括：响应于服务启动指令，解析名字服务配置文件得到配置了名字服务的扩展服务名称；获取名字服务中所述扩展服务名称对应的实际服务数据，基于所述实际服务数据配置转发服务数据，并创建定时器以完成服务启动；响应于所述定时器的触发任务，获取当前时刻下所述名字服务中所述扩展服务名称对应的实际服务数据；基于当前时刻下的所述实际服务数据更新所述转发服务数据，以利用更新后的转发服务数据进行数据转发。本公开提供的数据转发方法能够实现基于服务发现的反向代理服务器动态数据转发。务器动态数据转发。务器动态数据转发。


技术研发人员：王永瑞 陈存利 朱凤元
受保护的技术使用者：度小满科技(北京)有限公司
技术研发日：2023.06.20
技术公布日：2023/10/15