具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员基于本申请所获得的所有其他实施例,都属于本发明保护的范围。
首先,结合图1对本发明实施例涉及的服务集群进行说明。
图1为本发明实施例提供的服务集群的结构示意图。图1所示的服务集群中包括多个服务节点和管理节点。其中,
服务节点,用于向终端提供有状态服务;
管理节点,用于对各个服务节点进行管理。具体的,管理节点具有节点监听功能,实时监听服务节点的运行情况,在服务节点发生故障的情况下,执行异常处理操作,从而保证整个服务集群的稳定性。
管理节点可以运行不同编程语言编写的代码,编程语言包括Java、C++等。
上述管理节点可以包括多个管理节点,对上述多个管理节点可以进行集群化部署,提高对服务节点进行管理的效率和质量。
以下对本发明实施例提供的服务提供方法进行具体说明。
参见图2,提供了一种服务提供方法的流程示意图,应用于服务集群中的管理节点,上述方法包括以下步骤S201-S203。
步骤S201:接收终端发送的用于请求有状态服务的服务请求。
上述终端可以是智能手机、计算机、可穿戴设备、智能车辆等。
当服务节点需要基于终端的状态数据响应针对某服务的服务请求时,上述服务称为有状态服务。
本发明的一个实施例中,当终端为智能车辆时,有状态服务可以是影子服务。影子服务是指用于对车辆进行实时控制的服务,影子服务能够实现车辆与云端之间的连接、云端控制车辆、车辆实时数据上报等功能,是智能车辆场景中的关键服务。
步骤S202:根据预设的终端类型与在线的服务节点之间的对应关系、以及终端的类型,从在线的服务节点中确定响应服务请求的目标服务节点。
在线的服务节点是指能够提供服务的服务节点。在线的服务节点又可以称为活跃服务节点。
终端类型在不同的应用场景下具有不同的含义,具体的,以下述三种应用场景为例:
当应用场景为智能车辆场景时,终端类型可以为车辆的车系类型。上述车系类型可以是按照车辆的品牌类别划分得到的类型,如品牌1车系、品牌2车系、品牌3车系是按照车辆的品牌类别划分得到的车系类型;上述车系类型也可以是按照车辆的外观风格划分的类型,如日式风格车系、美式风格车系是按照车辆的外观风格划分得到的车系类型。
当应用场景为天气服务场景时,终端类型可以为终端所在地的类型。上述终端所在地的类型可以是按照终端所在省份划分得到的类型,如A省类型、B省类型、C省类型是按照终端所在省份划分得到的终端所在地的类型。
当应用场景为违章服务场景时,终端类型可以为终端所对应违章服务的服务类型,如违章服务N1类型、违章服务N2类型、违章服务N3类型是按照终端所对应的违章类型划分得到的分别为不同的终端类型。
若在线的服务节点与终端类型具有对应关系,表示上述在线的服务节点可以向上述终端类型的终端提供有状态服务;若在线的服务节点与终端类型不具有对应关系,表示上述在线的服务节点不向上述终端类型的终端提供有状态服务。上述对应关系的确定方式可以参见图3所示的实施例,在此不进行详述。
上述终端的类型是指:发送服务请求的终端的类型。
具体的,获得上述终端的类型可以按照以下两种方式实现:
第一种实施方式中,服务请求可以携带发送该服务请求的终端的类型,在这种情况下,可以对服务请求进行解析,获取发送上述服务请求的终端的类型。
第二种实施方式中,管理节点本地存储了各个终端的类型,在这种情况下,当管理节点接收到终端发送的服务请求后,从本地存储的各个终端的类型中确定发送服务请求的终端的类型。
上述目标服务节点是指用于响应服务请求的服务节点。一种实施方式中,可以从预设的终端类型与在线的服务节点之间的对应关系中,确定发送服务请求的终端的类型所对应的在线的服务节点,作为目标服务节点。
例如:表1示出了终端类型与在线的服务节点之间的对应关系。
表1
当发送服务请求的终端的类型为:类型Tc时,从上述表1所示的对应关系中,可以确定类型Tc所对应的服务节点为:服务节点S2,所以,将服务节点S2确定为目标服务节点。
步骤S203:向目标服务节点转发服务请求,以使得目标服务节点响应服务请求。
具体的,可以按照以下两种方式向目标服务节点转发服务请求。
第一种实施方式中,直接将服务请求路由至上述目标服务节点。
具体的,管理节点可以通过预设协议向服务节点发送服务请求,上述预设协议可以为http(Hyper Text Transfer Protocol,超文本传输协议),由于http高可用、且相对成熟,通过http进行数据交互,能够保证数据传输的可靠性。
第二种实施方式中,将上述服务请求添加至目标消息队列中,上述目标消息队列用于存储目标服务节点所对应的终端类型的终端发送的服务请求,目标服务节点从目标消息队列中获取服务请求。
由于目标服务节点是与终端的类型的相对应的服务节点,所以,终端发送的状态数据,最终会到达目标服务节点,也就是说,目标服务节点本地存储了发送服务请求的终端的状态数据。这样,在目标服务节点接收到服务请求后,可以基于本地存储的状态数据生成响应数据,基于响应数据响应上述服务请求,而不需要从其他节点获取状态数据,降低了网络传输资源的占用,提高了网络传输资源的利用率。
以终端为智能车辆为例,目标服务节点本地存储了上述智能车辆的状态数据,如智能车辆当前的行驶里程、CPU使用率、空调温度等信息,当上述服务请求为用于获取车辆当前的行驶里程时,目标服务节点可以获取本地存储的上述智能车辆当前的行驶里程,按照预设格式对上述行驶里程进行封装,封装得到的数据作为响应数据,将响应数据向智能车辆发送,智能车辆接收到上述响应数据后,对响应数据进行解封,从而得到智能车辆当前的行驶里程。
由以上可见,本发明实施例提供的方案中,服务集群中包括管理节点和多个服务节点,并且在线的服务节点与终端类型之间具有对应关系,在管理节点接收到终端发送的服务请求后,根据上述对应关系以及终端的类型确定用于响应服务请求的在线的目标服务节点,从而基于目标服务节点向上述终端提供有状态服务。当发送服务请求的终端不同,用于响应服务请求的目标服务节点可能也不同,所以,是由多个服务节点向各终端提供有状态服务,相较于现有技术中由单节点向各终端提供有状态服务,显著提高了服务质量。
并且,由于上述对应关系反映了终端类型与在线的服务节点之间的关联关系,根据发送服务请求的终端类型以及上述对应关系,能够较为准确地确定用于响应服务请求的目标服务节点,这样,向上述目标服务节点转发服务请求后,直接由目标服务节点响应服务请求,而不需要由目标服务节点进一步确定用于响应服务请求的服务节点,并通过网络向新的服务节点转发服务请求,减少了网络传输资源的占用,提高了网络传输资源的利用率。
另外,由于终端类型与在线的服务节点之间具有对应关系,终端类型的终端发送的状态数据均会存储至相对应的服务节点,所以,每一服务节点本地存储了相对应的终端类型的终端的状态数据。当服务节点接收到服务请求后,只需要从本地存储的状态数据中读取用于响应服务请求的状态数据,而不需要通过网络从其他节点获取状态数据,减少了网络传输资源的占用,提高了网络传输资源的利用率。而且,服务节点本地只存储相对应的终端类型的终端的状态数据,不需要存储所有终端的状态数据,避免了服务节点内存被大量占用情况,提高了服务节点的内存利用率。
并且,若在服务集群中增加多个服务节点,能够响应数量更多的服务请求,服务集群的吞吐量随着服务节点的数量随之增加。并且,在终端类型的终端的数量不发生较大改变情况下,各服务节点本地存储的终端的状态数据随着服务节点的增加而线性减小,进一步提高了服务节点的内存利用率。
上述步骤S202中终端类型与在线的服务节点之间的对应关系可以按照图3所示实施例中提及的对应关系的确定方式确定上述对应关系。本发明的一个实施例中,参见图3,提供了第一种对应关系确定方法的流程示意图,图3所示实施例中包括以下步骤S301-S302。
步骤S301:确定在线的服务节点。
一种实施方式中,服务节点可以按照预设时间间隔向管理节点发送心跳包,当管理节点接收到服务节点发送的心跳包时,表示该服务节点为在线的服务节点;当关联节点未接收到服务节点发送的心跳包时,表示该服务节点不是在线的服务节点。
上述预设时间间隔可以是10ms、20ms等。
具体的,服务节点中可以集成管理节点相对应的客户端模块,服务节点通过所集成的客户端模块,定时向服务节点发送心跳包。管理节点具有服务节点监听功能以及心跳检测功能,管理节点基于服务节点监听功能能够接收服务节点发送的心跳包,并基于心跳检测功能对心跳包进行检测。
服务节点还可以通过上述客户端模块在管理节点中进行服务节点注册,管理节点可以对所注册的节点进行统一管理。并且,可以将上述客户端模块快速集成于不同的应用场景中已有的服务节点中,而不改变已有服务节点自身的架构,将上述客户端模块称为无入侵式的客户端模块。
步骤S302:基于各终端类型对应的权重,确定在线的服务节点所对应的终端类型,得到终端类型与在线的服务节点之间的对应关系。
上述终端类型对应的权重表征终端类型的终端的数量。以终端类型为车辆的车系类型为例,车系类型T1的车辆的数量为1000,车系类型T2的车辆的数量为500,车系类型T3的车辆的数量为500,相对应的,车系类型T1对应的权重为2,车系类型T2对应的权重为1,车系类型T3对应的权重为1。
具体的,管理节点提供的用户界面中显示了用于录入终端类型对应的权重的录入框,工作人员预先通过上述用户界面中的录入框录入终端类型对应的权重,管理节点从而获得工作人员输入的终端类型对应的权重。
一种实施方式中,可以对每一在线的服务节点与每一终端类型进行组合,针对每一组合,计算该组合中各服务节点所对应终端类型的总权重,从各组合中确定所包含各服务节点的总权重之间的差值小于预设差值的目标组合,将目标组合所包含的各服务节点对应的终端类型确定为各在线的服务节点对应的终端类型。
例如:在线的服务节点包括Sa、Sb,各终端类型包括T1、T2、T3,其中,T1对应的权重为10,T2对应的权重为5,T3对应的权重为5,预设差值为1。
对每一在线的服务节点与每一终端类型进行组合,得到多种组合,如表2所示。
表2
在表2中,每一行表示一个组合,以第一行的组合为例,表示该组合中Sa对应的终端类型为T1,Sb对应的终端类型为T2、T3。
表2中还示出了每一个组合中包含的各服务节点所对应终端类型的总权重,由于第一行的组合中各服务节点的总权重是相等的,各服务节点的总权重之间的差值小于预设差值1,并且第六行的组合中各服务节点的总权重也是相等的,各服务节点的总权重之间的差值小于预设差值1,所以,可以将第一行的组合中各服务节点对应的终端类型确定为各在线的服务节点对应的终端类型,也可以将第六行的组合中各服务节点对应的终端类型确定为各在线的服务节点对应的终端类型。
由以上可见,由于是基于各终端类型对应的权重,确定在线的服务节点所对应的终端类型,并且终端类型对应的权重表征终端类型的终端的数量,所以,确定得到的服务节点所对应的终端类型是与终端类型的终端的数量相关联的。又由于当终端类型的终端的数量与服务请求的数量相关联,所以,所确定的各服务节点所对应的终端类型是与服务请求的数量相关联,从而使得后续服务节点为所对应的终端类型的终端提供服务时,能够适用于服务请求的数量,从而有效减少服务节点负载不均衡的问题。
在上述步骤S302确定在线的服务节点与终端类型之间的对应关系后,还会存在新上线服务节点的情况,针对新上线的服务节点,需要确定这些服务节点对应的终端类型。基于此,本发明的一个实施例中,参见图4a,提供了第二种对应关系确定方法的流程示意图。
具体的,图4a所示实施例中包括以下步骤S401-S405。
步骤S401:确定在线的服务节点。
步骤S402:基于各终端类型对应的权重,确定在线的服务节点所对应的终端类型,得到终端类型与在线的服务节点之间的对应关系。
上述终端类型对应的权重表征终端类型的终端的数量。
上述步骤S401-S402分别与上述图3所示的实施例中步骤S301-S302相同,在此不再赘述。
步骤S403:若检测到新上线的第一服务节点,判断是否存在未确定对应关系的第一终端类型。若存在,触发步骤S404,若不存在,触发步骤S405。
在线的服务节点按照预设的时间间隔向管理节点发送心跳包,当服务节点具有对应的终端类型时,服务节点发送的心跳包中则包含该服务节点所对应的终端类型;当服务节点为新上线的服务节点时,由于还未对新上线的服务节点确定所对应的终端类型,所以,服务节点发送的心跳包中不包含终端类型。基于此,本发明的一个实施例中,可以接收服务节点的心跳包;若上述心跳包中未包含上述服务节点所对应的终端类型,确定上述服务节点为新上线的第一服务节点,若上述心跳包中包含服务节点所对应的终端类型,确定上述服务节点不为新上线的第一服务节点。
由于服务节点能够发送心跳包表示该服务节点处于在线状态,并且当心跳包中不包含服务节点所对应的终端类型,表示上述在线的服务节点为新上线的服务节点,且未确定所对应的终端类型,所以,即通过检测心跳包中是否包含服务节点所对应的终端类型,能够较为确定地服务节点是否为新上线的服务节点。
并且,管理节点通过接收服务节点的心跳包,确定服务节点当前所处的生命周期状态,基于服务节点所处不同状态采取不同的操作,实现管理节点对服务节点处于不同生命周期进行有效管理。
未确定对应关系的第一终端类型是指:未确定相对应的服务节点的终端类型。例如:终端类型包括C1、C2、C3,预设的对应关系中包括C1与服务节点S1之间的对应关系、C2与服务节点S1之间的对应关系,但不存在C3与服务节点之间的对应关系,所以,C3为未确定相对应的服务节点的终端类型,即未确定对应关系的第一终端类型。
一种实施方式中,管理节点中记录有表征各个终端类型是否有对应的服务节点的信息,基于此,可以从管理节点本地记录的信息中确定是否存在不具有相对应的服务节点的终端类型,若存在,表示存在第一终端类型,若不存在,表示不存在第一终端类型。
步骤S404:将第一终端类型确定为第一服务节点对应的终端类型。
由于第一服务节点为新上线的服务节点,第一服务节点是未确定对应关系的服务节点,第一终端类型也是未确定对应关系的终端类型,所以,可以将第一终端类型确定为第一服务节点对应的终端类型。
步骤S405:从各在线的服务节点所对应的终端类型中确定第二终端类型,作为第一服务节点所对应的终端类型。
具体的,可以按照以下两种方式确定第二终端类型。
第一种实施方式中,基于在线的服务节点所对应终端类型的确定时刻,从各在线的服务节点所对应的终端类型中确定第二终端类型。
上述确定时刻表示确定在线的服务节点对应终端类型的时刻,也就是确定在线的服务节点与终端类型之间对应关系的时刻。
可以按照以下两种方式基于确定时刻确定第二终端类型:
一种方式中,可以从确定在线的服务节点所对应终端类型的确定时刻中确定最新时刻;将上述最新时刻所确定的终端类型确定为第二终端类型。
在上述步骤S402中,确定各在线的服务节点所对应终端类型的确定时刻是相同的,而当上述各在线的服务节点中存在服务节点下线的情况时,需要将该下线的服务节点所对应终端类型确定为其他在线的服务节点所对应的终端类型,所以,针对上述其他在线的服务节点,是在已确定所对应终端类型的基础上,又添加了终端类型,在这种情况下,后添加的终端类型的确定时刻相对于已确定的终端类型的确定时刻是相对较新的。基于此,最新时刻所确定的终端类型大概率是已下线的服务节点所对应的终端类型,当存在新上线的服务节点时,可以将最新时刻所确定的终端类型作为上述新上线的服务节点所对应的终端类型。
具体的,管理节点本地记录有在线的服务节点所对应的各终端类型的确定时刻,可以从本地记录的确定时刻中确定最新时刻。
另一种方式中,可以从确定在线的服务节点所对应终端类型的确定时刻中确定预设数量个最新时刻;将上述预设数量个最新时刻所确定的终端类型确定为第二终端类型。上述预设数量可以为2、4等。
第二种实施方式中,计算每一在线的服务节点所对应的终端类型的总权重,确定总权重大于平均权重值的服务节点,从所确定的服务节点所对应的终端类型中确定第二终端类型。上述平均权重值是各在线的服务节点所对应的终端类型的总权重的平均值。
当存在总权重大于平均权重值的服务节点时,表示该服务节点后续需要响应的服务请求的数量相对于其他服务节点需要响应的服务请求的数量较多,从而会对该服务节点造成较大的负载压力,因此,可以通过新上线的服务节点分担该服务节点后续可能产生的负载压力,所以,可以从总权重大于平均权重值的服务节点所对应的终端类型中确定第二终端类型,作为新上线的第一服务节点所对应的终端类型。
具体的,可以根据所确定的服务节点所对应的各终端类型的权重值,从上述各终端类型中确定第二终端类型。例如:可以从所确定的服务节点所对应的终端类型中确定权重值最小的终端类型,也可以从所确定的服务节点所对应的终端类型中确定权重值最大的终端类型。
例如:假设各在线的服务节点分别为SA、SB,各在线的服务节点所对应的终端类型以及总权重可以参见表3。
表3
由表3可以计算得到,平均权重值=(12+6)/2=9,可以看到SA的总权重12大于平均权重值9,所以,从SA对应的终端类型中确定第二终端类型,如可以选择权重值最大的终端类型C2,作为第二终端类型。
在上述步骤S404确定第一终端类型为第一服务节点对应的终端类型后,需要将第一服务节点与第一终端类型之间的对应关系向第一服务节点、网关服务器以及备份库发送。在上述步骤S405确定第二终端类型为第一服务节点所对应的终端类型后,需要将第一服务节点与第一终端类型之间的对应关系向第一服务节点、网关服务器以及备份库发送。从上述过程可以看到,在新增加对应关系后,需要将对应关系向第一服务节点、网关服务器以及备份库发送。
基于上述情况,在新增加了针对第一服务节点的对应关系后,本发明的一个实施例中,管理节点将针对第一服务节点的对应关系向第一服务节点、网关服务器以及备份库发送,以使得第一服务节点、网关服务器以及备份库存储上述对应关系。
上述备份库用于存储各服务节点所对应的终端类型。上述备份库可以是Redis(Remote Dictionary Server,远程字典服务)、mysql(关系型数据库管理***)等。
具体的,可以按照第一预设顺序依次向第一服务节点、网关服务器以及备份库发送上述对应关系。上述第一预设顺序可以为:首先第一服务节点,然后网关服务器,最后备份库的顺序。
以下结合图4b,对上述过程进行说明。
管理节点确定新增的对应关系后,需要对新增的对应关系中的服务节点以及终端类型进行健康性检查。上述健康性检查包括对服务节点是否在线进行检查,检查终端类型是否为其他服务节点对应的终端类型。当健康性检查通过,管理节点向第一服务节点发送上述对应关系。
第一服务节点将对应关系中终端类型记入本地cache(缓存),并将操作结果向管理节点发送。
管理节点同步等待第一服务节点的操作结果,在获得第一服务节点的操作结果后,确定第一服务节点是否存储对应关系,若为是,向网关服务器发送对应关系。
在网关服务器存储对应关系成功后,将对应关系写入Redis,在写入Redis成功后,在本地存储上述对应关系。
在上述步骤S405中,是从各在线的服务节点所对应的终端类型中确定第二终端类型,将第二终端类型确定为第一服务节点所对应的终端类型,也就是在已有对应关系中取消了第二终端类型与原在线的服务节点之间的对应关系,在这种情况下,需要将所取消的对应关系告知原在线的服务节点、网关服务器以及备份库,以使得原在线的服务节点、网关服务器以及备份库删除已存储的上述对应关系。
上述原在线的服务节点是指:第二终端类型原本所对应的服务节点。
具体的,可以按照第二预设顺序依次向原在线的服务节点、网关服务器以及备份库发送上述对应关系。上述第二预设顺序可以为:首先原在线的服务节点,然后网关服务器,最后备份库的顺序。
以下结合图4c,对上述过程进行说明。
管理节点确定取消的对应关系后,需要对第一服务节点进行检查,判断第一服务节点是否在线,若为是,管理节点向原在线的服务节点的服务节点告知取消缓存第二终端类型。
原在线的服务节点取消第二终端类型的本地缓存后,将操作结果向管理节点发送。
管理节点同步等待原在线的服务节点的操作结果,在获得原在线的服务节点的操作结果后,确定原在线的服务节点是否成功取消第二终端类型的本地缓存,若为是,向网关服务器告知取消上述对应关系。
在网关服务器成功取消上述对应关系后,告知Redis取消上述对应关系,在Redis成功取消上述对应关系后,在本地取消上述对应关系。
在上述步骤S302确定在线的服务节点与终端类型之间的对应关系后,还会存在服务节点下线的情况,针对下线的服务节点,需要将下线的服务节点对应的终端类型转移给其他在线的服务节点。基于此,本发明的一个实施例中,参见图5,提供了第三种对应关系确定方法的流程示意图。
具体的,图5所示实施例中包括以下步骤S501-S503。
步骤S501:确定在线的服务节点。
步骤S502:基于各终端类型对应的权重,确定在线的服务节点所对应的终端类型,得到终端类型与在线的服务节点之间的对应关系。
上述终端类型对应的权重表征终端类型的终端的数量。
上述步骤S501-S502分别与上述图3所示的实施例中步骤S301-S302相同,在此不再赘述。
步骤S503:若检测到下线的第二服务节点,根据第二服务节点所对应的第三终端类型的权重,以及除第二服务节点之外的其他在线的服务节点所对应的终端类型的权重,从其他在线的服务节点中确定第三终端类型所对应的服务节点。
具体的,可以按照以下两种方式检测下线的第二服务节点:
第一种方式,服务节点在即将下线时,向管理节点发送表征服务节点下线的离线包,以告知管理节点服务节点自身所处的状态。基于此,管理节点可以接收表征服务节点下线的离线包,确定发送离线包的服务节点,作为下线的第二服务节点。
具体的,管理节点可以对上述离线包进行解析,确定发送离线包的服务节点,作为下线的第二服务节点。
第二种方式,确定发送心跳包的间隔时长超过预设间隔时长的服务节点,作为下线的第二服务节点。
当发送心跳包的间隔时长超过预设间隔时长,表示心跳包超时,当心跳包超时,大概率表示发送该心跳包的服务节点处于下线状态,因此,可以将上述服务节点确定为下线的第二服务节点。
当第二服务节点下线时,需要重新确定第三终端类型所对应的服务节点。具体的,可以按照以下两种实施方式确定第三终端类型所对应的服务节点。
第一种实施方式中,可以计算每一其他在线的服务节点所对应的终端类型的总权重,确定目标数量个总权值最小的服务节点,将所确定的服务节点分别确定为第三终端类型所对应的服务节点。上述目标数量为第三终端类型的数量。
具体的,可以对目标数量个总权值最小的服务节点按照总权值由小到大的顺序进行排列,并对各第三终端类型按照所对应的权重由小到大的顺序进行排列,确定第三终端类型对应的服务节点为处于同一位置的服务节点。
例如:目标数量为3,3个总权值最小的服务节点包括S1、S2、S3,对上述服务节点按照总权值由小到大的顺序进行排列得到:S1、S3、S2,第三终端类型包括Ca、Cb、Cc,对上述第三终端类型按照所对应的权重由小到大的顺序进行排列得到:Ca、Cb、Cc。针对第三终端类型Ca,与Ca处于同一位置的服务节点为S1,所以,将S1确定为Ca对应的服务节点;针对第三终端类型Cb,与Cb处于同一位置的服务节点为S2,所以,将S2确定为Cb对应的服务节点;针对第三终端类型Cc,与Cc处于同一位置的服务节点为S3,所以,将S3确定为Cc对应的服务节点。
第二种实施方式中,计算每一其他在线的服务节点所对应的终端类型的总权重,确定总权值最小的服务节点,将所确定的服务节点确定为第三终端类型所对应的服务节点。
例如:沿用前述例子,总权值最小的服务节点为S1,将S1确定为第三终端类型对应的服务节点。
由于当服务节点下线时,大概率表示该服务节点出现故障,当存在这种情况时,管理节点针对下线的服务节点所对应的第三终端类型重新确定所对应的服务节点,这样,即使在服务节点出现故障的情况下,尽可能保证第三终端类型具有相对应的服务节点,实现了在服务节点故障情况下对发生故障的服务节点所对应的终端类型进行转移,以保证能够稳定地向各终端类型的终端提供服务。
在上述步骤S503确定第三终端类型所对应的服务节点后,管理节点将上述服务节点第一服务节点与所对应的终端类型之间的对应关系向第一服务节点、网关服务器以及备份库发送,以使得第一服务节点、网关服务器以及备份库存储上述对应关系。上述备份库用于存储各服务节点所对应的终端类型。上述备份库可以是Redis、mysql等。具体实现过程可以参见图4b所示的实施例。
以下结合不同场景,对服务节点上线或下线的情况进行具体说明。
假设有三个在线的服务节点,分别为A、B、C。
按照前述图3所示实施例中确定各在线的服务节点对应的终端类型的确定方式,确定上述三个在线的服务节点所对应的终端类型。这一次终端类型的确定可以称为第一次分配场景。
在服务节点运行过程中,当A断网出现异常时,A下线,服务集群出现了服务节点下线的情况,在这种情况下,会出现以下四种场景:
若第一种场景为:A下线后的预设时长内存在上线的服务节点D。
在A下线后的预设时长内,还未针对A对应的终端类型a重新确定所对应的服务节点,上述终端类型a为:还未确定对应关系的终端类型,在这种情况下,可以按照前述步骤S404的方式,将终端类型a确定为D对应的终端类型。
若第二种场景为:A下线后的预设时长内不存在上线的服务节点。
在这种情况下,可以按照前述步骤S503的方式针对A对应的终端类型a重新确定所对应的服务节点。
假设在第二种场景中,重新确定终端类型A对应的服务节点为B,B与多个终端类型均有对应关系,且终端类型A的确定时刻相较于B所对应的其他终端类型的确定时刻是较新的,在这种情况下,若存在新上线的服务节点E,可以按照前述步骤S405中提及的第二终端类型的确定方式,将终端类型A确定为E对应的终端类型。
以下结合图6,对本发明实施例提供的对应关系确定方法进行具体说明。
参见图6,提供了一种对应关系确定方法的信令交互图。图6中包括服务节点和管理节点。
服务节点向管理节点发送心跳包,管理节点接收服务节点发送的心跳包,在心跳包中不包含服务节点所对应的终端类型的情况下,判断是否存在未确定对应关系的终端类型;若存在,将上述终端类型确定为新上线的服务节点对应的终端类型;若不存在,从各在线的服务节点所对应的终端类型中确定新上线的服务节点所对应的终端类型。
当服务节点向管理节点发送离线包,或,管理节点确定某服务节点的心跳包超时,管理节点确定下线的服务节点,从在线的服务节点所对应的终端类型中确定下线的服务节点对应的终端类型。
本发明的一个实施例中,管理节点集成了各种功能模块,具有各种不同的功能,如心跳检测功能、服务节点监听功能、对应关系确定功能等。如图7a所示,图7a示出了管理节点所具有的各种功能模块。在图7a的第二层中包括终端类型管理模块、在线的服务节点管理模块、对应关系确定模块以及服务节点监听以及故障转移模块。
其中,终端类型管理模块,用于记录各种终端类型以及各种终端类型的终端的信息。在这一模块下,可以包括多个功能子模块,如终端类型增加子模块、终端类型减少子模块、终端类型记录子模块等。
在线的服务节点管理模块,用于对各在线的服务节点进行管理。
对应关系确定模块,用于确定在线的服务节点与终端类型之间的对应关系。在这一模块下,可以包括多个功能子模块,如取消对应关系子模块、对应关系记录子模块等。
服务节点监听以及故障转移模块,用于对各服务节点进行监听、心跳检测,异常报警等。
上述异常报警可以是由至少以下两种不同情况触发的。
第一种情况,当管理节点检测到不同的服务节点所对应的终端类型相同时,触发异常报警功能,针对上述情况进行异常报警。
第二种情况,当管理节点检测到服务节点上报的其所对应的终端类型与备份库中存储的该服务节点所对应的终端类型不同时,触发异常报警功能,针对上述情况进行异常报警。
由于管理节点具有上述各种功能,相较于其他管理节点,所具有的功能较为全面和丰富,从而有效管理各服务节点,使得各服务节点能够稳定的、可靠的提供有状态服务。
本发明的一个实施例中,服务节点可以集成管理节点相对应的客户端模块,服务节点可以通过上述客户端模块向管理节点发送信息,如发送心跳包、离线包等。
图7b示出了管理节点与服务节点之间进行交互的交互框图。在图7b中,服务节点通过所集成的客户端模块向管理节点发送心跳包,管理节点接收服务节点发送的心跳包,对心跳包进行检测;基于所接收的心跳包,确定在线服务节点,并监听在线服务节点;管理节点还确定各在线服务节点与终端类型之间的对应关系,当接收到的心跳包中不包含服务节点所对应的终端类型时,基于上述对应关系确定上述服务节点对应的终端类型。
管理节点本地存储了各种终端类型的信息,包括终端类型的标识以及终端类型所对应的权重,并存储了各种在线的服务节点的信息,还存储了未确定对应关系的终端类型的信息。管理节点基于本地存储的上述信息,确定上述服务节点对应的终端类型。
本发明实施例还提供了一种电子设备,如图8所示,包括处理器801、通信接口802、存储器803和通信总线804,其中,处理器801,通信接口802,存储器803通过通信总线804完成相互间的通信,
存储器803,用于存放计算机程序;
处理器801,用于执行存储器803上所存放的程序时,实现如下步骤:
接收终端发送的用于请求有状态服务的服务请求;
根据预设的终端类型与在线的服务节点之间的对应关系、以及终端的类型,从在线的服务节点中确定响应服务请求的目标服务节点;
向目标服务节点转发服务请求,以使得目标服务节点响应服务请求。
上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect,PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture,EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
在本发明提供的又一实施例中,还提供了一种计算机可读存储介质,该计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现上述服务提供方法的步骤。
在本发明提供的又一实施例中,还提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述服务提供方法。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于电子设备而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本发明的较佳实施例,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本发明的保护范围内。