一种低延时微服务路由管理系统的制作方法

文档序号:23505663发布日期:2021-01-01 18:15阅读:89来源:国知局
一种低延时微服务路由管理系统的制作方法
本发明涉及金融软件服务技术,具体涉及一种低延时微服务路由管理系统。
背景技术
:微服务是一种架构模式,提倡将应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供灵活的应用服务。在金融软件服务领域,可使用微服务架构将交易、结算、监察等金融业务进行整合,实现服务的灵活部署和接入。由于金融软件系统本身具备低延时、高可靠等特点,对于微服务路由管理方案有如下需求:(1)支持服务发现与服务路由功能:“服务发现”是指某个服务节点上线后,可以通过某种方式及时通知微服务集群内的其他节点,将本节点的服务地址和服务类型等消息告知其他节点。“服务路由”是指集群内的节点可以对服务数据进行自动转发,客户端节点可发起业务请求,请求数据将被路由至相应的微服务节点,服务节点完成业务请求处理后发送应答数据,通过集群路由至对应的客户端。(2)支持跨局域网部署:出于安全性的考虑,金融系统在实际进行部署时,通常会跨多个局域网,同一局域网内部的节点可以直接进行tcp或udp通讯,处于不同局域网的节点不能直接进行通讯,需通过特定的代理节点进行数据中转。微服务路由管理系统需支持跨局域网部署情况下的服务发现和服务路由功能。(3)容错机制:当集群中节点主动退出或节点意外断开后,集群内的其他节点可以自主调整路由表,不再对已退出节点进行消息路由。目前业界还没有一套针对微服务的路由管理系统来实现以上的需求。技术实现要素:以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览,并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。本发明的目的在于解决上述问题,提供了一种低延时微服务路由管理系统,降低了消息转发时延,支持跨局域网部署,满足容错要求。本发明的技术方案为:本发明揭示而来一种低延时微服务路由管理系统,系统用于对微服务集群上的节点进行路由管理,微服务集群的节点包括服务端、客户端和代理节点,微服务集群内的每个节点内都存储一张服务路由表,通过查询节点上的服务路由表实现包括将客户端节点发起的服务请求转发到对应的服务地址上在内的服务路由,系统包括服务发现功能模块、服务下线功能模块、服务请求及服务应答功能模块,其中:服务发现功能模块,配置为域内的节点通过域内各节点均拥有的相同的udp广播地址实时分享和更新路由表信息;服务下线功能模块,配置为在服务端不再对外提供某个服务时将服务信息从微服务集群中删除并更新各节点上的路由表信息;服务请求及服务应答功能模块,配置为以请求-应答方式实现微服务集群内的服务调用。根据本发明的低延时微服务路由管理系统的一实施例,服务路由表是微服务集群启动后由各个节点建立,节点也实时更新各自的服务路由表:同一域内的各节点通过多播通道收取服务路由信息,各局域网之间通过代理节点交换服务路由表的记录;服务路由表中的一条记录为(s,n,a,l),其中s为服务编号,n为节点编号,a为服务地址,l为路径长度,该条记录的含义是:由本节点到服务编号s的最短路径长度为l,这个最短路径上的下一个节点是n,对应的服务地址为a,请求数据将被转发至地址a,节点编号n指向了该路径的下一个节点,下一个节点包括代理节点或服务端节点,在服务路由表中,对于同一个服务编号s,服务路由表内只记录路径长度最短的路由。根据本发明的低延时微服务路由管理系统的一实施例,服务发现功能模块包括单域服务发现单元,单域服务发现单元配置为:服务端节点启动后在广播udp地址上,按照配置的频率定时进行服务信息广播,每次进行服务信息广播时均针对服务端提供的每一个服务对外发送一条服务路由表记录(s,n,a,l),其中s为服务编号,n为服务端节点编号,a为该服务的服务地址,l为0;与服务端节点同一域内的代理节点和客户端节点收到服务端广播的路由表记录(s,n,a,l)后,作如下处理:(1)查找本节点的路由表,是否有服务编号s的记录,如果没有匹配记录,则向本节点路由表插入一条(s,n,a,l+1)的记录;(2)如果本节点的路由表已有原始记录,取出原始记录(s,n′,a′,l′)。如果l+1>=l′,则无需更新路由表;如果l+1<l′,则将原始记录更新为(s,n,a,l+1)。根据本发明的低延时微服务路由管理系统的一实施例,服务发现功能模块包括跨域服务发现单元,跨域服务发现单元配置为:一域的本域代理节点与其他域的跨域代理节点建立tcp连接;本域代理节点实时收取udp广播通道上的消息,更新自身的路由表,当自身的路由表产生更新时,本域代理节点向所有已连接的跨域代理节点发送一条路由更新消息;其他域的本域代理节点实时接收跨域代理节点发送的路由更新消息,更新自身的路由表(s,n,a,l),其中s为服务编号,n为服务端节点编号,a为该服务的服务地址,l表示路径长度,更新过程包括:(a)查找本节点的路由表,是否有服务编号s的记录,如果没有匹配记录,则向本节点路由表插入一条(s,n,a,l+1)的记录;(b)如果本节点路由表已有服务编号s的原始记录,取出原始记录(s,n′,a′,l′),如果l+1>=l′,则无需更新路由表;如果l+1<l′,则将原始记录更新为(s,n,a,l+1);(c)如果路由表记录更新为了(s,n,a,l+1),则本域代理节点定时向本域内的udp广播通道发送一条(s,n_proxy,a_proxy,l+1)的路由消息,其中n_proxy和a_proxy分别为本域代理节点的节点编号和服务地址。根据本发明的低延时微服务路由管理系统的一实施例,服务下线功能模块对服务端主动发出服务下线通知的处理配置如下:当服务端不再提供某个服务时,通过udp广播通道发送服务下线通知,服务下线通知内包含一条与该服务相关的路由信息(s,n,a,l),其中,s和a为要下线服务的服务编号和服务地址,n为服务端的节点编号,l表示路径长度;对于同域内的情况,同域内的客户端和代理节点收到服务下线消息后,查找本节点的路由表内是否存在(s,n,a,l+1)的记录,如存在则将其从路由表内删掉;对于跨域部署的情况,代理节点从相连接的跨域代理节点接收并处理服务下线消息,如果代理节点成功处理了服务下线消息并删除了一条对应记录(s,n,a,l),则该代理节点同时向本域udp广播通道、和其他相连的跨域代理节点发送一条服务下线通知(s,n_proxy,a_proxy,l),其中,n_proxy和a_proxy为该代理节点的节点编号和服务地址。根据本发明的低延时微服务路由管理系统的一实施例,服务下线功能模块对服务端意外退出的处理配置如下:服务端节点意外退出导致无法主动对外发送服务下线通知,当服务端意外退出时,服务端与客户端和代理节点建立的tcp连接自动断开;客户端如果检测到与服务端节点或代理节点的连接断开,则从路由表中删除包含这个服务端节点的路由记录;代理节点如果检测到与服务端或代理节点的连接断开,则从路由表中删除包含这个服务端节点的路由记录,针对每一条删除的记录,向相连接的跨域代理节点发送服务下线通知。根据本发明的低延时微服务路由管理系统的一实施例,服务请求及服务应答功能模块对服务调用方式的处理进一步配置如下:由客户端节点发起服务请求,根据各节点上的路由表信息,请求数据最终被转发至对应的服务端节点上;服务端节点处理服务请求,将服务请求所产生的应答数据发回至客户端节点,在进行服务请求转发时,服务请求所经过的路径上的各个节点都记录请求数据的来源地址,转发应答数据时根据请求数据的路由路径原路返回。本发明对比现有技术有如下的有益效果:本发明的系统是采用分布式路由管理,无集中式路由节点,而是由集群内的各个节点保存服务路由信息,对于请求和应答数据可以直接查询内存中的路由表选取转发路径,降低了消息转发时延。可以支持跨局域网部署,在同一个局域网内,使用udp广播通道交换路由信息,跨局域网情况下通过部署代理节点通过tcp网络协议实现跨域数据交换。此外,集群内的节点退出后,其他节点可自行调整路由表,满足容错需求。具体而言,本发明的系统的创新点包括:1.本发明支持微服务集群内的服务发现、服务下线、服务路由等功能。服务路由表采用分布式管理,集群内每个节点都保存了一张路由表,各节点的路由表会随着集群内的服务和节点变更做自动调整,无需人为干预。由于每个节点都独立维护路由表,在进行请求数据路由时,各节点可直接查询存储在内存中的路由表数据,以降低整体路由时延。2.本发明支持单局域网、多局域网灵活部署。同一域内的各个节点通过udp广播通道交换路由表记录,路由信息扩散速度快、延时低。当存在多个局域网时,通过部署代理节点可实现多局域网的级联,代理节点之间通过tcp网络互相交换路由信息并通过udp广播通知本域内的各节点,集群内的每个节点都能获得整个集群的路由信息。3.本发明采用分布式路由管理,不存在单点故障风险。当服务端或代理节点意外退出后,预期相连的各个节点检测到连接断开后都能自动进行服务下线处理,并通过本域udp或代理节点通知到集群内的其他节点,因此整个集群可以自动完成节点故障下的路由调整,具有较强的容错性。附图说明在结合以下附图阅读本公开的实施例的详细描述之后,能够更好地理解本发明的上述特征和优点。在附图中,各组件不一定是按比例绘制,并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。图1示出了本发明的低延时微服务路由管理系统的一实施例的原理图。图2示出了本发明的代理节点的示意图。图3示出了图1的低延时微服务路由管理系统实施例中的服务发现功能模块中针对单域服务发现情况处理的示意图。图4和图5示出了图1的低延时微服务路由管理系统实施例中的服务发现功能模块中针对跨域服务发现情况处理的示意图。图6示出了图1的低延时微服务路由管理系统实施例中的服务下线功能模块的处理示意图。图7a和7b示出了图1的低延时微服务路由管理系统实施例中的服务请求及服务应答功能模块的处理示意图。具体实施方式以下结合附图和具体实施例对本发明作详细描述。注意,以下结合附图和具体实施例描述的诸方面仅是示例性的,而不应被理解为对本发明的保护范围进行任何限制。图1示出了本发明的低延时微服务路由管理系统的一实施例的原理。请参见图1,本实施例的系统包括:服务发现功能模块、服务下线功能模块、服务请求及服务应答功能模块。系统用于对微服务集群上的节点进行路由管理。微服务集群是由多个节点(node)组成的网络,每个节点就是一个linux应用进程。微服务集群内的每个节点都有一个全局唯一的编号,称为节点编号(node_id)。在节点启动后,节点编号由系统自动生成。节点编号采用4字节整数存储,编号生成算法如下:步骤1:获取节点进程的系统进程号,存储在长度为1字节的整形变量proc_id中;步骤2:获取当前机器的系统启动时间,存储在长度为两个字节的整形变量local_timestamp中;步骤3:生成一个1字节的随机数,存储在变量rand_id中;步骤4:生成4字节节点编号:node_id=(proc_id<<24)|(local_timestamp<<8)|rand_id。其中,“<<”为“左位移”运算,“|”为“按位或”运算。节点按照功能分为服务端(server)、客户端(client)、代理节点(proxy)三种类型。微服务集群内的服务端节点可以对外提供多种“微服务”,也称“服务”,这里的微服务即对应某一具体的业务功能。每一类服务具有唯一的服务编号,服务编号以字符串形式存储,由使用者分配。此外,服务端对外提供服务时,会为每个服务分配一个服务地址,该地址是一个tcp网络地址,其他节点可连接到该地址来访问对应的服务。微服务集群在实际部署时,可能跨多个局域网,本发明将局域网的概念抽象称为“域”。微服务集群可以由多个域构成,每个域内可以包含多个节点。处于同一个域内的各个节点可以直接进行tcp或udp通讯。每个域内需配置一个udp广播通道,域内的各节点通过该通道交换服务路由所需的数据。不同域之间存在网络隔离,除代理节点外,不同域之间的节点不能直接进行tcp或udp通讯,而两个域之间可以通过代理节点实现tcp通讯。如果客户端节点需要请求其他域内提供的服务,请求数据必须经过两个域内的代理节点进行转发。微服务集群内的每个节点内都存储一张服务路由表,通过查询节点上的服务路由表实现包括将客户端节点发起的服务请求转发到对应的服务地址上在内的服务路由。以下就上述提到的微服务集群中的三种类型的进程节点(服务端、客户端和代理节点)进行说明。服务端即微服务提供方。一个服务端监听一个服务地址,服务端可通过该服务地址对外提供多个服务,每一类服务具有独立的服务编号和服务地址。服务端定时向域内广播通道发送服务编号和服务地址等信息,其他节点通过该信息构建路由表。服务端可接受客户端或代理节点发起的tcp连接,并接收客户端或代理节点发来的服务请求,之后调用相应的服务进行处理,并返回应答数据。客户端即微服务请求方。客户端实时监听域内广播通道上的消息并更新路由表,可对路由表内登记的服务发起服务请求。代理节点的作用是:当微服务集群中有多个互相隔离的域时,多个局域网可通过代理节点进行消息转发。代理节点启动后可通过服务发现功能模块自动发现同一域内的服务端和代理节点并与之建立tcp连接,此外可通过读取配置文件发现其他域内的代理节点并与之建立tcp连接,从而获得其他域内的服务信息。当整个微服务集群内只有一个域时,可以不加入代理节点。如图2所示,域a(domaina)和域b(domainb)是两个不同的域,根据手工配置,domaina中的代理节点proxy1和domainb中的代理节点proxy2可以建立tcp连接,domaina中的其他节点(服务端server1、客户端client1)不能直接与domainb中的任何节点进行直接通讯,只能经由proxy1节点进行数据转发。对于domaina来说,本实施例中将proxy1称为“本域代理节点”,将proxy2称为“跨域代理节点”。微服务集群内的客户端节点可以发起服务请求,该服务请求最终将被转发至对应的服务地址上,由服务端节点来进行业务处理,转发请求数据的过程称为服务路由。微服务集群内的每个节点内都存储了一张映射表,来记录服务编号与服务地址的映射关系,称为服务路由表,服务路由是通过查询节点上的服务路由表实现的。服务路由表用于将客户端节点发起的服务请求转发到对应的服务地址上。服务路由表的管理是微服务路由管理系统的核心,服务路由表是各节点进行请求数据和应答数据路由的重要依据。微服务集群启动后各个节点都会建立一张服务路由表,节点也会实时更新各自的服务路由表:同一域内的各节点通过多播通道收取服务路由信息,各局域网之间通过代理节点交换服务路由表的记录。当节点收到请求或应答数据时,将根据数据的最终目标地址查询服务路由表,确定下一个目标节点。服务路由表中的一条记录包含四个字段:(服务编号s,节点编号n,服务地址a,路径长度l),该条记录的含义是:由本节点到服务编号s的最短路径长度为l,这个最短路径上的下一个节点是n,对应的服务地址为a,请求数据将被转发至地址a。节点编号n指向了该路径的下一个节点,可能是代理节点,也可能是服务端节点。在服务路由表中,对于同一个服务编号s,路由表内只记录路径长度最短的路由。以下分别就各个功能模块进行说明。服务发现功能模块配置为域内的节点通过域内各节点均拥有的相同的udp广播地址实时分享和更新路由表信息。在微服务集群内,同一域内的各节点拥有相同的广播udp地址配置,域内的节点通过这个广播地址实时分享路由表信息,这一过程称为服务发现。服务发现功能模块又配置有单域服务发现单元和跨域服务发现单元。单域服务发现单元实施如下的配置过程。如果集群内只存在一个域,则通过该域内的udp广播通道完成服务发现。服务端节点启动后,在广播udp地址上,按照配置的频率定时进行服务信息广播。每次进行服务信息广播时,针对服务端提供的每一个服务,都对外发送一条服务路由表记录(s,n,a,l),其中:s为服务编号,n为服务端节点编号,a为该服务的服务地址,l为0。当服务端有新的微服务上线时,可通过定时广播机制将这一信息通知给其他节点。与服务端节点同一域内的代理节点和客户端节点收到服务端广播的路由表记录(s,n,a,l)后,将作如下处理:(1)查找本节点的路由表,是否有服务编号s的记录。如果没有匹配记录,则向本节点路由表插入一条(s,n,a,l+1)的记录(2)如果本节点路由表已有原始记录,取出原始记录(s,n′,a′,l′)。如果l+1>=l′,那么说明新收到的路由记录不构成最短路径,无需更新路由表;l+1<l′,则将原始记录更新为(s,n,a,l+1)代理节点和客户端节点启动后,实时侦听广播udp地址上的路由消息,并根据上述规则更新路由表。如图3所示,集群中只有一个域domaina。域内有两个服务端节点,其中服务端server1(节点编号为1001)提供服务编号为servicea、serviceb的两个服务,服务地址分别为addra和addrb;server2(节点编号为1002)提供一个服务servicec,服务地址为addrc。根据上述规则,服务端server1启动后,将定时向udp广播通道内广播两个服务路由记录,分别为(servicea,1001,addra,0)和(serviceb,1001,addrb,0);服务端server2启动后,将定时向udp通道内广播一条服务路由记录:(servicec,1002,addrc,0)。集群内包含一个代理节点proxy1和一个客户端节点client1,当两个服务端节点都启动后,根据两个服务端节点的广播消息,代理节点和客户端节点都将构建出如下的服务路由表:服务编号s目标节点n目标地址a最短路径长度lservicea1001addra1serviceb1001addrb1servicec1002addrc1根据如上的路由表,若客户端client1需要请求服务编号为serviceb的服务,则查表得到访问该服务的最短路径上的下一个节点是1001节点,需将数据转发至addrb服务地址上。跨域服务发现单元实施如下的配置过程。如果微服务集群内存在多个不同的域,不能直接进行跨域服务访问,需要通过配置代理节点进行中转。在这种场景下,每个域内至少应包含一个代理节点,需要对代理节点之间的连接进行手动配置。代理节点启动后,将根据配置信息,主动与跨域代理节点建立tcp连接,后续的路由记录交换都通过该tcp连接进行。此外,每个代理节点都有一个服务地址,用于进行业务数据转发。代理节点启动后,将进行如下操作:(1)根据配置文件,代理节点将以tcp方式连接跨域代理节点。(2)代理节点实时收取udp广播通道上的消息,更新自身的路由表。当自身的路由表产生更新时,代理节点将向所有已连接的跨域代理节点发送一条路由更新消息。假设代理节点内的路由更新消息为(s,n,a,l),那么向跨域代理节点发送的路由记录为(s,n_proxy,a_proxy,l),其中n_proxy和a_proxy分别为本节点的节点编号和服务地址。如果代理节点连接到了新的跨域代理节点,需要将本节点上的所有路由信息通过上述方式发送给新连接的代理节点。(3)实时接收跨域代理节点发送的路由更新消息,更新路由表。假设当前代理节点从跨域代理节点收到一条(s,n,a,l)的路由记录(其中,n和a为跨域代理节点的节点编号和服务地址),将进行如下检查:(a)查找本节点的路由表,是否有服务编号s的记录。如果没有匹配记录,则向本节点路由表插入一条(s,n,a,l+1)的记录;(b)如果本节点路由表已有记录,取出原始记录(s,n′,a′,l′)。如果l+1>=l′,那么说明新收到的路由记录不构成最短路径,无需更新路由表;l+1<l′,则将原始记录更新为(s,n,a,l+1);(c)如果路由表记录更新为了(s,n,a,l+1),则当前节点将定时向本域内的广播通道发送一条(s,n_proxy,a_proxy,l+1)的路由消息,其中n_proxy和a_proxy分别为这个代理节点的节点编号和服务地址。此外,在路由表更新时,也需要将这个消息通知给其他已连接的跨域代理节点。通过如上机制,可实现不同域之间的路由信息交换。当某个域内提供的服务信息发生变更时,集群内的所有节点都会调整各自的路由表。如图4所示,集群内存在两个域domaina和domainb,根据配置信息,代理节点proxy1(服务地址为addr_p1)和proxy2(服务地址为addr_p2)将建立起tcp连接,用于交换路由表数据。根据上述服务发现机制,最终:代理节点proxy1上的路由表如下:服务编号s目标节点n目标地址a最短路径长度lservicea1001addra1serviceb1001addrb1servicec1002addrc1serviced2002addr_p22代理节点proxy2上的路由表如下:服务编号s目标节点n目标地址a最短路径长度lservicea2001addr_p12serviceb2001addr_p12servicec2001addr_p12serviced1003addrd1客户端节点client1上的路由表如下:服务编号s目标节点n目标地址a最短路径长度lservicea1001addra1serviceb1001addrb1servicec1002addrc1serviced2001addr_p13客户端节点client2上的路由表如下:服务编号s目标节点n目标地址a最短路径长度lservicea2002addr_p23serviceb2002addr_p23servicec2002addr_p23serviced1003addrd1假设客户端节点client1将请求服务编号为serviced的服务,查询本节点的路由表,得知最短路径上的下一个节点为代理节点proxy1,客户端节点client1将该数据转发至代理节点proxy1的服务地址addr_p1上。代理节点proxy1收到该数据后,根据服务号进行查表,得知下一个节点为代理节点proxy2,将该数据转发到对应的服务地址addr_p2上。代理节点proxy2收到请求数据后,查表得知下一个节点为服务端节点server3,转发至相应的服务地址,由服务端处理请求数据。请求数据的路由转发链路如图5箭头所示。服务下线功能模块配置为在服务端不再对外提供某个服务时将服务信息从微服务集群中删除并更新各节点上的路由表信息。当服务端不再对外提供某个服务时,需要将服务信息从集群中删除,称为服务下线。服务下线有如下两种情况:(1)服务端主动发出服务下线通知当服务端不再提供某个服务时,将通过广播通道发送服务下线通知,服务下线通知内包含一条与该服务相关的路由信息(s,n,a,l),其中,s和a为要下线服务的服务编号和服务地址,n为服务端的节点编号,l固定为0。同域内的客户端和代理节点收到服务下线消息后,查找本节点的路由表内是否存在(s,n,a,l+1)的记录,如存在则将其从路由表内删掉。对于跨域部署的情况,代理节点也会从相连的跨域代理节点接收并处理服务下线消息。如果代理节点成功处理了服务下线消息并删除了一条对应记录(s,n,a,l),则该代理节点需要同时向本域udp广播通道、和其他相连的跨域代理节点发送一条服务下线通知(s,n_proxy,a_proxy,l),其中,n_proxy和a_proxy为该代理节点的节点编号和服务地址。如图6所示,如果集群内的服务端节点server1需要将serviceb服务下线,则该节点需要在udp通道内广播一条下线通知(serviceb,1001,addrb,0)。该域内的客户端节点client1收到下线通知后,删除相关记录,其路由表更新为:该域内的代理节点proxy1收到下线通知后,删除相关记录,其路由表更新为:同时,代理节点proxy1将向相连的跨域代理节点proxy2发出一条下线通知消息(serviceb,2001,addr_p1,1),proxy2收到这条消息后,路由表更新如下:最后,代理节点proxy2将在域domainb内的广播通道上发送一条服务下线消息(serviceb,2002,addr_p2,2),客户端节点client2收到该消息后,路由表更新如下:(2)服务端意外退出如果服务端节点发生故障导致意外退出,则无法主动对外发送服务下线通知。当服务端退出时,它与客户端和代理节点建立的tcp连接也将自动断开。客户端如果检测到与服务端节点或代理节点的连接断开,则从路由表中删除包含这个服务端节点的路由记录。代理节点如果检测到与服务端或代理节点的连接断开,则从路由表中删除包含这个服务端节点的路由记录,针对每一条删除的记录,向相连的跨域代理节点发送服务下线通知。微服务集群内的服务调用方式为“请求-应答”方式,由客户端节点发起服务请求,根据各节点上的路由表信息,请求数据最终被转发至对应的服务端节点上。服务端节点调用相应的服务处理函数来处理请求,将产生的应答数据发回至客户端节点。在进行请求转发时,请求所经过的路径上的各个节点都会记录请求数据的来源地址,转发应答数据时根据请求数据的路由路径原路返回。如图6所示,应答将按照请求的路径原路返回。服务请求及服务应答模块配置为以请求-应答方式实现微服务集群内的服务调用。微服务集群内的服务调用方式为“请求-应答”方式,由客户端节点发起服务请求,根据各节点上的路由表信息,请求数据最终被转发至对应的服务端节点上。服务端节点调用相应的服务处理函数来处理请求,将产生的应答数据发回至客户端节点。在进行请求转发时,请求所经过的路径上的各个节点都会记录请求数据的来源地址,转发应答数据时根据请求数据的路由路径原路返回。如图7a和7b所示,应答将按照请求的路径原路返回。尽管为使解释简单化将上述方法图示并描述为一系列动作,但是应理解并领会,这些方法不受动作的次序所限,因为根据一个或多个实施例,一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。本领域技术人员将进一步领会,结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性,各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性,但这样的实现决策不应被解读成导致脱离了本发明的范围。结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器,但在替换方案中,该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合,例如dsp与微处理器的组合、多个微处理器、与dsp核心协作的一个或多个微处理器、或任何其他此类配置。结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动盘、cd-rom、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中,存储介质可以被整合到处理器。处理器和存储介质可驻留在asic中。asic可驻留在用户终端中。在替换方案中,处理器和存储介质可作为分立组件驻留在用户终端中。在一个或多个示例性实施例中,所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品,则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者,其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定,这样的计算机可读介质可包括ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如,如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(dsl)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来,则该同轴电缆、光纤电缆、双绞线、dsl、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(cd)、激光碟、光碟、数字多用碟(dvd)、软盘和蓝光碟,其中盘(disk)往往以磁的方式再现数据,而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的,且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此,本公开并非旨在被限定于本文中所描述的示例和设计,而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1