具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
LDC:全称是Logical Data Center(逻辑数据中心),是对IDC(Internet DataCenter,互联网数据中心)的一种逻辑划分。LDC是支付宝系统实践“单元化部署”所采用的方案。
zone: 是指一个能完成所有业务操作的自包含集合,在这个集合中包含了所有业务所需的所有服务,以及分配给这个单元的数据。
本发明实施例提供了一种实现服务器集合均衡调配的方法,用以解决现有技术的高并发请求下单库的TPS/QPS不能满足业务的需要的技术问题。
在具体的实施过程中,本实施例的方法主要用于一种实现服务器集合均衡调配的系统中,下面请参看图1A,是该系统具体的架构示意图。
在该系统包含有设置在各个城市的服务器集合。以两个不同的城市(分别命名为为第一城市和第二城市)设置的服务器集合为例,其他城市的的设置类似。
第一城市中设置有第一服务器集合101和第二服务器集合102。其中,第一服务器集合101和第二服务器集合102是处于第一城市中的不同区域的服务器集合。值得注意的是,本实施例的第一城市中的第一服务器集合101和第二服务器集合102主要是为了表示处于第一城市中不同区域的服务器集合,并不代表只有第一城市只有两个服务器集合。下面以第一服务器集合101的结构为例,第二服务器集合102的设置类似,故而不再赘述。
而第一服务器集合101中又包含有第一服务器子集合1011和第二服务器子集合1012,其中,第一服务器子集合1011中包含有一个或者多个服务器,第二服务器子集合1012也包含有一个或者多个服务器。第一服务器子集合1011和第二服务器子集合1012中的服务器的数目可以相同也可以不相同。
第二服务器子集合1012和第一服务器子集合1011设置的结构类似,故而不再赘述。
第二城市中设置有第三服务器集合103和第四服务器集合104。其中,第三服务器集合103和第四服务器集合104是处于第二城市中的不同区域的服务器集合。值得注意的是,本实施例的第二城市中的第三服务器集合103和第四服务器集合104主要是为了表示处于第二城市中不同区域的服务器集合,并不代表只有第二城市只有两个服务器集合。例如请参看图5,假设第二城市为深圳,那么第三服务器集合103可能是服务器集合RZ11、服务器集合gtj、服务器集合Su18中的一个。第四服务器集合104可能是服务器集合RZ11、服务器集合gtj、服务器集合Su18中的一个,只要是第三服务器集合103和第四服务器集合104不同即可。下面以第三服务器集合103的结构为例,第四服务器集合104的设置类似,故而不再赘述。
第三服务器集合103中包含有第三服务器子集合1031和第四服务器子集合1032。其中,第三服务器子集合1031中包含有一个或者多个服务器,第四服务器子集合1032也包含有一个或者多个服务器。第三服务器子集合1031和第四服务器子集合1032中的服务器的数目可以相同也可以不相同。
第四服务器子集合1032和第三服务器子集合1031设置的结构类似,故而不再赘述。
在上述实施例的这些服务器中,每个服务器都有各自的编号。
例如,参看图1A,第一服务器子集合1011中设置有10个服务器,编号分别为01-10依次编号。第二服务器子集合1012中设置有9个服务器,编号分别为11-19依次编号。
进一步的,本实施例中的各服务器的编号并不是随意编号的,本实施例中的各服务器的编号是基于数据库拆分获得的子数据库的编号来确定的。服务器中存储的由数据库拆分获得的子数据库的编号是多少,那么该台服务器的编号便是多少,进而能够便于快速的响应数据。
每个服务器包含有一个子数据库。数据库可以拆分成一个或者多个子数据库,然后所述子数据库是由一个数据库拆分获得。也就是说,一个数据库可以拆分成多个子数据库,然后分配给各服务器使用。
所有服务器包含的子数据库可以合并成一个数据库。
下面先介绍数据库的拆分。
本实施例将数据库进行了拆分,例如将数据库拆分成100个子数据库,每个子数据库存储在一个服务器中。当然,在将子数据库拆分成100个的过程中,可以平均拆分成100个,这100个子数据库的数据存储量相等。也可以根据服务器的性能或者随机等等规则不平均拆分成100个子数据库,那么这100个子数据库的数据存储量有可能相同有可能不同。然后将业务数据分配到各子数据库中进行响应,能够极大的缓解单个数据库在数据访问量太大时造成的性能瓶颈,提供高并发请求的响应效率。
进一步的,本实施例为了识别各子数据库,还将拆分获得的子数据库按照拆分的数目按照顺序进行了编号,例如拆分了100个子数据库,则将这100个子数据库从00-100进行了编号。例如,finlinkdata数据库,将该finlinkdata数据库拆分成子数据库,则会按照拆分个数进行编号并排序,如图2所示,示出了部分子数据库的编号。
而在本实施例中,则在各地设置有服务器存储各子数据库,故而每台服务器的编号实际上就和存储的各子数据库的编号相同。
进一步的,在对数据库进行拆分的过程中,还会生成一拆分数据表,用于记录各个子数据库的基本拆分信息,例如编号、数据存储量、对应的用户ID编号等等。
每个服务器的子数据库中都存储有该拆分数据表,并且每个服务器上的子数据库存储的拆分数据表的内容都相同。各子数据库中的编号和其存储的拆分数据表的编号一样。例如finlinkdata_01子数据库中的拆分数据表的编号也为01。当然,各子数据库上除了存储有该拆分数据表之外,各子数据库中还存储有其他数据表,例如,订单表,人员表,交易表等等,各子数据库中存储的数据表的个数是不定的,但是每个子数据库中的数据表的个数、结构都是一模一样的。例如,各子数据都存储有订单表,但是每个子数据库的订单表的编号是不同的,例如 order_00,......,order_100,而不同用户的订单就分配到不同的订单表中。
参看图3,是将finlinkdata数据库拆分成子数据库之后,编号为01的子数据库中finlinkdata_01存储的数据表的示意图。finlinkdata_01这个子数据库中包含了很多数据表,这些数据表是带有后缀的,说明也是拆分过的。
以上实施例则是数据库的拆分过程。
而在对服务器进行编号的过程中,则首先获得各服务器各自存储的子数据库的编号,然后将各服务器各自存储的子数据库的编号对应作为各服务器的编号。因此可以看出,本实施例的服务器的数量是和数据库拆分成的子数据库的数量对应设置的。
进一步的,每个服务器上都设置有机构鉴权服务平台finauth应用,机构鉴权服务平台,包括面向机构的签约,面向客户类鉴权,核审及签约请求中与机构能力相关的流程服务编排,包括:机构四要素鉴权,机构三要素鉴权,机构多证件校验能力,机构短信校验,机构免签等能力编排撮合。finauth这个应用在所有服务器上的部署的功能是对等的,就是同一份代码部署在了不同的服务器中,以服务不同的用户ID。
以上便是本实施例中的系统运行的基础,将各城市的各个服务器对应分配有由数据库进行拆分之后得到的子数据库,并且各服务器按照分配到的子数据库的编号进行编号。所述子数据库是由一总数据库拆分获得,并且各个服务器对应分配的子数据库合并在一起,则可以变成该总数据库。
在下面的实施例中,参看图1A,是本发明实施例中的实现服务器集合均衡调配的方法的流程图,具体的实施步骤如下所示:
步骤11,实时监测各服务器集合的运行状态。
作为一种可选的实施例,在实时监测各服务器集合的运行状态之前,会基于各流量用户的用户身份识别号ID,将所述各流量用户调配到各服务器集合中。其中,用户ID预设位数的编号、各服务器集合中的服务器的编号、各服务器中存储的子数据库的编号、子数据库中的拆分数据表的编号等等一一对应,进而能够将流量用户按照用户ID对应分配到各服务器集合中的服务器中,进而使得各服务器能够及时快速的响应对应的流量用户的用户请求。
在具体的实施过程中,每个流量用户都具有各自的用户ID,用户ID可用于表征对应流量用户的身份,每个流量用户的用户ID是唯一的。故而为了分配流量用户到不同的子数据库,本实施例还设置了一套分配规则,以分配流量用户到对应的子数据库中。该分配规则在路由器、各服务器的子数据库、各服务器中的finauth应用上都是一样的,会减少跨城的流量损失。
该分配规则是:将流量用户分配到编号和流量用户ID的预设位数的号码值相同的子数据库进行响应,或者将流量用户分配到编号和流量用户ID的预设位数的号码值相同的服务器进行响应。也就是说,流量用户ID的预设位数的号码值和子数据库(服务器)的编号一致,才能够将该流量用户分配到该子数据库(服务器)中。以用户ID的倒数两位数为例,例如用户ID为2000000099,那么则会进入99编号的子数据库(服务器)中进行响应。
本实施例将流量用户的用户ID和数据库的编号相对应,将流量用户分配到编号和流量用户ID的预设位数的号码值相同的子数据库(服务器)中,故而能够明确的划分流量用户到对应的子数据库中,这样的设置,不但能够避免高并发请求时的数据库的崩溃,还能够及时快速的响应用户的需求。另外,还模糊了城市与城市之间的数据传输障碍,减少跨城的流量损失。
而在具体的分配过程中:首先,确定出各流量用户的用户身份识别号ID中的预设位数的号码值。例如确定出流量用户的用户ID的倒数两位的号码值,当然预设位数是根据实际情况而定的,可以设置为倒数三位、中间四位等等,例如若60亿流量用户,就可以使用一万个数据库一万个数据表,采用用户ID的倒数4位来做分配规则。
本实施例在此不做限制。然后按照所述各流量用户的用户身份识别号ID中的预设位数的号码值,确定出对应编号的服务器,并将各流量用户调配到对应编号的服务器中。例如以用户ID的倒数两位数为例,例如用户ID为2000000099,那么则会确定出其对应的是99编号的子数据库(服务器),故而该流量用户则会进入编号为99的子数据库(服务器)进行响应。
由上述实施例可知,用户ID、子数据库、拆分数据库、服务器的编号是一致的。故而能够将流量用户调配到对应编号的服务器中进行响应。
进一步的,在按照所述各流量用户的用户身份识别号ID中的预设位数的号码值,确定出对应编号的服务器的过程中,是按照所述各流量用户的用户身份识别号ID中的预设位数的号码值在拆分数据表中确定出对应编号的服务器。
将所述各流量用户划分到对应的预设号段中;最后将各预设号段对应调配到各服务器子集合中。举例来说,按照用户ID进行一百库一百表的拆分。100库100表的含义是,将一个总的数据库分成100个子数据库,各数据库具有编号。并且对应生成100个拆分数据表,每个拆分数据表的内容是一样的,将每个拆分数据表都对应置入这100个子数据库中,使得每个子数据库都具有一个拆分数据表,然后将这100个数据库对应设置到各服务器中。拆分数据表、子数据库、各服务器集合中的服务器是一一对应的。
利用流量用户的用户ID的倒数两位的号码值进行作为基础进行分配,而预设段划分为5个预设号段,分别为:00-19,20-39,40-59,6 0-79,80-100。将用户ID的倒数两位的号码值分别对应调配到上述公开的预设号段中,例如用户A的用户ID为AB12,用户B的用户ID为BA12,则根据末尾两位数的号码值,会将用户A和用户B都调配到预设号段00-19的预设号段中。
进一步的,会将各预设号段对应调配到各服务器子集合中。举例来说,请参看图4,图4中是用户ID和城市机房ZONE(也就是服务器集合)的映射关系图。
在图4中,上海部署了ET15和em14两个物理机房。ET15物理机房部署了RZ25服务器集合,RZ25服务器集合部署了的RZ25A、 RZ25B两组服务器子集合,每个服务器子集合中分别设置了10台服务器,各服务器上设置有finauth应用。em14物理机房部署了RZ24服务器集合。RZ24服务期集合又部署了RZ24A、 RZ24B两组服务器子集合,每个服务器子集合中分别设置了10台服务器,各服务器上设置有finauth应用。
深圳部署了gtj和su18两个物理机房。gtj物理机房部署了RZ11,RZ12两个服务器集合。而RZ11服务器集合部署了RZ11A、RZ11B两组服务器子集合。RZ12服务器集合部署了RZ12A 、RZ12B两组服务器子集合,每个服务器子集合中分别设置了10台服务器,各服务器上设置有finauth应用。Su18物理机房部署了RZ13服务器集合。RZ13服务器集合部署了的RZ13A、 RZ13B两组服务器子集合,每个服务器子集合中分别设置了10台服务器,各服务器上设置有finauth应用。
以用户ID的倒数2,3位做为流量调配依据,目前通过流量调配中心将00~19的用户调配到RZ25,20~39的用户调配到RZ11,40~59的用户调配到RZ12,60~79的用户调配到RZ13,80~100调配到RZ24。这样可以实现不同的用户均衡的调配到不同的服务器集合中去处理。当然,同一个服务器集合的A,B两组服务器子集合,对外提供相同的服务。
作为一种可选定的实施例,在同一个服务器集合中的两个服务器子集合进行升级时,会执行下面的步骤:在实时监测各服务器集合的运行状态的过程中,当监测到所述第一服务器集合上的第一服务器子集合升级,则将所述第一服务器集合上的第一服务器子集合中的流量用户调配到所述第一服务器集合上的第二服务器子集合中,所述第一服务器集合中的第二服务器子集合响应所述第一服务器集合上的第一服务器子集合的流量用户的数据请求。
进一步的,若监测到所述第一服务器集合上的第一服务器子集合升级完毕,则从所述第一服务器集合上的第二服务器子集合中回调出所述第一服务器集合上的第一服务器子集合中的流量用户,并调配到所述第一服务器集合上的第一服务器子集合中。
进一步的,若监测到所述第一服务器集合上的第一服务器子集合升级完毕,则验证第一服务器子集合升级完毕后获得的新功能是否满足要求,若是,则从所述第一服务器集合上的第二服务器子集合中回调出所述第一服务器集合上的第一服务器子集合中的流量用户,并调配到所述第一服务器集合上的第一服务器子集合中。
作为一种可选的实施例,若监测到所述第一服务器集合上的第一服务器子集合升级完毕,而第一服务器集合上的第二服务器子集合进行升级时,则可以从所述第一服务器集合上的第二服务器子集合中回调出所述第一服务器集合上的第一服务器子集合中的流量用户和所述第一服务器集合上的第二服务器子集合中的流量用户,并调配到所述第一服务器集合上的第一服务器子集合中。当第一服务器集合中的第二服务器子集合升级完毕之后,再回调所述第一服务器集合上的第二服务器子集合中的流量用户即可,以使得两个服务器子集合的流量均衡分配。
故而,当某个服务器子集合升级时,可将流量引入到同一个服务器集合中的另一个服务器子集合中,发布完毕后,引入少量的流量(引入的流量值少于预设流量阈值)来做线上验证,验证升级的服务器子集合的升级后获得的新功能,验证通过后再将流量用户切换过来,升级另一个服务器子集合,当另一个服务器子集合也发布完毕后,A,B两组再各分配50%流量,实现流量均衡。这样可以实现平稳的发布,保证系统的持续可用。
以上便是服务器集合内部升级时,服务器集合内部的调配方式,下面介绍在服务器发生故障时,具体的调配方式,具体请参看步骤13。
步骤13,当监测到第一城市的第一服务器集合发生故障,则将所述第一服务器集合的流量用户调配到所述第一城市的第二服务器集合,以使得所述第二服务器集合响应所述第一服务器集合的流量用户的数据请求。
其中,所述第二服务器集合和所述第一服务器集合为同城区域中的不同的服务器集合。也即:所述第二服务器集合和所述第一服务器集合都是为第一城市中不同区域中的服务器集合。
在具体的调配过程中,若第一服务器集合发生故障,则优先将第一服务器集合中的流量用户调配到同城的其他服务器集合(例如第二服务器集合)中。“同城”的概念,是指同处于相同城市的不同区域的两个服务器集合,例如处于深圳的gtj服务器集合和su18服务器集合。“异城”的概念,是指处于不同城市的两个服务器集合,例如深圳的gtj服务器集合和处于上海的em14服务器集合。
上述实施例的手段也可以称之为“同城备灾”,也就是说,在同一城市中的其中一个服务器集合发生故障,可以将该服务器集合中的所有流量用户都调配到相同城市的另一个服务器集合进行响应,进而在短时间内(恢复时间处于预设时间范围内,例如3秒内)即可恢复响应发生故障的服务器集合对应的流量用户的数据请求的响应,从而大大提升了系统整体的性能,减少数据请求的响应时间。
作为一种可选的实施例,当监测到第一服务器集合发生故障之后,还会将所述第一服务器集合的流量用户调配到第二城市的第三服务器集合,以使得所述第三服务器集合响应所述第一服务器集合的流量用户的数据请求。其中,所述第三服务器集合和所述第一服务器集合分属于不同的城市。
进一步的,当监测到第一服务器集合发生故障之后,会先判断所述第二服务器集合是否允许调配,若允许,则优先将第一服务器集合的流量用户调配到第二服务器集合中。若不允许,例如第二服务器集合也发生故障,或者第二服务器集合的子数据库并发接入量高于预设阈值,或者第二服务器集合关闭等等情况,则将所述第一服务器集合的流量用户调配到第二城市的第三服务器集合。
上述实施例的手段也可以称之为“异城备灾”,也就是说,在某个城市中的服务器集合发生故障,可以将服务器集合中的流量用户对应调配到其他城市的服务器集合进行响应,进而在短时间内(恢复时间处于预设时间范围内,例如3秒内)即可恢复响应发生故障的服务器集合对应的流量用户的数据请求的响应,从而大大提升了系统整体的性能,减少数据请求的响应时间。
参看图5,图5是应用备灾和数据拆分映射图,备灾分为LDR的同城备灾以及RDR的异地备灾,RZ11以RZ13做为同城备灾,以RZ25做为异地备灾。其他各个服务器集合的同城和异地备灾信息如上图箭头所指。
假设深圳gtj物理机房发生故障,而RZ11服务器集合不能对外提供服务,但是Su18物理机房可用时,通过流量调配将20~39的用户请求转发到RZ13服务器集合中,很容易就实现服务的恢复。
如果出现极端情况,深圳整座城市的物理机房都不可用时,将20~39的用户调配到上海的RZ25服务器集合中,而且流量切换的过程中只有少量的用户短时间受影响,保证了系统的高可用。数据库也按照用户ID维度进行N库N表的拆分,N为正整数。每个子数据库都包含有相同的拆分数据表,并且保证各路由器、各应用各子数据库使用同一套规则,减少了跨城的调用,每个子数据库只负责一部分流量用户的请求,大大提升了系统整体的性能,减少响应时间。
下面以具体的场景为例进行举例说明。
上述实施例中的方法可用于银行、投资、开户业务中,流量用户指的就是请求在银行开户(例如开一类户、二类户、三类户等等)的用户,而服务器集合则是能够实现开户申请的各网点。以银行A为例,服务器集合是银行A分布在全球的各网点。那么对于流量用户在银行A的开户申请请求的并发量比较高,则需要服务器集合提供及时响应的高性能的开户服务。故而,可以将银行A对应的数据库分成多个子数据库,然后将每个子数据库的编号和流量用户的用户ID进行对应。如此,当有流量用户进行开户申请时,则会根据流量用户的用户ID分配到对应的子数据库中,由对应的服务器进行处理,进而能够及时快速的响应流量用户的开户申请,实现均衡响应。若监测到银行A在第一城市的第一服务器集合出现故障,则可以将第一服务器集合中的流量用户调配到同城的第二服务器集合中进行响应,或者调配到异城的第三服务器集合中进行响应,以保证在其中一个服务器集合发生故障时,其他服务器能够及时快速的响应发生故障的服务器集合的流量用户的开户请求,并且保证流量用户的开户信息不丢失。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
参看图6,本说明书的一个或者多个实施例,还公开了一种实现服务器集合均衡调配的系统,包括:
监测模块61,用于实时监测各服务器集合的运行状态,其中,各服务器集合中分配有各自的流量用户;
第一调配模块62,用于当监测到第一城市的第一服务器集合发生故障,则将所述第一服务器集合的流量用户调配到所述第一城市的第二服务器集合,以使得所述第二服务器集合响应所述第一服务器集合的流量用户的数据请求;其中,所述第二服务器集合和所述第一服务器集合为同城区域中的不同的服务器集合。
作为一种可选的实施例,本实施例的系统还包括:
第二调配模块,用于当监测到第一城市的第一服务器集合发生故障,将所述第一服务器集合的流量用户调配到第二城市的第三服务器集合,以使得所述第三服务器集合响应所述第一服务器集合的流量用户的数据请求;其中,所述第三服务器集合和所述第一服务器集合分属于不同的城市。
作为一种可选的实施例,本实施例的系统还包括:
第三调配模块,用于实时监测各服务器集合的运行状态之前,基于各流量用户的用户身份识别号ID,将所述各流量用户调配到所述各服务器集合中。
作为一种可选的实施例,所述第一调配模块62,具体包括:
第一确定模块,用于确定出各流量用户的用户身份识别号ID中的预设位数的号码值;
第二确定模块,用于基于各流量用户的用户ID中的预设位数的号码值,确定出对应编号的服务器;
第四调配模块,用于将各流量用户调配到对应编号的服务器中。
作为一种可选的实施例,本实施例的系统还包括:
第五调配模块,用于实时监测各服务器集合的运行状态之后,当监测到所述第一服务器集合上的第一服务器子集合升级,则将所述第一服务器集合上的第一服务器子集合中的流量用户调配到所述第一服务器集合上的第二服务器子集合中,所述第一服务器集合中的第二服务器子集合响应所述第一服务器集合上的第一服务器子集合的流量用户的数据请求。
作为一种可选的实施例,本实施例的系统还包括:
第六调配模块,用于当监测到所述第一服务器集合上的第一服务器子集合升级之后,若监测到所述第一服务器集合上的第一服务器子集合升级完毕,则从所述第一服务器集合上的第二服务器子集合中回调出所述第一服务器集合上的第一服务器子集合中的流量用户,并调配到所述第一服务器集合上的第一服务器子集合中。
基于与前述实施例中同样的发明构思,本发明实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现前文任一所述方法的步骤。
基于与前述实施例中同样的发明构思,本说明书的实施例还提供一种计算机设备,如图7所示,包括存储器704、处理器702及存储在存储器704上并可在处理器702上运行的计算机程序,所述处理器702执行所述程序时实现前文任一所述方法的步骤。
其中,在图7中,总线架构(用总线700来代表),总线700可以包括任意数量的互联的总线和桥,总线700将包括由处理器702代表的一个或多个处理器和存储器704代表的存储器的各种电路链接在一起。总线700还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口705在总线700和接收器701和发送器703之间提供接口。接收器701和发送器703可以是同一个元件,即收发机,提供用于在传输介质上与各种其他装置通信的单元。处理器702负责管理总线700和通常的处理,而存储器704可以被用于存储处理器702在执行操作时所使用的数据。
通过本发明实施例的一个或者多个实施例,本发明实施例具有以下有益效果或者优点:
本说明中的一个或者多个实施例公开了一种实现服务器集合均衡调配的方法及系统,该方法会实时监测各服务器集合的运行状态,其中,各服务器集合中分配有各自的流量用户;当监测到第一城市的第一服务器集合发生故障,则将所述第一服务器集合的流量用户调配到所述第一城市的第二服务器集合,以使得所述第二服务器集合响应所述第一服务器集合的流量用户的数据请求。由于将故障服务器集合的流量用户调配到了其他非故障的服务器集合中进行响应,故而能够快速响应发生故障的服务器集合对应的流量用户的数据请求的响应,从而大大提升了系统整体的性能,减少数据请求的响应时间。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述,构造这类系统所要求的结构是显而易见的。此外,本发明实施例也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明实施例的内容,并且上面对特定语言所做的描述是为了披露本发明实施例的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明实施例的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明实施例的示例性实施例的描述中,本发明实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如所述的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明实施例的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明实施例的范围之内并且形成不同的实施例。例如,在所述的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明实施例的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的网关、代理服务器、系统中的一些或者全部部件的一些或者全部功能。本发明实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明实施例的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明实施例进行说明而不是对本发明实施例进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。