基于探针交易的服务状态更新方法和装置与流程

文档序号:30507277发布日期:2022-06-25 00:44阅读:86来源:国知局
基于探针交易的服务状态更新方法和装置与流程

1.本公开涉及服务架构技术领域,更具体地涉及一种基于探针交易的服务状态更新方法、装置、设备、存储介质和程序产品。


背景技术:

2.软件架构体系设计时,需要考虑服务器的注册及服务发现,以达到服务器集群高可用的目的。
3.在实际的应用过程中,会独立创建服务注册集群,例如springcloud采用的eureka实现方式中,不仅需要考虑服务注册集群的高可用,还需要占用大量的服务器资源。注册方出现数据库故障、应用服务器未出现故障时,注册服务器无法及时识别,剔除服务,进而影响服务调用方体验;当注册服务器宕机时,只能通过客户端缓存模式来获取服务注册信息,不能获取最新的服务注册状态。


技术实现要素:

4.鉴于上述问题,本公开提供了基于探针交易的服务状态更新方法、装置、设备、介质和程序产品。
5.根据本公开的第一个方面,提供了一种基于探针交易的服务状态更新方法,应用于客户端,包括:
6.获取服务清单,所述服务清单预先配置在所述客户端中;
7.根据所述服务清单定时调用探针交易轮询服务端;
8.接收各服务端返回的服务状态码信息,所述服务状态码信息用于表征各服务的状态以及所述各服务对应的数据库状态;以及
9.根据所述服务状态码信息更新所述服务清单。
10.根据本公开的实施例,所述服务清单包括服务名、服务地址和服务状态信息,所述根据所述服务清单定时调用探针交易轮询服务端包括:
11.获取各服务的服务地址;以及
12.根据所述各服务的服务地址调用探针交易。
13.根据本公开的实施例,所述根据所述服务状态码信息更新所述服务清单包括:
14.根据所述服务状态码信息确定所述各服务的当前服务状态;以及
15.根据所述当前服务状态更新所述服务清单。
16.根据本公开的实施例,所述各服务的当前服务状态包括可用状态和不可用状态,所述根据所述服务状态码信息确定所述各服务的当前服务状态包括:
17.根据所述服务状态码信息确定服务异常类型;以及
18.若确定存在所述服务异常类型,则确定当前服务状态为不可用状态。
19.根据本公开的实施例,所述服务异常类型包括服务器探针交易超时、探针交易访问数据库失败和探针交易返回报文失败中的一种或多种。
20.本公开的第二方面提供了一种基于探针交易的服务状态更新装置,应用于客户端,包括:
21.获取模块,用于获取服务清单,所述服务清单预先配置在所述客户端中;
22.查询模块,用于根据所述服务清单定时调用探针交易轮询服务端;
23.接收模块,用于接收各服务端返回的服务状态码信息,所述服务状态码信息用于表征各服务的状态以及所述各服务对应的数据库状态;以及
24.更新模块,用于根据所述服务状态码信息更新所述服务清单。
25.本公开的第三方面提供了一种电子设备,包括:一个或多个处理器;存储器,用于存储一个或多个程序,其中,当所述一个或多个程序被所述一个或多个处理器执行时,使得一个或多个处理器执行上述基于探针交易的服务状态更新。
26.本公开的第四方面还提供了一种计算机可读存储介质,其上存储有可执行指令,该指令被处理器执行时使处理器执行上述基于探针交易的服务状态更新方法。
27.本公开的第五方面还提供了一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现上述基于探针交易的服务状态更新方法。
28.根据本公开实施例提供的基于探针交易的服务状态更新方法,通过采用客户端与服务端直连探测,定时调用探针交易轮询服务清单中各服务的服务状态以及对应数据库状态,根据各服务的服务状态更新服务清单,通过将服务清单设置在客户端取代单独的服务注册中心节点,由客户端维护各自的服务清单,无需维护单独的注册中心节点;当数据库出现故障时,也可以及时更新服务状态,以解决上述技术问题。
附图说明
29.通过以下参照附图对本公开实施例的描述,本公开的上述内容以及其他目的、特征和优点将更为清楚,在附图中:
30.图1示意性示出了根据本公开实施例的基于探针交易的服务状态更新方法的应用场景图;
31.图2示意性示出了根据本公开实施例的基于探针交易的服务状态更新方法的流程图;
32.图3示意性示出了根据本公开实施例的调用探针交易的方法的流程图;
33.图4示意性示出了根据本公开实施例的服务清单更新方法的流程图;
34.图5示意性示出了根据本公开实施例的基于探针交易的服务状态更新装置的结构框图;以及
35.图6示意性示出了根据本公开实施例的适于实现基于探针交易的服务状态更新方法的电子设备的方框图。
具体实施方式
36.以下,将参照附图来描述本公开的实施例。但是应该理解,这些描述只是示例性的,而并非要限制本公开的范围。在下面的详细描述中,为便于解释,阐述了许多具体的细节以提供对本公开实施例的全面理解。然而,明显地,一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外,在以下说明中,省略了对公知结构和技术的描述,以避免
不必要地混淆本公开的概念。
37.在此使用的术语仅仅是为了描述具体实施例,而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了特征、步骤、操作和/或部件的存在,但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
38.在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义,除非另外定义。应注意,这里使用的术语应解释为具有与本说明书的上下文相一致的含义,而不应以理想化或过于刻板的方式来解释。
39.在使用类似于“a、b和c等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。
40.在软件架构体系设计时,需要考虑服务器的注册及服务发现,以达到服务器集群高可用的目的,但在实际的应用过程中,以springcloud采用的eureka实现方式为例,eureka server需要集群模式独立部署维护,只有一个服务注册中心,不符合高可用的原则,实现高可用就需要增加eureka server的数量,导致维护成本过高;如果eureka server服务集群全部宕机则只能通过客户端的缓存模式来获取服务注册信息,不能获取最新的服务注册状态;因为网络问题(例如心跳慢被剔除)而被剔除出去的服务器本身是“健康”的,只是因为网络分割故障把eureka集群分割成了独立的子网导致不能互访;当服务端数据库出现故障时,如果对应的应用服务器是“健康”状态,则不会取消该应用服务器的注册,但调用该应用服务器的交易会发生失败。
41.基于上述技术问题,本公开的实施例提供了一种基于探针交易的服务状态更新方法,应用于客户端,包括:获取服务清单,所述服务清单预先配置在所述客户端中;根据所述服务清单定时调用探针交易轮询服务端;接收各服务端返回的服务状态码信息,所述服务状态码信息用于表征各服务的状态以及所述各服务对应的数据库状态;以及根据所述服务状态码信息更新所述服务清单。
42.图1示意性示出了根据本公开实施例的基于探针交易的服务状态更新方法的应用场景图。
43.如图1所示,根据该实施例的应用场景100可以包括服务注册及调用场景。网络104用以在客户端101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
44.用户可以使用客户端101、102、103通过网络104与服务器105交互,以接收或发送消息等。客户端101、102、103上可以安装有各种通讯客户端应用,例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
45.服务器105可以是提供各种服务的服务器,例如相应于用户利用客户端101、102、103所发起服务调用请求,提供相应的服务的应用服务器(仅为示例)。应用服务器可以对接收到的用户服务调用请求等数据进行分析等处理,并将对客户端提供服务。
46.需要说明的是,本公开实施例所提供的基于探针交易的服务状态更新方法一般可以由服务器105执行。相应地,本公开实施例所提供的基于探针交易的服务状态更新装置一般可以设置于服务器105中。本公开实施例所提供的基于探针交易的服务状态更新方法也
可以由不同于服务器105且能够与客户端101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地,本公开实施例所提供的基于探针交易的服务状态更新装置也可以设置于不同于服务器105且能够与客户端101、102、103和/或服务器105通信的服务器或服务器集群中。
47.应该理解,图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。
48.以下将基于图1描述的场景,通过图2~图4对公开实施例的基于探针交易的服务状态更新方法进行详细描述。
49.图2示意性示出了根据本公开实施例的基于探针交易的服务状态更新方法的流程图。
50.如图2所示,该实施例的基于探针交易的服务状态更新方法包括操作s210~操作s240,该基于探针交易的服务状态更新方法可以由客户端服务器执行,本公开实施例适用于调用方与服务注册方服务数量较少的场景,采用cs模式(client-server),即多台客户端对应多台服务端的模块,实现服务状态动态刷新和服务调用,即服务调用方(客户端)与服务提供方(服务端)直连,无需服务注册中心节点。
51.在操作s210,获取服务清单。在操作s220,根据所述服务清单定时调用探针交易轮询服务端。
52.根据本公开实施例,所述服务清单预先配置在所述客户端中。
53.根据本公开实施例,所述服务清单包括服务名、服务地址和服务状态信息。
54.一个示例中,每个客户端都配置有一份服务清单,服务清单上预先配置有服务名称、服务地址和服务状态。每个客户端各自维护服务清单,相对于设置服务注册中心的模式,仅占用一小部分内存存储服务清单列表,无需占用大量系统资源,提高了可用性。
55.为及时获取到各服务端最新的服务状态,避免由于服务状态更新不及时影响服务调用方的使用。客户端会根据配置的服务清单定时调用探针交易轮询服务端以获取服务的状态。探针交易包括服务可用性探测和数据库可用性探测。具体轮询调用过程可参见图3所示的操作s221~操作s222。
56.在操作s230,接收各服务端返回的服务状态码信息。
57.在操作s240,根据所述服务状态码信息更新所述服务清单。
58.根据本公开实施例,所述服务状态码信息用于表征各服务的状态以及所述各服务对应的数据库状态。
59.一个示例中,在操作s230之后,客户端调用探针交易后,相当于向各个服务端发动查询请求,查询各服务的状态以及各服务对应的数据库的联通状态,相比于现有技术,本公开实施例中探针交易由于包括数据库可用性探测,能够识别出应用服务状态为可用,而数据库不可用导致服务调用方无法调用相应服务的异常情况,服务状态信息更准确。响应于探针交易的调用请求,服务端会将查询结果返回值客户端,接收从服务端返回的服务状态码信息,根据该服务状态码信息可以确定当前各服务的异常情况或场景,进而确定各服务的服务状态。更新服务清单中各服务的服务状态。具体的更新过程可参见图4所示的操作s241~操作s242。
60.根据本公开实施例提供的基于探针交易的服务状态更新方法,通过采用客户端与
服务端直连探测,定时调用探针交易轮询服务清单中各服务的服务状态以及对应数据库状态,根据各服务的服务状态更新服务清单,通过将服务清单设置在客户端取代单独的服务注册中心节点,由客户端维护各自的服务清单,无需维护单独的注册中心节点;当数据库出现故障时,也可以及时更新服务状态。
61.图3示意性示出了根据本公开实施例的调用探针交易的方法的流程图。如图3所示,该实施例调用探针交易的步骤包括操作s221~操作s222。
62.在操作s221,获取各服务的服务地址。在操作s222,根据所述各服务的服务地址调用探针交易。
63.根据本公开实施例,所述服务清单包括服务名、服务地址和服务状态信息。
64.一个示例中,客户端会根据配置的服务清单定时调用探针交易轮询服务端以获取服务的状态。server服务提供探针交易,client端定时针对每台serve调用探针交易,server端提供/rcc/exetrans探针交易供调用。首先很据服务清单获取要查询服务的服务地址,访问该服务地址调用服务端提供的探针交易。
65.接下来将结合图4介绍根据所述服务状态码信息更新所述服务清单的过程。
66.图4示意性示出了根据本公开实施例的服务清单更新方法的流程图。
67.如图4所示,操作s240包括操作s241和操作s242。
68.在操作s241,根据所述服务状态码信息确定所述各服务的当前服务状态。在操作s242,根据所述当前服务状态更新所述服务清单。
69.根据本公开实施例,所述各服务的当前服务状态包括可用状态和不可用状态;根据所述服务状态码信息确定服务异常类型;以及若确定存在所述服务异常类型,则确定当前服务状态为不可用状态。
70.根据本公开实施例,所述服务异常类型包括服务器探针交易超时、探针交易访问数据库失败和探针交易返回报文失败中的一种或多种。
71.本公开实施例中服务异常类型主要分为三种,包括服务器探针交易超时、探针交易访问数据库失败和探针交易返回报文失败。例如,如果client端访问服务器探针交易超时,client端设置访问返回状态码为01;如果server端探针交易访问数据库失败,在返回报文头中设置状态码为02;如果server端探针交易异常导致框架转换返回报文失败,返回报文头中设置状态码03。根据服务状态码信息能够确定具体的服务异常类型。为了保证服务的高可用性,当出现上述任意一项服务异常类型时,则确定当前服务状态为不可用状态,并在服务清单中更新服务状态。
72.基于上述基于探针交易的服务状态更新方法,本公开还提供了一种基于探针交易的服务状态更新装置。以下将结合图6对该装置进行详细描述。
73.图5示意性示出了根据本公开实施例的基于探针交易的服务状态更新装置的结构框图。
74.如图5所示,该实施例的基于探针交易的服务状态更新装置500包括获取模块510、查询模块520、接收模块530和更新模块540。
75.获取模块510用于获取服务清单,所述服务清单预先配置在所述客户端中。在一实施例中,获取模块510可以用于执行前文描述的操作s210,在此不再赘述。
76.查询模块520用于根据所述服务清单定时调用探针交易轮询服务端。在一实施例
中,查询模块520可以用于执行前文描述的操作s220,在此不再赘述。
77.接收模块530用于接收各服务端返回的服务状态码信息,所述服务状态码信息用于表征各服务的状态以及所述各服务对应的数据库状态。在一实施例中,接收模块530可以用于执行前文描述的操作s230,在此不再赘述。
78.更新模块540用于根据所述服务状态码信息更新所述服务清单。在一实施例中,更新模块540可以用于执行前文描述的操作s240,在此不再赘述。
79.根据本公开实施例,查询模块520包括获取子模块521和调用子模块522。
80.获取子模块521用于获取各服务的服务地址。在一实施例中,获取子模块521可以用于执行前文描述的操作s221,在此不再赘述。
81.调用子模块522用于根据所述各服务的服务地址调用探针交易。在一实施例中,调用子模块522可以用于执行前文描述的操作s222,在此不再赘述。
82.根据本公开实施例,更新模块540包括确定子模块541和更新子模块542。
83.确定子模块541用于根据所述服务状态码信息确定所述各服务的当前服务状态。在一实施例中,确定子模块542可以用于执行前文描述的操作s241,在此不再赘述。
84.更新子模块542用于根据所述当前服务状态更新所述服务清单。在一实施例中,更新子模块542可以用于执行前文描述的操作s242,在此不再赘述。
85.根据本公开实施例,确定子模块541包括第一确定单元5411和第二确定单元5412。
86.第一确定单元5411用于根据所述服务状态码信息确定服务异常类型。在一实施例中,第一确定单元5411可以用于执行前文描述的操作s241,在此不再赘述。
87.第二确定单元5412用于若确定存在所述服务异常类型,则确定当前服务状态为不可用状态。在一实施例中,第二确定单元5412可以用于执行前文描述的操作s241,在此不再赘述。
88.根据本公开的实施例,获取模块510、查询模块520、接收模块530和更新模块540中的任意多个模块可以合并在一个模块中实现,或者其中的任意一个模块可以被拆分成多个模块。或者,这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合,并在一个模块中实现。根据本公开的实施例,获取模块510、查询模块520、接收模块530和更新模块540中的至少一个可以至少被部分地实现为硬件电路,例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic),或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现,或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者,获取模块510、查询模块520、接收模块530和更新模块540中的至少一个可以至少被部分地实现为计算机程序模块,当该计算机程序模块被运行时,可以执行相应的功能。
89.图6示意性示出了根据本公开实施例的适于实现基于探针交易的服务状态更新方法的电子设备的方框图。
90.如图6所示,根据本公开实施例的电子设备900包括处理器901,其可以根据存储在只读存储器(rom)902中的程序或者从存储部分908加载到随机访问存储器(ram)903中的程序而执行各种适当的动作和处理。处理器901例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如,专用集成电路(asic))等等。处理器901还可以包括用于缓存用途的板载存储器。处理器901可以包括用于执行根据本公开实施
例的方法流程的不同动作的单一处理单元或者是多个处理单元。
91.在ram 903中,存储有电子设备900操作所需的各种程序和数据。处理器901、rom 902以及ram 903通过总线904彼此相连。处理器901通过执行rom 902和/或ram 903中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意,程序也可以存储在除rom 902和ram 903以外的一个或多个存储器中。处理器901也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
92.根据本公开的实施例,电子设备900还可以包括输入/输出(i/o)接口905,输入/输出(i/o)接口905也连接至总线904。电子设备900还可以包括连接至i/o接口905的以下部件中的一项或多项:包括键盘、鼠标等的输入部分906;包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分907;包括硬盘等的存储部分908;以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至i/o接口905。可拆卸介质911,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器910上,以便于从其上读出的计算机程序根据需要被安装入存储部分908。
93.本公开还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的;也可以是单独存在,而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序,当上述一个或者多个程序被执行时,实现根据本公开实施例的基于探针交易的服务状态更新方法。
94.根据本公开的实施例,计算机可读存储介质可以是非易失性的计算机可读存储介质,例如可以包括但不限于:便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如,根据本公开的实施例,计算机可读存储介质可以包括上文描述的rom 902和/或ram 903和/或rom 902和ram 903以外的一个或多个存储器。
95.本公开的实施例还包括一种计算机程序产品,其包括计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机系统中运行时,该程序代码用于使计算机系统实现本公开实施例所提供的基于探针交易的服务状态更新方法。
96.在该计算机程序被处理器901执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例,上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。
97.在一种实施例中,该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中,该计算机程序也可以在网络介质上以信号的形式进行传输、分发,并通过通信部分909被下载和安装,和/或从可拆卸介质911被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输,包括但不限于:无线、有线等等,或者上述的任意合适的组合。
98.在这样的实施例中,该计算机程序可以通过通信部分909从网络上被下载和安装,和/或从可拆卸介质911被安装。在该计算机程序被处理器901执行时,执行本公开实施例的
系统中限定的上述功能。根据本公开的实施例,上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
99.根据本公开的实施例,可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码,具体地,可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如java,c++,python,“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中,远程计算设备可以通过任意种类的网络,包括局域网(lan)或广域网(wan),连接到用户计算设备,或者,可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
100.附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
101.本领域技术人员可以理解,本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合,即使这样的组合或结合没有明确记载于本公开中。特别地,在不脱离本公开精神和教导的情况下,本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。
102.以上对本公开的实施例进行了描述。但是,这些实施例仅仅是为了说明的目的,而并非为了限制本公开的范围。尽管在以上分别描述了各实施例,但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围,本领域技术人员可以做出多种替代和修改,这些替代和修改都应落在本公开的范围之内。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1