CN110581890B - 一种服务请求的路由方法和装置 - Google Patents

一种服务请求的路由方法和装置 Download PDF

Info

Publication number
CN110581890B
CN110581890B CN201910853260.6A CN201910853260A CN110581890B CN 110581890 B CN110581890 B CN 110581890B CN 201910853260 A CN201910853260 A CN 201910853260A CN 110581890 B CN110581890 B CN 110581890B
Authority
CN
China
Prior art keywords
routing
server
service request
request
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910853260.6A
Other languages
English (en)
Other versions
CN110581890A (zh
Inventor
欧明辉
陈大平
程明远
曹广平
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Construction Bank Corp
Original Assignee
China Construction Bank Corp
CCB Finetech Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Construction Bank Corp, CCB Finetech Co Ltd filed Critical China Construction Bank Corp
Priority to CN201910853260.6A priority Critical patent/CN110581890B/zh
Publication of CN110581890A publication Critical patent/CN110581890A/zh
Application granted granted Critical
Publication of CN110581890B publication Critical patent/CN110581890B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种服务请求的路由方法和装置，涉及计算机技术领域。该方法的一具体实施方式包括：第一服务器接收请求端发来的服务请求并对其报文内容进行解析，得到路由数据元；第一服务器根据路由数据元确定目标节点；当目标节点不包括第一服务器时，第一服务器在目标节点对应的服务地址列表中选取一个服务地址作为目标服务地址，并将服务请求路由到目标服务地址对应的第二服务器。该实施方式能够根据数据内容对请求路由，不依赖特定软件系统，可自定义报文格式，通用性强、适用范围广，路由规则灵活并可动态加载更新，而无需重启服务器，支持多数据元组合，适于多服务共用单一接入地址系统，方便服务请求跟踪和监控。

Description

一种服务请求的路由方法和装置
技术领域
本发明涉及计算机技术领域，尤其涉及一种服务请求的路由方法和装置。
背景技术
目前大型应用系统通常需要分布式部署，建设异地多中心进行灾备部署。不同中心之间处于独立状态，存储、数据库等都不共享，但是一些整合度高的业务依赖业务上下文，传统的服务请求路由一般是基于链路层或者协议层，无法根据数据内容对服务请求路由。其中，方案一是基于中间件TUXEDO(一个支持分布式事务的中间件系统)，客户端请求发往其中一台TUXEDO服务器，请求经过路由后调用对应服务，如果服务是本地TUXEDO服务器提供的则在本地处理，如果是映射自其他TUXEDO服务器的，则由本地TUXEDO服务器转发请求到实际提供服务的TUXEDO服务器处理；方案二是服务端收到服务请求后，根据请求URI(统一资源标识符)地址判断是否需要路由，如果需要路由则将请求发往对应的服务器地址，或者通知请求方把请求重新发往另外一个URL地址以其他服务器处理。
在实现本发明过程中，发明人发现现有技术中至少存在如下问题：
无法根据数据内容对服务请求路由；
基于中间件路由需要依赖中间件TUXEDO，从客户端到服务端都需要按TUXEDO的标准接口交互，不支持HTTP(超文本传输协议)协议，适用范围小，且路由规则、服务映射关系通过记录在配置文件中，需重启服务器才能使配置生效，不利于服务连续性和快速维护；路由只能针对单个数据元，不支持多个数据元组合；
基于请求地址路由不适用于多个服务共用单一接入地址的系统，原始服务方无法记录请求中的数据，不利于对请求的跟踪及监控，请求重定向依赖客户端支持重定向技术，对于采用简单轻量级HTTP客户端(不支持重定向)的应用系统则无法路由。
发明内容
有鉴于此，本发明实施例提供一种服务请求的路由方法和装置，能够根据数据内容对服务请求路由，不依赖特定软件系统(中间件)，可以自定义报文格式，通用性强、适用范围广，路由规则可从数据库动态加载更新，而无需重启服务器，服务连续性和可维护性好，支持多个数据元组合，可适用于多个服务共用单一接入地址的系统，路由规则灵活，可记录服务请求痕迹，方便对服务请求进行跟踪和监控，对于采用轻量级HTTP客户端的应用系统也实现路由。
为实现上述目的，根据本发明实施例的一个方面，提供了一种服务请求的路由方法。
一种服务请求的路由方法，包括：第一服务器接收请求端以报文方式发来的服务请求，并对所述服务请求的报文内容进行解析，得到路由数据元；所述第一服务器根据所述路由数据元，确定可处理所述服务请求的目标节点，所述目标节点包括一组服务器；在所述目标节点不包括所述第一服务器的情况下，所述第一服务器按照预设的选取规则在所述目标节点对应的服务地址列表中选取一个服务地址作为目标服务地址；所述第一服务器将所述服务请求路由到所述目标服务地址对应的第二服务器。
可选地，所述服务请求的报文内容基于HTTP协议，其中携带请求地址，对所述服务请求的报文内容进行解析，得到路由数据元的步骤，包括：按照配置的请求地址与报文格式之间的对应关系，查找与所述服务请求携带的请求地址所对应的目标报文格式；根据所述目标报文格式解析所述服务请求的报文内容，以得到多个数据元；将所述多个数据元之中与配置的数据元一致的数据元作为所述路由数据元。
可选地，所述路由数据元的个数为一个或多个，且通过对所述服务请求的报文内容解析，还得到所述路由数据元的值；所述第一服务器根据所述路由数据元，确定可处理所述服务请求的目标节点的步骤，包括：所述第一服务器读取当前已加载的路由规则表，所述路由规则表中的每一路由规则记录节点和与所述节点对应的路由条件，且所述每一路由规则中的节点数和路由条件数均为一个或多个；所述第一服务器根据所述路由数据元的个数，从所述路由规则表中选出一个或多个路由规则，其中，选出的每一路由规则记录的路由条件数与所述路由数据元的个数相同；在选出的所述一个或多个路由规则中，按照预设规则查找出一个记录的路由条件与所述路由数据元的值匹配的路由规则，并将该查找出的路由规则记录的节点作为可处理所述服务请求的目标节点。
可选地，所述第一服务器按照预设的时间间隔，定期从保存所述路由规则的数据库表中获取已启用的节点对应的路由规则，以组成所述路由规则表，并将所述路由规则表加载到内存，其中，所述数据库表中保存的所述路由规则可动态配置及更新。
可选地，所述第一服务器将所述服务请求路由到所述目标服务地址对应的第二服务器的步骤，包括：所述第一服务器按照所述服务请求重新生成待路由服务请求，所述待路由服务请求中的参数与所述服务请求的参数相同；所述第一服务器将所述待路由服务请求路由到所述目标服务地址对应的第二服务器。
可选地，还包括：所述第一服务器在本地日志记录所述路由数据元和唯一跟踪号，所述唯一跟踪号是由所述第一服务器生成的或者由所述第一服务器从所述报文内容中解析得到的，用于对所述服务请求进行跟踪和监控；所述第一服务器将所述服务请求路由到所述目标服务地址对应的第二服务器的步骤之后，还包括：接收并在所述本地日志记录所述第二服务器返回的响应数据，然后将所述响应数据返回所述请求端。
根据本发明实施例的另一方面，提供了一种服务请求的路由装置。
一种服务请求的路由装置，包括：请求接收和解析模块，用于第一服务器接收请求端以报文方式发来的服务请求，并对所述服务请求的报文内容进行解析，得到路由数据元；目标节点确定模块，用于所述第一服务器根据所述路由数据元，确定可处理所述服务请求的目标节点，所述目标节点包括一组服务器；服务地址选取模块，用于在所述目标节点不包括所述第一服务器的情况下，所述第一服务器按照预设的选取规则在所述目标节点对应的服务地址列表中选取一个服务地址作为目标服务地址；服务请求路由模块，用于所述第一服务器将所述服务请求路由到所述目标服务地址对应的第二服务器。
可选地，所述服务请求的报文内容基于HTTP协议，其中携带请求地址，所述请求接收和解析模块包括报文内容解析单元，用于：按照配置的请求地址与报文格式之间的对应关系，查找与所述服务请求携带的请求地址所对应的目标报文格式；根据所述目标报文格式解析所述服务请求的报文内容，以得到多个数据元；将所述多个数据元之中与配置的数据元一致的数据元作为所述路由数据元。
可选地，所述路由数据元的个数为一个或多个，且通过对所述服务请求的报文内容解析，还得到所述路由数据元的值；所述目标节点确定模块还用于：所述第一服务器读取当前已加载的路由规则表，所述路由规则表中的每一路由规则记录节点和与所述节点对应的路由条件，且所述每一路由规则中的节点数和路由条件数均为一个或多个；所述第一服务器根据所述路由数据元的个数，从所述路由规则表中选出一个或多个路由规则，其中，选出的每一路由规则记录的路由条件数与所述路由数据元的个数相同；在选出的所述一个或多个路由规则中，按照预设规则查找出一个记录的路由条件与所述路由数据元的值匹配的路由规则，并将该查找出的路由规则记录的节点作为可处理所述服务请求的目标节点。
可选地，还包括路由规则表加载模块，用于所述第一服务器按照预设的时间间隔，定期从保存所述路由规则的数据库表中获取已启用的节点对应的路由规则，以组成所述路由规则表，并将所述路由规则表加载到内存，其中，所述数据库表中保存的所述路由规则可动态配置及更新。
可选地，所述服务请求路由模块还用于：所述第一服务器按照所述服务请求重新生成待路由服务请求，所述待路由服务请求中的参数与所述服务请求的参数相同；所述第一服务器将所述待路由服务请求路由到所述目标服务地址对应的第二服务器。
可选地，还包括日志记录模块，用于：所述第一服务器在本地日志记录所述路由数据元和唯一跟踪号，所述唯一跟踪号是由所述第一服务器生成的或者由所述第一服务器从所述报文内容中解析得到的，用于对所述服务请求进行跟踪和监控；所述日志记录模块还用于：接收并在所述本地日志记录所述第二服务器返回的响应数据。
根据本发明实施例的又一方面，提供了一种电子设备。
一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现本发明提供的服务请求的路由方法。
根据本发明实施例的又一方面，提供了一种计算机可读介质。
一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明提供的服务请求的路由方法。
上述发明中的一个实施例具有如下优点或有益效果：第一服务器接收请求端以报文方式发来的服务请求，并对服务请求的报文内容解析以得到路由数据元，根据路由数据元进行服务请求路由，能够根据数据内容对服务请求路由，不依赖特定软件系统(中间件)，可以自定义报文格式，通用性强、适用范围广。对服务请求路由所使用的路由规则表从数据库动态加载更新，而无需重启服务器，服务连续性和可维护性好。支持多个数据元组合，可适用于多个服务共用单一接入地址的系统，路由规则中的路由条件也可以为一个或多个，可支持表达式配置，路由规则十分灵活。通过本地日志可记录服务请求痕迹，方便对服务请求进行跟踪和监控。通过根据服务请求重新生成新的待路由服务请求，以将待路由服务请求路由到相应的服务器，无需对请求重定向，从而对于采用轻量级HTTP客户端的应用系统也实现路由。
上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。
附图说明
附图用于更好地理解本发明，不构成对本发明的不当限定。其中：
图1是根据本发明第一实施例的服务请求的路由方法的主要步骤示意图；
图2是根据本发明第二实施例的服务请求的路由流程示意图；
图3是根据本发明第三实施例的服务请求解析流程示意图；
图4是根据本发明第四实施例的基于交易系统的路由示意图；
图5是根据本发明第五实施例的服务请求的路由装置的主要模块示意图；
图6是本发明实施例可以应用于其中的示例性系统架构图；
图7是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。
具体实施方式
以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
本领域技术技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
图1是根据本发明第一实施例的服务请求的路由方法的主要步骤示意图。
如图1所示，本发明一个实施例的服务请求的路由方法由第一服务器执行，方法主要包括如下的步骤S101至步骤S104。
步骤S101：第一服务器接收请求端以报文方式发来的服务请求，并对服务请求的报文内容进行解析，得到路由数据元。
报文是按特定格式组合表述数据的文本内容。
请求端可以为客户端，也可以为与第一服务器以及下文的第二服务器不同的其他服务器。
服务请求的报文内容基于HTTP协议，其中携带请求地址，该请求地址是由请求端提供的。请求端按服务请求的报文格式向第一服务器提供相对应的URL(统一资源定位符)地址(即请求地址)，报文格式例如xml(可扩展标记语言)、定长报文、JSON(JavaScriptObject Notation，JS对象简谱)等格式。报文格式不同，请求端提供的请求地址也不同。
第一服务器可以预先将请求地址与报文格式之间的对应关系以及需要的数据元配置在文件中，并在第一服务器的系统启动时装载。当第一服务器收到服务请求后，按照配置的该对应关系即可查找到与服务请求携带的请求地址所对应的目标报文格式，以便进行报文内容的解析。
对服务请求的报文内容进行解析，得到路由数据元的步骤，具体可以包括：按照配置的请求地址与报文格式之间的对应关系，查找与服务请求携带的请求地址所对应的目标报文格式；根据目标报文格式解析服务请求的报文内容，以得到多个数据元；将多个数据元之中与配置的数据元一致的数据元作为路由数据元。
从报文内容解析得到的多个数据元，不同数据元有不同的名称(如如下的name、acct、tradNo)：
name：abc；
acct：1234；
tradNo:AB123；
路由需要的数据元只是个别数据元，假设根据上述的tradNo进行路由，那么在配置文件里配置的数据元为tradNo，数据元又称字段，配置文件里配置的数据元又称关键字段，例如本例中tradNo即为一个关键字段。如果对报文内容解析得到的多个数据元中有一个数据元为tradNo，则该数据元即为路由数据元。
对服务请求的报文内容进行解析，得到的路由数据元的个数可以为一个或多个，另外，还可解析得到各路由数据元的值。
步骤S102：第一服务器根据路由数据元，确定可处理服务请求的目标节点，目标节点包括一组服务器。
具体地，第一服务器读取当前已加载的路由规则表，路由规则表中的每一路由规则记录节点和与节点对应的路由条件，且每一路由规则中的节点数和路由条件数均为一个或多个；第一服务器根据路由数据元的个数，从路由规则表中选出一个或多个路由规则，其中，选出的每一路由规则记录的路由条件数与路由数据元的个数相同；在选出的一个或多个路由规则中，按照预设规则查找出一个记录的路由条件与路由数据元的值匹配的路由规则，并将该查找出的路由规则记录的节点作为可处理服务请求的目标节点。
第一服务器可以按照预设的时间间隔，定期从保存路由规则的数据库表中获取已启用的节点对应的路由规则，以组成路由规则表，并将路由规则表加载到内存，其中，数据库表中保存的路由规则可动态配置及更新。
表1示例性地示出了数据库表中保存的路由规则的各表项。
表1
Figure BDA0002197534380000091
第一服务器可以在系统启动后将已启用(即flag为0)的节点对应的路由规则组成路由规则表，并将路由规则表加载到内存，此后，可以每隔5分钟(仅为举例)自动刷新重新装载路由规则表，以从数据库得到最新配置的路由规则表。由于本发明实施例的路由规则表从数据库动态加载更新，而无需重启服务器，因此，服务连续性和可维护性好。
第一服务器根据路由数据元的个数，从路由规则表中选出一个或多个路由规则，具体地，可以选出记录的路由条件数与路由数据元的个数相同的路由规则。表2示例性地示出了路由规则表的形式。假设路由数据元的个数＝2，那么按照上述选出路由规则的方法，即选出记录的路由条件数为2的路由规则，即将表2的“条件1|条件2”和“条件2|条件3”对应的两行路由规则选出。多个路由条件之间用符号“|”分隔，表示该多个路有条件之间是“与”的关系，例如“条件1|条件2”表示条件1与条件2。本发明实施例的路由条件支持正则表达式，例如“条件1|条件2”具体可以为“A[1-5].*|[0,3].*”。表2中路由规则记录的节点也可以为多个，多个节点之间用符号“|”分隔，表示该多个节点之间是并列关系，例如“节点1|节点2”表示节点1和节点2是并列关系。
表2
节点 路由条件 状态flag
节点1 条件1|条件2 0
节点2 条件2|条件3 0
节点3 条件3 0
节点4 条件4 0
节点1|节点2 条件5 0
在确定可处理服务请求的目标节点时，结合表2，可以从上述选出的两个路由规则依次匹配检查是否符合路由条件，在查找到第一个符合的路由规则后即终止查找。具体地，先检查路由数据元的值与“条件1|条件2”是否匹配，以“条件1|条件2”是“A[1-5].*|[0,3].*”为例，对于解析得到的两个数据元，可以判断第一个路由数据元是否符合表达式A[1-5].*，同时第二个路由数据元是否符合表达式[0,3].*，若都符合，则“条件1|条件2”对应的路由规则即是所要查找出的路由规则，该路由规则记录的节点(“节点1”)即为可处理服务请求的目标节点，并且不再继续查找，即不再继续判断“条件2|条件3”是否与路由数据元的值匹配。只有当路由数据元的值与“条件1|条件2”不匹配的情况下，才继续检查路由数据元的值与“条件2|条件3”是否匹配。
判断路由数据元的值是否与路由条件匹配可以判断路由数据元的值是否与路由条件相等，如果相等表示二者匹配，如果不相等表示二者不匹配。
目标节点包括一组服务器，相应地，目标节点对应一个服务地址列表，服务地址列表中包括多个服务地址。例如，节点1包括分别对应以下多个服务地址：http://IP1:PORT1，http://IP2:PORT2，http://IP3:PORT3等的多个服务器，这些服务器都可以提供同样的服务。
步骤S103：在目标节点不包括第一服务器的情况下，第一服务器按照预设的选取规则在目标节点对应的服务地址列表中选取一个服务地址作为目标服务地址。
在确定可处理服务请求的目标节点之后，第一服务器可以先判断是否为本地节点，即判断目标节点是否包括第一服务器，若是，表示在第一服务器可提供服务来处理服务请求，而不需要对服务请求路由，那么返回的目标节点号为空，表示无需路由；若否，表示第一服务器不提供处理该服务请求的服务，而需要将服务请求路由到目标节点的一个服务器，那么返回目标节点号(每一节点有各自的节点号)。
在目标节点不包括第一服务器的情况下，第一服务器可以根据目标节点号在所有服务地址中找到与目标节点对应的服务地址列表，目标节点对应的服务地址列表中随机选取一个服务地址作为目标服务地址。为了保证这组服务地址负载均衡，采用轮询方式发送服务。
在目标节点包括第一服务器的情况下，由第一服务器本地处理服务请求，在本地完成处理后将响应结果(即响应数据)返回给请求端。
步骤S104：第一服务器将服务请求路由到目标服务地址对应的第二服务器。
具体地，第一服务器可以按照服务请求重新生成待路由服务请求；第一服务器将待路由服务请求路由到目标服务地址对应的第二服务器。
在重新生成待路由服务请求时，将服务请求的参数、报文重新封装到待路由服务请求中，待路由服务请求中的参数与该服务请求的参数一致。
图2是根据本发明第二实施例的服务请求的路由流程示意图。
如图2所示，本发明一个实施例的服务请求的路由流程主要包括如下的步骤S201至步骤S209。
步骤S201：第一服务器接收请求端以报文方式发来的服务请求，并对服务请求的报文内容进行解析，得到路由数据元。
步骤S202：第一服务器在本地日志记录路由数据元和唯一跟踪号。
其中，唯一跟踪号是由第一服务器生成的或者由第一服务器从报文内容中解析得到的，用于对服务请求进行跟踪和监控。
具体地，对于请求端为其他服务器的情况，该其他服务器在向第一服务器发送交易请求时会将对应该交易的唯一跟踪号添加到交易请求的报文中，第一服务器从服务请求的报文内容中可以解析得到唯一跟踪号。对于请求端为客户端的情况，客户端向第一服务器发送的交易请求中没有该交易的唯一跟踪号，这样，第一服务器会自行生成一个唯一跟踪号。
唯一跟踪号可以是一串字符，以服务请求为交易请求为例，每个交易请求都有各自的唯一跟踪号，在不同的应用系统之间可以根据唯一跟踪号对交易请求进行跟踪和监控，以定位某笔交易在处理过程中所经过的应用系统的服务器。
本地日志中还可以记录服务请求的报文中的日期、客户编号、客户端IP、账号等信息。
步骤S203：第一服务器根据路由数据元，确定可处理服务请求的目标节点，目标节点包括一组服务器。
步骤S204：第一服务器判断是否在本地处理服务请求，若是，则执行步骤S205，否则执行步骤S206。
第一服务器具体通过判断目标节点是否包括第一服务器，来判断是否在本地处理服务请求。如果目标节点包括第一服务器，则在本地处理服务请求，无需对服务请求路由；如果目标节点不包括第一服务器，则需要把服务请求路由到目标节点的一个服务器。
步骤S205：第一服务器处理服务请求得到响应数据，在本地日志记录该响应数据后，将该响应数据返回请求端。
步骤S206：第一服务器按照预设的选取规则在目标节点对应的服务地址列表中选取一个服务地址作为目标服务地址。
步骤S207：第一服务器按照服务请求重新封装得到待路由服务请求。
步骤S208：第一服务器将待路由服务请求路由到目标服务地址对应的第二服务器。
步骤S209：第一服务器接收并在本地日志记录第二服务器返回的响应数据，然后将响应数据返回请求端。
第一服务器可以根据第二服务器返回的响应数据，获取响应状态，然后把响应数据中的报文提取出来并返回给请求端。
图3是根据本发明第三实施例的服务请求解析流程示意图。
如图3所示，以服务请求为交易请求，请求端为客户端为例，本发明一个实施例的服务请求解析流程可以包括：
步骤S301：第一服务器接收客户端以报文方式发来的交易请求，交易请求基于HTTP协议，且其中携带请求的URL地址。
请求的URL地址即请求地址，通过该URL地址用于获得交易请求的报文格式。
步骤S302：第一服务器根据交易请求中的URL地址，得到交易请求的报文格式。
步骤S303：第一服务器根据报文格式解析交易请求的报文内容，得到指定路由字段以及日志需要记录的其他字段。
指定路由字段即路由数据元，日志需要记录的其他字段可以包括：报文中的日期、客户编号、客户端IP、账号等等。
步骤S304：第一服务器在本地日志记录得到的指定路由字段以及日志需要记录的其他字段，生成唯一跟踪号，并在本地日志记录该唯一跟踪号。
本发明实施例的服务请求的路由流程能为使用HTTP，且基于报文方式进行请求应答服务的系统带来方便，并且可以按报文数据内容对服务请求路由，不依赖特定软件系统，具有比TUXEDO等数据路由方案更通用、更广泛的适用范围。此外，本发明实施例可以自定义报文格式，可以同时设置多个数据元进行路由，并能使用表达式配置路由条件，路由规则十分灵活。通过解析报文数据获得请求中的字段要素，在本地记录服务请求痕迹，方便对服务请求进行跟踪和监控。
图4是根据本发明第四实施例的基于交易系统的路由示意图。
如图4所示，一个客户的交易经过多个应用系统：系统A、系统B、系统C、系统D，其中每个应用系统都可以使用本发明实施例的服务请求的路由方法对交易请求进行路由。
根据图4，客户端向系统A发送第一交易请求，在系统A中，确定由接收第二交易请求的服务器A1本地处理第一交易请求，无需路由，然后，服务器A1向系统B的服务器B1发送第二交易请求，在系统B中，接收第二交易请求的服务器B1将该交易请求路由到系统B的服务器B2进行处理，然后，服务器B2向系统C的服务器C3发送第三交易请求，确定由服务器C3本地处理第三交易请求，之后服务器C3向系统D的服务器D2发送第四交易请求，服务器D2处理第四交易请求，将相应的响应数据依次经服务器C3、服务器B2、服务器B1、服务器A1，最后返回给客户端。需要说明的是，上述的“第一交易请求”、“第二交易请求”、“第三交易请求”、“第四交易请求”指的是同一笔交易的交易请求，其中的“第一”、“第二”、“第三”、“第四”仅表示发出交易请求的设备不同(设备包括客户端以及不同服务器)。每个应用系统均可以包括多个节点，图4中的同一应用系统的各服务器位于不同的节点上，每个节点上仅以图中示出的服务器为例，该节点的其他服务器未示出。上述过程中，判断交易请求是否需要路由的方法具体可以参见第一实施例中的介绍。
每个应用系统都会记录该交易的日志。日志可以包括唯一跟踪号、交易代码、服务器编号、客户编号、日期和时间、处理是否成功等信息(具体各个应用系统还可以根据自身特点记录更多的信息，此处不分别一一列举)。每个应用系统的日志存在交易所经过的服务器上，监控系统可以从每台服务器(例如图4中的服务器A1、服务器B1、服务器B2、服务器C3、服务器D2)上采集这些日志并进行汇总。从而可以在监控系统上跟踪查找到每笔交易经过了哪些应用系统的哪些服务器，如果有交易请求处理失败也可以通过日志定位到在哪个服务器上的交易请求失败。
图4中，对于服务器A1而言，请求端为客户端，服务器A1接收到的第一交易请求中不包括本交易的唯一跟踪号，服务器A1需要自行生成一个唯一跟踪号，在服务器A1向服务器B1发送交易请求时，会将生成的该唯一跟踪号添加到第二交易请求的报文中，服务器B1可以通过解析第二交易请求的报文内容得到该唯一跟踪号，而无需再自行生成唯一跟踪号。同样地，服务器C3、服务器D2也可以从各自接收到的交易请求中解析得到该交易的唯一跟踪号。
对于银行系统等大型系统中，每个应用系统的服务器都负责处理很多交易，每笔交易通常经过多个应用系统。通过在本地日志记录交易请求的唯一跟踪号(或称交易的唯一跟踪号)，可以对交易请求进行跟踪和监控。根据本地日志记录的路由数据元和唯一跟踪号，可以跟踪交易状态和监控应用系统状态。
随着银行业务从传统的柜台转移到网站、手机、自助终端等多种电子渠道，给银行系统带来了巨大的交易量和海量的数据。此外银行业务也不断精细化、个性化，使得银行信息系统功能越来越复杂，系统处理压力增大。大型银行系统需要分布式部署，建设异地多中心进行灾备部署，不同中心之间处于独立状态，存储、数据库等都不共享，但是一些整合度高的银行业务依赖交易上下文，因此需要一种基于交易业务内容的跨中心路由的方法。传统的基于中间件TUXEDO需要按特定格式存储数据，路由规则和目标不支持动态更新。而本发明实施例支持使用HTTP协议，服务请求以报文方式发送，并可按自定义格式解析报文数据，根据数据内容对交易请求进行路由，路由规则、路由目标支持动态配置、动态生效，支持所有基于HTTP请求、响应类型的服务，不依赖特定中间件或容器。路由功能不依赖客户端，客户端不能且不需要关注请求是否经过路由。相对于现有的基于请求地址路由的路由方案，由于本发明实施例的服务端根据客户端请求的数据内容判断交易请求应该转发到哪个服务器处理，实现根据请求数据内容路由，从而克服了不适用于多个服务共用单一接入地址的系统的缺陷，并且路由中间系统(服务器)可以得到交易请求的路由数据元等字段信息，并记录在本地日志中，实现对交易请求的监控和跟踪。并且，本发明实施例的路由方案不依赖重定向技术，对于银行系统的简单轻量级HTTP客户端的服务请求也可以路由。
图5是根据本发明第五实施例的服务请求的路由装置的主要模块示意图。
本发明实施例的服务请求的路由装置500位于第一服务器上，如图5，服务请求的路由装置500主要包括：请求接收和解析模块501、目标节点确定模块502、服务地址选取模块503、服务请求路由模块504。
请求接收和解析模块501，用于第一服务器接收请求端以报文方式发来的服务请求，并对服务请求的报文内容进行解析，得到路由数据元。
服务请求的报文内容基于HTTP协议，其中携带请求地址。
请求接收和解析模块501包括报文内容解析单元，用于：按照配置的请求地址与报文格式之间的对应关系，查找与服务请求携带的请求地址所对应的目标报文格式；根据目标报文格式解析服务请求的报文内容，以得到多个数据元；将该多个数据元之中与配置的数据元一致的数据元作为路由数据元。
路由数据元的个数可以为一个或多个，通过对服务请求的报文内容解析，还可以得到路由数据元的值。
目标节点确定模块502，用于第一服务器根据路由数据元，确定可处理服务请求的目标节点，目标节点包括一组服务器。
目标节点确定模块502具体可以用于：第一服务器读取当前已加载的路由规则表，路由规则表中的每一路由规则记录节点和与节点对应的路由条件，且每一路由规则中的节点数和路由条件数均为一个或多个；第一服务器根据路由数据元的个数，从路由规则表中选出一个或多个路由规则，其中，选出的每一路由规则记录的路由条件数与路由数据元的个数相同；在选出的一个或多个路由规则中，按照预设规则查找出一个记录的路由条件与路由数据元的值匹配的路由规则，并将该查找出的路由规则记录的节点作为可处理服务请求的目标节点。
服务请求的路由装置500还可以包括路由规则表加载模块，用于第一服务器按照预设的时间间隔，定期从保存路由规则的数据库表中获取已启用的节点对应的路由规则，以组成路由规则表，并将路由规则表加载到内存，其中，数据库表中保存的路由规则可动态配置及更新。
服务地址选取模块503，用于在目标节点不包括第一服务器的情况下，第一服务器按照预设的选取规则在目标节点对应的服务地址列表中选取一个服务地址作为目标服务地址。
服务请求路由模块504，用于第一服务器将服务请求路由到目标服务地址对应的第二服务器。
服务请求路由模块504具体可以用于：第一服务器按照服务请求重新生成待路由服务请求，待路由服务请求中的参数与服务请求的参数相同；第一服务器将待路由服务请求路由到目标服务地址对应的第二服务器。
服务请求的路由装置500还可以包括日志记录模块，用于：第一服务器在本地日志记录路由数据元和唯一跟踪号，唯一跟踪号是由第一服务器生成的或者由第一服务器从报文内容中解析得到的，用于对服务请求进行跟踪和监控。日志记录模块还用于接收并在本地日志记录第二服务器返回的响应数据。
另外，在本发明实施例中服务请求的路由装置的具体实施内容，在上面所述服务请求的路由方法中已经详细说明了，故在此重复内容不再说明。
图6示出了可以应用本发明实施例的服务请求的路由方法或服务请求的路由装置的示例性系统架构600。
如图6所示，系统架构600可以包括终端设备601、602、603，网络604和服务器605。网络604用以在终端设备601、602、603和服务器605之间提供通信链路的介质。网络604可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备601、602、603通过网络604与服务器605交互，以接收或发送消息等。终端设备601、602、603上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
终端设备601、602、603可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器605可以是提供各种服务的服务器，例如对用户利用终端设备601、602、603所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的交易请求等数据进行分析等处理，并将处理结果(例如响应信息--仅为示例)反馈给终端设备。
需要说明的是，本发明实施例所提供的服务请求的路由方法一般由服务器605执行，相应地，服务请求的路由装置一般设置于服务器605中。
应该理解，图6中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
下面参考图7，其示出了适于用来实现本申请实施例的终端设备或服务器的计算机系统700的结构示意图。图7示出的终端设备或服务器仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图7所示，计算机系统700包括中央处理单元(CPU)701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM 703中，还存储有系统700操作所需的各种程序和数据。CPU 701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。
以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。
特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(CPU)701执行时，执行本申请的系统中限定的上述功能。
需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括请求接收和解析模块、目标节点确定模块、服务地址选取模块、服务请求路由模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，请求接收和解析模块还可以被描述为“用于第一服务器接收请求端以报文方式发来的服务请求，并对服务请求的报文内容进行解析的模块”。
作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：第一服务器接收请求端以报文方式发来的服务请求，并对所述服务请求的报文内容进行解析，得到路由数据元；所述第一服务器根据所述路由数据元，确定可处理所述服务请求的目标节点，所述目标节点包括一组服务器；在所述目标节点不包括所述第一服务器的情况下，所述第一服务器按照预设的选取规则在所述目标节点对应的服务地址列表中选取一个服务地址作为目标服务地址；所述第一服务器将所述服务请求路由到所述目标服务地址对应的第二服务器。
根据本发明实施例的技术方案，第一服务器接收请求端以报文方式发来的服务请求，并对服务请求的报文内容解析以得到路由数据元，根据路由数据元进行服务请求路由，能够根据数据内容对服务请求路由，不依赖特定软件系统(中间件)，可以自定义报文格式，通用性强、适用范围广。对服务请求路由所使用的路由规则表从数据库动态加载更新，而无需重启服务器，服务连续性和可维护性好。支持多个数据元组合，可适用于多个服务共用单一接入地址的系统，路由规则中的路由条件也可以为一个或多个，可支持表达式配置，路由规则十分灵活。通过本地日志可记录服务请求痕迹，方便对服务请求进行跟踪和监控。通过根据服务请求重新生成新的待路由服务请求，以将待路由服务请求路由到相应的服务器，无需对请求重定向，从而对于采用轻量级http客户端的应用系统也实现路由。
上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (12)

1.一种服务请求的路由方法，其特征在于，包括：
第一服务器接收请求端以报文方式发来的服务请求，并对所述服务请求的报文内容进行解析，得到路由数据元；所述服务请求的报文内容基于HTTP协议，其中携带请求地址，对所述服务请求的报文内容进行解析，得到路由数据元的步骤，包括：按照配置的请求地址与报文格式之间的对应关系，查找与所述服务请求携带的请求地址所对应的目标报文格式；根据所述目标报文格式解析所述服务请求的报文内容，以得到多个数据元；将所述多个数据元之中与配置的数据元一致的数据元作为所述路由数据元；
所述第一服务器根据所述路由数据元，确定可处理所述服务请求的目标节点，所述目标节点包括一组服务器；
在所述目标节点不包括所述第一服务器的情况下，所述第一服务器按照预设的选取规则在所述目标节点对应的服务地址列表中选取一个服务地址作为目标服务地址；
所述第一服务器将所述服务请求路由到所述目标服务地址对应的第二服务器。
2.根据权利要求1所述的方法，其特征在于，所述路由数据元的个数为一个或多个，且通过对所述服务请求的报文内容解析，还得到所述路由数据元的值；
所述第一服务器根据所述路由数据元，确定可处理所述服务请求的目标节点的步骤，包括：
所述第一服务器读取当前已加载的路由规则表，所述路由规则表中的每一路由规则记录节点和与所述节点对应的路由条件，且所述每一路由规则中的节点数和路由条件数均为一个或多个；
所述第一服务器根据所述路由数据元的个数，从所述路由规则表中选出一个或多个路由规则，其中，选出的每一路由规则记录的路由条件数与所述路由数据元的个数相同；
在选出的所述一个或多个路由规则中，按照预设规则查找出一个记录的路由条件与所述路由数据元的值匹配的路由规则，并将该查找出的路由规则记录的节点作为可处理所述服务请求的目标节点。
3.根据权利要求2所述的方法，其特征在于，所述第一服务器按照预设的时间间隔，定期从保存所述路由规则的数据库表中获取已启用的节点对应的路由规则，以组成所述路由规则表，并将所述路由规则表加载到内存，其中，所述数据库表中保存的所述路由规则可动态配置及更新。
4.根据权利要求1所述的方法，其特征在于，所述第一服务器将所述服务请求路由到所述目标服务地址对应的第二服务器的步骤，包括：
所述第一服务器按照所述服务请求重新生成待路由服务请求，所述待路由服务请求中的参数与所述服务请求的参数相同；
所述第一服务器将所述待路由服务请求路由到所述目标服务地址对应的第二服务器。
5.根据权利要求1所述的方法，其特征在于，还包括：所述第一服务器在本地日志记录所述路由数据元和唯一跟踪号，所述唯一跟踪号是由所述第一服务器生成的或者由所述第一服务器从所述报文内容中解析得到的，用于对所述服务请求进行跟踪和监控；
所述第一服务器将所述服务请求路由到所述目标服务地址对应的第二服务器的步骤之后，还包括：接收并在所述本地日志记录所述第二服务器返回的响应数据，然后将所述响应数据返回所述请求端。
6.一种服务请求的路由装置，其特征在于，包括：
请求接收和解析模块，用于第一服务器接收请求端以报文方式发来的服务请求，并对所述服务请求的报文内容进行解析，得到路由数据元；所述服务请求的报文内容基于HTTP协议，其中携带请求地址，所述请求接收和解析模块包括报文内容解析单元，用于：按照配置的请求地址与报文格式之间的对应关系，查找与所述服务请求携带的请求地址所对应的目标报文格式；根据所述目标报文格式解析所述服务请求的报文内容，以得到多个数据元；将所述多个数据元之中与配置的数据元一致的数据元作为所述路由数据元；
目标节点确定模块，用于所述第一服务器根据所述路由数据元，确定可处理所述服务请求的目标节点，所述目标节点包括一组服务器；
服务地址选取模块，用于在所述目标节点不包括所述第一服务器的情况下，所述第一服务器按照预设的选取规则在所述目标节点对应的服务地址列表中选取一个服务地址作为目标服务地址；
服务请求路由模块，用于所述第一服务器将所述服务请求路由到所述目标服务地址对应的第二服务器。
7.根据权利要求6所述的装置，其特征在于，所述路由数据元的个数为一个或多个，且通过对所述服务请求的报文内容解析，还得到所述路由数据元的值；
所述目标节点确定模块还用于：
所述第一服务器读取当前已加载的路由规则表，所述路由规则表中的每一路由规则记录节点和与所述节点对应的路由条件，且所述每一路由规则中的节点数和路由条件数均为一个或多个；
所述第一服务器根据所述路由数据元的个数，从所述路由规则表中选出一个或多个路由规则，其中，选出的每一路由规则记录的路由条件数与所述路由数据元的个数相同；
在选出的所述一个或多个路由规则中，按照预设规则查找出一个记录的路由条件与所述路由数据元的值匹配的路由规则，并将该查找出的路由规则记录的节点作为可处理所述服务请求的目标节点。
8.根据权利要求7所述的装置，其特征在于，还包括路由规则表加载模块，用于所述第一服务器按照预设的时间间隔，定期从保存所述路由规则的数据库表中获取已启用的节点对应的路由规则，以组成所述路由规则表，并将所述路由规则表加载到内存，其中，所述数据库表中保存的所述路由规则可动态配置及更新。
9.根据权利要求6所述的装置，其特征在于，所述服务请求路由模块还用于：
所述第一服务器按照所述服务请求重新生成待路由服务请求，所述待路由服务请求中的参数与所述服务请求的参数相同；
所述第一服务器将所述待路由服务请求路由到所述目标服务地址对应的第二服务器。
10.根据权利要求6所述的装置，其特征在于，还包括日志记录模块，用于：所述第一服务器在本地日志记录所述路由数据元和唯一跟踪号，所述唯一跟踪号是由所述第一服务器生成的或者由所述第一服务器从所述报文内容中解析得到的，用于对所述服务请求进行跟踪和监控；
所述日志记录模块还用于：接收并在所述本地日志记录所述第二服务器返回的响应数据。
11.一种电子设备，其特征在于，包括：
一个或多个处理器；
存储器，用于存储一个或多个程序，
当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-5中任一所述的方法。
12.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-5中任一所述的方法。
CN201910853260.6A 2019-09-10 2019-09-10 一种服务请求的路由方法和装置 Active CN110581890B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910853260.6A CN110581890B (zh) 2019-09-10 2019-09-10 一种服务请求的路由方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910853260.6A CN110581890B (zh) 2019-09-10 2019-09-10 一种服务请求的路由方法和装置

Publications (2)

Publication Number Publication Date
CN110581890A CN110581890A (zh) 2019-12-17
CN110581890B true CN110581890B (zh) 2022-02-22

Family

ID=68811591

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910853260.6A Active CN110581890B (zh) 2019-09-10 2019-09-10 一种服务请求的路由方法和装置

Country Status (1)

Country Link
CN (1) CN110581890B (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110913025B (zh) * 2019-12-31 2022-06-24 中国银联股份有限公司 服务调用方法、装置、设备及介质
CN111580797B (zh) * 2020-05-13 2021-04-27 上海创蓝文化传播有限公司 基于dubbo和spring框架的动态路由分组的方法
CN112134722A (zh) * 2020-08-18 2020-12-25 北京思特奇信息技术股份有限公司 一种动态路由的方法和系统
CN112199426B (zh) * 2020-09-24 2023-06-02 建信金融科技有限责任公司 微服务架构下的接口调用管理方法、装置、服务器及介质
CN114531492B (zh) * 2020-11-05 2024-05-10 网联清算有限公司 服务调用方法、装置、存储介质及计算机设备
CN113411234B (zh) * 2021-06-17 2022-08-16 杭州遥望网络科技有限公司 一种接口测试方法、系统及计算机可读存储介质
CN113360043B (zh) * 2021-06-29 2024-04-09 中国农业银行股份有限公司 业务处理方法及设备
CN113806129A (zh) * 2021-09-16 2021-12-17 北京沃东天骏信息技术有限公司 一种服务请求处理方法和装置
CN114885010B (zh) * 2022-06-06 2024-01-05 中国工商银行股份有限公司 请求响应方法、装置、设备、介质
CN116595285B (zh) * 2023-07-19 2024-04-16 深圳复临科技有限公司 一种路由生成方法、装置、计算机设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101102535A (zh) * 2007-08-02 2008-01-09 中国移动通信集团浙江有限公司 一种多媒体消息跟踪系统及其跟踪方法
CN102148752A (zh) * 2010-12-22 2011-08-10 华为技术有限公司 基于内容分发网络的路由实现方法及相关设备、系统
CN103581765A (zh) * 2012-08-02 2014-02-12 华为技术有限公司 一种报文转发的方法和设备
CN105743993A (zh) * 2016-03-31 2016-07-06 杭州数梦工场科技有限公司 报文处理方法和系统
CN108965203A (zh) * 2017-05-18 2018-12-07 腾讯科技（深圳）有限公司 一种资源访问方法及服务器
CN109067860A (zh) * 2018-07-20 2018-12-21 山东中创软件工程股份有限公司 一种移动端消息处理方法及相关装置
CN110120917A (zh) * 2019-06-28 2019-08-13 北京百度网讯科技有限公司 基于内容的路由方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9680865B2 (en) * 2014-10-10 2017-06-13 Secret Media Inc. Reliable user-device content and media delivery apparatuses, methods and systems

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101102535A (zh) * 2007-08-02 2008-01-09 中国移动通信集团浙江有限公司 一种多媒体消息跟踪系统及其跟踪方法
CN102148752A (zh) * 2010-12-22 2011-08-10 华为技术有限公司 基于内容分发网络的路由实现方法及相关设备、系统
CN103581765A (zh) * 2012-08-02 2014-02-12 华为技术有限公司 一种报文转发的方法和设备
CN105743993A (zh) * 2016-03-31 2016-07-06 杭州数梦工场科技有限公司 报文处理方法和系统
CN108965203A (zh) * 2017-05-18 2018-12-07 腾讯科技（深圳）有限公司 一种资源访问方法及服务器
CN109067860A (zh) * 2018-07-20 2018-12-21 山东中创软件工程股份有限公司 一种移动端消息处理方法及相关装置
CN110120917A (zh) * 2019-06-28 2019-08-13 北京百度网讯科技有限公司 基于内容的路由方法及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Do More Replicas of Object Data Improve the Performance of Cloud Data Centers;Zeng Zeng,Bharadwaj Veeravalli;《IEEE》;20121108;全文 *
信息与内容为中心的未来网络架构研究综述;王雪;《辽宁大学学报》;20161115;全文 *

Also Published As

Publication number Publication date
CN110581890A (zh) 2019-12-17

Similar Documents

Publication Publication Date Title
CN110581890B (zh) 一种服务请求的路由方法和装置
CN110120917B (zh) 基于内容的路由方法及装置
CN111917687B (zh) 一种循环推送提醒消息的方法和装置
CN108494860B (zh) Web访问系统、用于客户端的web访问方法和装置
US10630531B2 (en) Propagating state information to network nodes
CN110851468A (zh) 对客户端的测试请求做出模拟响应的方法和装置
CN110830374A (zh) 一种基于sdk的灰度发布的方法和装置
CN112835904A (zh) 一种数据处理方法和数据处理装置
CN110505074B (zh) 一种应用模块化集成方法和装置
CN113452600A (zh) 跨地域的消息通信方法、装置、电子设备和存储介质
CN114513552B (zh) 数据处理方法、装置、设备及存储介质
CN110798495B (zh) 用于在集群架构模式下端到端的消息推送的方法和服务器
CN110620722B (zh) 一种订单处理的方法和装置
CN113282589A (zh) 一种数据获取方法和装置
CN112804366B (zh) 用于解析域名的方法和装置
CN111858621B (zh) 监控业务流程的方法、装置、设备和计算机可读介质
CN114760360B (zh) 请求响应方法、装置、电子设备及计算机可读存储介质
CN108696549B (zh) 负载均衡方法、装置和系统
CN113760929A (zh) 数据同步方法、装置、电子设备和计算机可读介质
CN113127550A (zh) 信息处理方法、装置、电子设备及存储介质
CN113992664A (zh) 一种集群通信的方法、相关装置及存储介质
CN113762910A (zh) 一种单据监控方法和装置
CN115516842A (zh) 编排代理服务
CN117896380B (zh) 用于云考试的高并发信息处理方法、系统和装置
CN114844957B (zh) 链路报文转换方法、装置、设备、存储介质和程序产品

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20220923

Address after: 25 Financial Street, Xicheng District, Beijing 100033

Patentee after: CHINA CONSTRUCTION BANK Corp.

Address before: 25 Financial Street, Xicheng District, Beijing 100033

Patentee before: CHINA CONSTRUCTION BANK Corp.

Patentee before: Jianxin Financial Science and Technology Co.,Ltd.