一种优化Presence信息负载的方法与流程

本发明涉及一种计算机领域，特别是一种优化微服务器presence信息负载的方法。

背景技术：

微服务是一种软件架构风格，以单一责任与功能的小型功能区块为基础，利用模组化的方式组合出复杂的大型应用程序，同时各个功能区块使用与语言无关的api集相互进行通讯。微服务以业务功能为主实现服务设计，每一个服务都具有自主运行的业务功能，对外开放不受语言限制的api，应用程序则是由一个或多个微服务组成。若需要针对特定业务功能进行扩充时，只要对该业务功能的服务进行扩展就好，不需要对整个应用程序进行扩展，同时，由于微服务是以业务功能导向的实作，因此不会受到应用程序的干扰，微服务的管理员可以视运算资源的需要来配置微服务到不同的运算资源内，或是布建新的运算资源对其进行配置。

微服务的特点决定了功能模块的部署是分布式的，大部分功能模块都是运行在不同机器上，彼此通过调用进行交互，前后台的业务流会经过很多个微服务的处理和传递，出现了异常就需要快速定位出错环节。因此，在这种框架下，对微服务的监控就显得尤为重要。掌控各个微服务节点实例的状态信息，包括：微服务器负载情况、数据库连接信息、服务调用、逻辑流或页面流的调用情况、及执行时长等都是十分必要的。

微服务器负载有以下两种分类方式：

1：从负载网络特性看，主要包括域内负载和域间负载。域内负载是指，两个客户端连接到同一个微服务器通信时产生的网络流量，而域间负载是指，两个客户端通过连接不同微服务器通信时产生的网络流量，显然域内负载是域间负载的子集；

2：从负载内容特性看，主要包括instant消息负载和presence信息负载。instant消息是用户传递的交互信息，而presence信息则用于表达一个实体当前的网络可用性，包括主状态(如离线、在线等)和亚状态(如忙碌、离开等)。

由于instant消息负载，在微服务器总负载中占据很大的比例，因此目前面向instant消息的负载优化占有主导地位。然而，如果城域内几十万人同时在线使用微服务器，尽管单个presence信息所用字节较小，但是presence信息负载总和仍将是一个不容忽视的数字，会对微服务器造成非常大的负担。

因此，如何基于对presence信息传输的负载优化实现高效的信息传输，具有重要意义，已经引起工业界和学术界的广泛关注，需要面对两个重要挑战：

1，微服务通信协议多种多样，不同的协议提供不同的接口和功能。针对某种特定的协议，如何利用或扩展相关接口，获取消息传输的相关信息(如计算传输剩余时间等)，是负载优化的前提和基础。

2，presence信息服务的相关机制比较复杂(包含初始化presence信息和presence信息广播等功能)，对每个客户端c来说，均包括presence信息主动汇报和被动汇报。主动汇报是指当客户端presence状态发生变化时，主动向微服务器报告。而被动汇报是指接受到微服务器固定频率的探测后进行报告。

因此，如何有效地改进presence信息服务的相关机制以降低presence信息负载，是亟待解决的核心问题。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本发明的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本发明的目的在于提供一种降低presence信息负载的方法的方法，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

具体的，本发明提供一种降低presence信息负载的方法，该方法包括：

(1)、选取rest协议作为微服务器消息传输的承载协议；

(2)、设定用户在与微服务器进行消息传输结束前的presence信息状态不变，该设定是基于用户在与微服务器进行消息传输结束前的presence信息状态变化的概率非常小；该信息状态包括主状态(离线、在线等)和亚状态(忙碌、离开等)；

(3)、计算消息传输时间；

(4)、当用户客户端presence信息状态发生变化时主动向微服务器汇报；

(5)、对消息传输中的presence信息进行维护。

优选地，计算消息传输时间的方法为：

第一步，从iq流中读取客户端ca和微服务器端s的jid，判断客户端ca和服务器端s是否位于相同的域内；若是，则执行第二步；若否，则执行第三步；

第二步，若客户端ca和微服务器端s位于相同域内，则从所述iq流中读取传输消息大小size，并判断客户端ca是否与微服务器端s协商成功；若是，则执行第四步；若否，则执行第五步；

第三步，若客户端ca和微服务器端s不在一个相同域内，则系统恢复正常的presenceprobe机制；

第四步，若判定客户端与微服务器端协商成功，则向客户端ca询问tcp1080端口的消息传输速度，在明确消息传输速度后，系统获取传输速度v，并计算消息传输时间t0：t0＝size/v

第五步，若判定客户端与微服务器端协商不成功，则系统恢复正常的presenceprobe机制。

优选地对消息传输中的presence信息进行维护的具体方法为：

第一步，在消息开始传输时启动定时器t；

第二步，判断消息传输是否失败，或所述定时器是否到时；

第三步，若判定消息传输失败或者定时器到时，则直接恢复到正常的presenceprobe机制；

第四步，若判定消息没有传输失败且定时器未到时，则进一步判断系统是否收到客户端ca的presenceprobe信息；

五步，若判定收到客户端ca的presenceprobe信息，则利用微服务器本地database中存储的消息传输前客户端ca和微服务器端s的presence信息进行回复；若判定没有收到客户端ca的presenceprobe信息，则返回第二步重新判定消息传输是否失败，或定时器是否到时。

客户端与微服务器的接口调用具体为：

客户端ca和微服务器端s的协商信息包括：传输协议、是否接受、网络地址信息以及端口信息；

所述协商信息在流的<iq/>节中传输，所述协商信息中携带有客户端ca和微服务器端s的jid信息；所述jid信息的格式为node@domain/resource，其中domain表示一个网关，或者是提供服务的一个子节点，所述resource代表一个特定的会话或连接。

传输消息大小和传输时间估算的具体方法为：

所述客户端ca和所述微服务器端s针对传输协议协商完毕以后，还要对消息相关信息进行协商，从而确定微服务器端s是否接受消息；其中，协商信息包含在<iq/>节的<message/>元素中，通过捕获<message/>元素中size属性的值，可以获得传输消息的大小；

若经过协商，微服务器端s接受客户端ca的传输消息请求，会回送给客户端ca确认信息，并通知ca建立消息流；

为获取客户端ca和微服务器端s间，微服务器会向客户端ca发送询问信息；为此，根据xml语法定义<rate/>元素，其中只包含一个rate属性，询问信息被包含在iq节中传输；

微服务器通过传输消息大小size和消息流传输速度v来估算消息传输时间t0＝size/v。

更进一步，由于消息流的传输速度是由慢到快的过程，获取的上述消息流传输速度v的值比平均值稍小，故估算出的消息传输时间是消息传输所需实际时间的最大值。

基于定时器和事件的混合presenceprobe机制为：

ca和s完成消息流协商后开始传输文件，而当客户端ca和微服务器s进行消息传输时，我们可以认为其在线或离线信息基本不变。此时，服务器开启定时器t，在定时器到时前，若消息传输没有中断，则认为ca和s的在离线状态不变。此时，若微服务器收到对ca和s的presence信息查询请求，则直接用服务器本地数据库中存储的消息传输前ca和s的presence信息状态应答。若消息传输出现中断，客户端负责向微服务器主动报告文件传输中断信息，服务器会停止定时器，并恢复原有presence信息服务机制(收到对客户端的presence信息查询请求后，实时向客户端发送probe信息查询)。当定时器时间到时时，认为消息传输完成，服务器同样会恢复原有presence信息服务机制

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了一种降低presence信息负载的方法的流程图；

图2示意性示出了基于rest协议的分布式应用架构；

图3示意性示出一种针对消息传输的负载信息维护流程图；

图4示意性示出了协商信息流中<iq/>节解析图；

图5示意性示出一种<iq/>节中<message/>元素解析图；

图6示意性示出一种消息流确认消息格式；

图7示意性示出了消息流传输速度询问消息及应答消息格式。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本发明的各方面。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

如图1所示为一种降低presence信息负载的方法的流程图，其包括：选取rest协议作为微服务器消息传输的承载协议；设定用户在与微服务器进行消息传输结束前的presence信息状态不变，该设定是基于用户在与微服务器进行消息传输结束前的presence信息状态变化的概率非常小；该信息状态包括主状态(离线、在线等)和亚状态(忙碌、离开等)；计算消息传输时间；当用户客户端presence信息状态发生变化时主动向微服务器汇报；对消息传输中的presence信息进行维护。

图2示意性示出了一种基于rest协议的分布式应用架构，具体应用于打车服务中，rest(representationalstatetransfer，即表现层状态转换)是便于不同软件/程序在网络中互相传递信息。目前在三种主流的web服务实现方案中，因为rest模式与复杂的soap和xml-rpc相比更加简洁，越来越多的web服务开始采用rest风格进行设计和实现。

图3则清晰地表达了针对消息传输的负载信息维护完整流程：

(1)从iq流中读取客户端ca和微服务器端s的jid；

(2)判断客户端ca和服务器端s是否位于相同的域内；若是，则执行(3)；若否，则执行(9)；

(3)若客户端ca和微服务器端s位于相同域内，则从所述iq流中读取传输消息大小size，并判断客户端ca是否与微服务器端s协商成功；若是，则执行(4)，若否，则执行(9)；

(4)若判定客户端与微服务器端协商成功，则向客户端ca询问tcp1080端口的消息传输速度，在明确消息传输速度后，系统获取传输速度v，并计算消息传输时间t0：t0＝size/v；

(5)在消息开始传输时，启动定时器t；

(6)判断消息传输是否失败，或所述定时器是否到时；若否，则执行(7)，若是，则执行(9)；

(7)若判定消息没有传输失败且定时器未到时，则进一步判断系统是否收到客户端ca的presenceprobe信息；若是，则执行(8)，若否，则返回执行(6)；

(8)若判定收到客户端ca的presenceprobe信息，则利用微服务器本地database中存储的消息传输前客户端ca和微服务器端s的presence信息进行回复；

(9)系统恢复正常的presenceprobe机制，维护结束。

图4示出了协商信息流中<iq/>节解析图。传输消息前，ca和s要针对传输协议、是否接受、以及网络地址和端口等信息进行协商，协商信息在流的<iq/>节中传输。如图4所示，信息中携带有ca和s的jid(jabberidentifier)，格式为node@domain/resource。其中domain表示一个网关，或者是提供服务的一个子节点；resource通常代表一个特定的会话、连接、属于实体的对象。

图5示意性示出一种<iq/>节中<message/>元素解析图。ca和s针对传输协议协商完毕以后，还要对消息相关信息进行协商，从而确定s是否接受消息。协商信息包含在<iq/>节的<message/>元素中。我们通过捕获<message/>元素中size属性的值，可以获得传输消息的大小。

图6示意示出一种消息流确认消息格式。若经过协商，s接受ca传输消息请求，会回送给ca确认信息，并通知ca建立消息流。

图7示意性示出了消息流传输速度询问消息及应答消息格式。为了获取ca和s间消息传输流的速度，微服务器会向客户端ca发送询问信息。为此，根据xml语法定义了<rate/>元素，其中只包含一个rate属性。询问信息也被包含在iq节中传输。微服务器可以通过消息大小size和消息流传输速度v来估算消息传输时间t0＝size/v。另外，由于消息流的传输速度是刚开始缓慢后来逐渐加快的，所以我们获取的v值比平均值稍小，故估算出的是消息传输时间的最大值。

ca和s完成消息流协商后开始传输文件。当客户端ca和微服务器s进行消息传输时，认为其在线离线信息基本不变。此时，服务器开启定时器t，在定时器未到时前，若消息传输没有中断，则认为ca和s的在离线状态不变。此时若微服务器收到对ca和s的presence信息查询请求，可以直接用服务器本地数据库中存储的消息传输前ca和s的presence信息状态应答。若消息传输出现中断，客户端负责向服务器报告文件传输中断信息，服务器会停止定时器，并恢复原有presence信息服务机制(收到对客户端的presence信息查询请求后，实时向客户端发送probe信息查询)。当定时器时间到时时，我们认为消息传输完成，服务器同样会恢复原有presence信息服务机制。

下表中明确了presence信息查询应答策略：

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。