一种支撑互联网问诊服务的集群式即时消息系统及其实现方法

摘要

本发明属于即时通讯技术领域，涉及一种支撑互联网问诊服务的集群式即时消息系统及其实现方法。本发明方法对比标准的Jabber/XMPP架构与协议有着很大的优势，首先客户端不再受到命名约束，而且可以自动化的动态注册到集群任意消息服务，极大的保证了客户端的即时消息使用的高可靠性；其次基于网络连接数的均衡负载算法，比手动域名配置来看，最大化利用好集群中每个节点的资源，并且可以具备更好的动态伸缩性，实现更大规模的即时消息吞吐压力，最后MQ消息中心广播的模式，不仅降低了每个消息节点的路由压力，而且MQ队列的模式，防止了某个消息节点出现的突然骤然升高的并发压力，当出现突然的峰值情况，完全可以通过队列处理的一定延时来防止消息节点崩溃。

权利要求

1.一种支撑互联网问诊服务的集群式即时消息实现的方法，其特征在于，包括：通过客户端进行消息节点注册，通过SocketIO服务节点的注册请求，生成临时的、动态的令牌，由SocketIO服务端对客户端拿到的临时令牌进行令牌有效性的控制；

发送方通过消息节点通讯将消息发送到SocketIO服务节点时，SocketIO服务节点会对消息的类型进行遍历，建立观察者模式，通过图文消息监听对象，实现与图像存储系统的对接；通过视频消息监听对象，实现与视频服务系统的对接；通过健康档案消息监听对象，实现与EHR系统对接；通过处方消息监听对象，实现与HIS系统对象；

接收方不在发送方SocketIO消息节点会话内，将在SocketIO消息节点集群广播，如果接收方不在自己的会话内就丢弃，如果接收方在会话内找到就进行SocketIO服务节点与业务节点之间的消息通知、业务交互、结果封装及结果消息发送接收端；

所述HIS系统为医院信息管理系统，所述EHR系统为电子健康档案系统。

2.根据权利要求1所述支撑互联网问诊服务的集群式即时消息实现的方法，其特征在于，所述通过客户端进行消息节点注册的包括如下步骤：S10：客户端注册初始化，向注册请求代理服务发送注册请求；

S20：注册请求代理服务接收客户端的注册请求；

S21：注册请求代理服务将新的客户端均衡分配到SocketIO服务节点；

S30：SocketIO服务节点进行会话注册；

S31：若注册失败，返回步骤S20注册请求代理服务，注册请求代理会将错误原路返回给客户端；

S32：若注册成功，SocketIO服务节点为客户端创建身份令牌，并通过HTTP协议最终回应给客户端；

S40：客户端获取到注册成功的令牌，注册完成。

3.根据权利要求2所述支撑互联网问诊服务的集群式即时消息实现的方法，其特征在于，所述通过客户端进行消息节点注册的具体包括如下步骤：S10：客户端注册初始化

客户端要进行即时消息通讯，需要进行服务节点的注册初始化；注册初始化的流程中客户端通过HTTP协议之上的WebSocket协议，通过向注册代理服务发送注册请求，建立与SocketIO服务节点的连接资源；

S20：注册请求代理服务接收客户端的注册请求，并且进行SocketIO动态分配；

代理服务是一个基于HTTP协议的反向代理服务器组成，其中，Nginx服务可以有效的作为高性能反向代理服务，通过这种两级注册模式，实现一级代理作为客户端请求入口，实现SocketIO集群的调度，SocketIO做为二级集群，提供数百台注册服务子节点的负载；

S21：Nginx服务进行代理的过程是通过负载均衡的分配方式，负载均衡算法是根据Nginx服务提供的最少连接数算法进行均衡负载，优先给连接数最少的SocketIO服务节点注册新的客户端连接；

S30：SocketIO服务节点是以Netty‑SocketIO开源组件为基础，提供了TCP/IP长连接之间的数据通讯；

SocketIO服务节点会话注册步骤：(a)SocketIO服务节点获取注册代理节点发来的客户端注册请求，(b)SocketIO对服务节点的身份证书进行数据库身份鉴权，所述身份鉴权数据会缓存在Redis内存数据库中；

S31：若注册失败返回步骤S20注册请求代理服务，注册请求代理会将错误原路返回给客户端；

S32：若注册成功，SocketIO服务节点为客户端创建身份令牌，作为下次访问的身份授权证书，通过HTTP协议最终回应给客户端；

S40：客户端获取到注册成功的令牌消息后，将令牌保存在自己的本地临时数据库中，当下次进行消息发送的时候，会将令牌和消息一并发送。

4.根据权利要求2或3所述支撑互联网问诊服务的集群式即时消息实现的方法，其特征在于：步骤S40中，所述令牌有过期时间，若令牌超过过期时间后，客户端需要重新注册申请。

5.根据权利要求1所述支撑互联网问诊服务的集群式即时消息实现的方法，其特征在于，消息发送过程中，包括如下步骤：

100:客户端作为发送端，开始健康档案的编号发送；

200:SocketIO注册节点获取到客户端发来的消息；

201:根据200SocketIO注册节点获取的健康档案编号进行医院EHR系统编号查询；

202:对健康档案中患者索引信息、医院EHR透传所需信息进行数据封装；

203:SocketIO服务节点完成对健康档案数据的封装后进行发送准备，并确认在本SocketIO服务节点的注册列表中是否存在接收方客户端；

204:如果确认本SocketIO服务节点的注册列表中有接收方客户端，则将封装后的健康档案数据向接收方客户端直接进行数据传输；

300：接收方客户端接收到健康档案数据，并对健康档案数据进行解析，链接到700:接收方客户端所属的系统中，由EHR系统查询详细信息，并返回给接收方客户端进行详情展示；

205:如果确认本SocketIO服务节点的注册列表中没有接收方客户端，则SocketIO需要进行MQ消息服务中心的通知，SocketIO服务节点从本地获取MQ消息服务中心客户端对象，并将封装好的健康档案Json数据通过MQ消息服务中心对象，向MQ消息服务中心进行数据推送，直到完成；

400:由上205向MQ消息服务中心进行数据推送完成后，MQ消息服务接收到SocketIO推送来的发送方客户端健康档案数据，并加入到通道队列中；MQ消息服务中心不参与业务逻辑的路由转发工作，无差别地对订阅在该消息服务中心的所有SocketIO消息服务节点(推送节点除外)，进行健康档案消息广播；

500:每个订阅MQ消息服务中心健康档案通道的SocketIO消息节点，都将及时获取到MQ消息服务中心轮询推送来的消息，确认正处于本SocketIO服务节点的注册列表中是否有接收方客户端；

501:若SocketIO服务节点的会话列表不存在该接收方客户端，则直接对消息丢弃；

502:若SocketIO服务节点的会话列表存在该接收方客户端，则从注册列表中取出接收方客户端的会话连接，并将封装好的健康档案数据向接收方客户端直接进行数据传输直到完成；

600:向接收方客户端完成健康档案数据传输后，接收方医生客户端就获取到了发送方传来的患者健康档案数据，接收方对健康档案数据进行解析，链接到700:接收方所属的系统中，由EHR系统查询详细信息，并返回给接收方客户端进行详情展示。

6.根据权利要求5所述支撑互联网问诊服务的集群式即时消息实现的方法，其特征在于：步骤400中，每一个订阅该通道的SocketIO消息节点都将轮询接收MQ消息服务中心的健康档案数据推送，直到推送完成。

说明书

一种支撑互联网问诊服务的集群式即时消息系统及其实现

方法

技术领域

[0001] 本发明属于即时通讯技术领域，具体涉及一种支撑互联网问诊服务的集群式即时消息系统及其实现方法。

背景技术

[0002] 即时消息系统是互联网医疗服务的基础需要，医生与患者、医生与医生需要通过一个面向互联网医疗业务特征，即时通讯的消息通知平台，不仅实现文字、图像、文件等通
用信息资料的传递，而且能实现EHR(健康档案)、视频交流、在线处方等第三方医疗业务系
统的整合协作。例如：发送方提供患者健康档案编号给消息服务节点，消息服务节点对EHR
系统进行调用，提取健康档案数据库患者基本信息，并封装成网络可传递的数据包给接收
方，便于接收方快速查阅该数据包中患者的基本信息，数据包最终发送给接收端，接收端会
根据数据包中的数据来源及证书授权实现对方院内EHR系统的访问穿透查询能力，为接收
方客户提供患者详细健康数据调阅能力。那么EHR系统就存在与即时消息系统非常紧密的
业务协作关系，视频交流、在线处方等亦如此。

[0003] 为了满足大规模、高并发的互联网消息传递，大多数即时消息产品都是在标准的互联网TCP/IP网络协议之上，形成一个分布式的网络架构，通过一种应用层Socket通讯协
议，发送方消息在本消息服务节点上路由到接收方消息服务节点，最终到达目的接收端。例
如：Jabber/XMPP协议与架构由IETFXMPP协议(RFC3290)标准化，就是一种比较典型的符合
分布式架构特点的标准即时消息协议，用户名通过Jabber识别符表示([e-mail]
类似邮件格式)，@前半部分表示用户名，@后半部分表示所属的XMPP协议服务器域名，当
[e-mail]用户向[e-mail]用户发送消息，A.com服务节点首先接收到sender发
送来的XML流消息，然后通过网关路由到B.com服务节点，最后B.com将接收到的XML流消息
发送给所属receiver用户，实现完整消息路由传递。整个过程中A.com,B.com两个服务节
点，分别负载了各自庞大的用户群体，实现了真正的分布式网络架构，一方面基于域名分组
的方式满足大规模、高并发的需求，另一方面也实现了不同服务节点之间通过标准协议的
互联互通。

[0004] 面向互联网问诊服务的消息服务不仅要实现通用的信息资料传递，而且还需要紧密结合业务系统，例如：EHR(电子健康档案系统)，视频聊天系统，院内HIS系统等，因此消息
服务节点和业务系统紧密结合度会远远大于普通的即时消息服务器，若消息服务与业务的
耦合度过于紧密，若业务系统出现不可靠因素，就有可能导致消息服务节点的通讯故障，而
互联网医疗问诊服务对系统的可靠性要求极高，因此保护消息服务节点的高可靠性非常关
键。

[0005] 首先基于Jabber/XMPP协议与架构的即时消息系统，是通过Jabber识别符的约定，实现了通过域名分组的形式，满足大规模、高并发的即时消息在互联网消息服务节点间的
传递。但是Jabber识别符的约定虽然巧妙的解决了消息服务节点的扩展，却带来了新的问
题，就是客户端节点必须按照约定的Jabber识别符名称注册到对应域名的消息服务节点
上。一旦对应域名的消息服务节点通讯坏掉，那么就没有办法对所属服务节点下的所有客
户端动态地进行切换到其他服务节点上，除非更换客户端的用户名及所属域，那么在互联
网用户的广泛性上看，这就会带来极高的切换代价。

[0006] 其次服务节点间的消息转移是通过路由的方式，也就是说A.com服务节点是通过TCP/IP建立连接的方式路由到B.com服务节点，那么就形成了(a)A客户端到A.com,(b)
A.com到B.com,(b)B.com到B客户端的TCP通讯三阶段消息通讯链，同理我们可以得出，C客
户端、D客户端、E客户端……，都是按照此模式由所属的服务节点通过路由的方式和其他服
务节点进行消息传递。当网络中出现A、C、D、E……等服务节点同时向B服务节点传递消息的
情况时，那么B服务节点将成为巨大的压力点，一旦突发这种情况，B服务点就可能会因为压
力出现缓慢甚至崩溃，导致整个网络的通讯异常。而且XMPP协议传递的是XML流数据格式，
对网络带宽占用大，DOM组装和解包处理比较慢，也增加了服务节点的压力。

发明内容

[0007] 本发明的目的在于提供一种支撑互联网问诊服务的集群式即时消息系统及其实现方法，以解决现有技术中存在的问题。

[0008] 本发明的实现过程如下：

[0009] 一种支撑互联网问诊服务的集群式即时消息实现的方法，包括：

[0010] 通过客户端进行消息节点注册，通过SocketIO服务节点的注册请求，生成临时的、动态的令牌，由SocketIO服务端对客户端拿到的临时令牌进行令牌有效性的控制；

[0011] 发送方通过消息节点通讯将消息发送到SocketIO服务节点时，SocketIO服务节点会对消息的类型进行遍历，建立观察者模式，通过图文消息监听对象，实现与图像存储系统
的对接；通过视频消息监听对象，实现与视频服务系统的对接；通过健康档案消息监听对
象，实现与EHR系统对接；通过处方消息监听对象，实现与HIS系统对象；

[0012] 接收方不在发送方SocketIO消息节点会话内，将在SocketIO消息节点集群广播，如果接收方不在自己的会话内就丢弃，如果接收方在会话内找到就进行SocketIO服务节点
与业务节点之间的消息通知、业务交互、结果封装及结果消息发送接收端。

[0013] 上述支撑互联网问诊服务的集群式即时消息实现的方法，所述通过客户端进行消息节点注册的包括如下步骤：

[0014] S10：客户端注册初始化，向注册请求代理服务发送注册请求；

[0015] S20：注册请求代理服务接收客户端的注册请求；

[0016] S21：注册请求代理服务将新的客户端均衡分配到SocketIO服务节点；

[0017] S30：SocketIO服务节点进行会话注册；

[0018] S31：若注册失败，返回步骤S20注册请求代理服务，注册请求代理会将错误原路返回给客户端；

[0019] S32：若注册成功，SocketIO服务节点为客户端创建身份令牌，并通过HTTP协议最终回应给客户端；

[0020] S40：客户端获取到注册成功的令牌，注册完成。

[0021] 上述支撑互联网问诊服务的集群式即时消息实现的方法，所述通过客户端进行消息节点注册的具体包括如下步骤：

[0022] S10：客户端注册初始化

[0023] 客户端要进行即时消息通讯，需要进行服务节点的注册初始化；注册初始化的流程中客户端通过HTTP协议之上的WebSocket协议，通过向注册代理服务发送注册请求，建立
与SocketIO服务节点的连接资源；

[0024] S20：注册请求代理服务接收客户端的注册请求，并且进行SocketIO动态分配；

[0025] 代理服务是一个基于HTTP协议的反向代理服务器组成，其中，Nginx服务可以有效的作为高性能反向代理服务，通过这种两级注册模式，实现一级代理作为客户端请求入口，
实现SocketIO集群的调度，SocketIO做为二级集群，提供数百台注册服务子节点的负载；

[0026] S21：Nginx服务进行代理的过程是通过负载均衡的分配方式，负载均衡算法是根据Nginx服务提供的最少连接数算法进行均衡负载，优先给连接数最少的SocketIO服务节
点注册新的客户端连接；

[0027] S30：SocketIO服务节点是以Netty‑SocketIO开源组件为基础，提供了TCP/IP长连接之间的数据通讯；

[0028] SocketIO服务节点会话注册步骤：(a)SocketIO服务节点获取注册代理节点发来的客户端注册请求，(b)SocketIO对服务节点的身份证书进行数据库身份鉴权，所述身份鉴
权数据会缓存在Redis内存数据库中；

[0029] S31：若注册失败返回步骤S20注册请求代理服务，注册请求代理会将错误原路返回给客户端；

[0030] S32：若注册成功，SocketIO服务节点为客户端创建身份令牌，作为下次访问的身份授权证书，通过HTTP协议最终回应给客户端；

[0031] S40：客户端获取到注册成功的令牌消息后，将令牌保存在自己的本地临时数据库中，当下次进行消息发送的时候，会将令牌和消息一并发送。

[0032] 上述支撑互联网问诊服务的集群式即时消息实现的方法，步骤S40中，所述令牌有过期时间，若令牌超过过期时间后，客户端需要重新注册申请。

[0033] 上述支撑互联网问诊服务的集群式即时消息实现的方法，消息发送过程中，包括如下步骤：

[0034] 100:客户端作为发送端，开始健康档案的编号发送；

[0035] 200:SocketIO注册节点获取到客户端发来的消息；

[0036] 201:根据200SocketIO注册节点获取的健康档案编号进行医院EHR系统编号查询；

[0037] 202:对健康档案中患者索引信息、医院EHR透传所需信息进行数据封装；

[0038] 203:SocketIO服务节点完成对健康档案数据的封装后进行发送准备，并确认在本SocketIO服务节点的注册列表中是否存在接收方客户端；

[0039] 204:如果确认本SocketIO服务节点的注册列表中有接收方客户端，则将封装后的健康档案数据向接收方客户端直接进行数据传输；

[0040] 300：接收方客户端接收到健康档案数据，并对健康档案数据进行解析，链接到700:接收方客户端所属的系统中，由EHR系统查询详细信息，并返回给接收方客户端进行详
情展示；

[0041] 205:如果确认本SocketIO服务节点的注册列表中没有接收方客户端，则SocketIO需要进行MQ消息服务中心的通知，SocketIO服务节点从本地获取MQ消息服务中心客户端对
象，并将封装好的健康档案Json数据通过MQ消息服务中心对象，向MQ消息服务中心进行数
据推送，直到完成；

[0042] 400:向MQ消息服务中心进行数据推送完成后，MQ消息服务接收到SocketIO推送来的发送方客户端健康档案数据，并加入到通道队列中，MQ消息服务中心对订阅在该消息服
务中心的所有SocketIO消息服务节点，进行健康档案消息广播；

[0043] 500:每个订阅MQ消息服务中心健康档案通道的SocketIO消息节点，都将及时获取到MQ消息服务中心轮询推送来的消息，确认正处于本SocketIO服务节点的注册列表中是否
有接收方客户端；

[0044] 501:若SocketIO服务节点的会话列表不存在该接收方客户端，则直接对消息丢弃；

[0045] 502:若SocketIO服务节点的会话列表存在该接收方客户端，则从注册列表中取出接收方客户端的会话连接，并将封装好的健康档案数据向接收方客户端直接进行数据传输
直到完成；

[0046] 600:向接收方客户端完成健康档案数据传输后，接收方医生客户端就获取到了发送方传来的患者健康档案数据，接收方对健康档案数据进行解析，链接到700:接收方所属
的系统中，由EHR系统查询详细信息，并返回给接收方客户端进行详情展示。

[0047] 上述支撑互联网问诊服务的集群式即时消息实现的方法，步骤400中，每一个订阅该通道的SocketIO消息节点都将轮询接收MQ消息服务中心的健康档案数据推送，直到推送
完成。

[0048] 上述支撑互联网问诊服务的集群式即时消息实现的方法，

[0049] (a)客户端向SocketIO服务节点发送请求消息，请求消息中包括了消息的类型；

[0050] (b)SocketIO服务节点从监听对象列表中进行消息遍历，监听对象包括：图像消息监听、视频聊天消息监听、健康档案消息监听、处方消息监听，若该消息类型匹配该监听器，
则SocketIO服务节点对匹配的监听器实施线程异步，保证主服务继续处理其他消息请求，
不会被监听器与外部服务或系统的交互中所阻塞，实现主消息处理与业务处理的彻底解
耦；

[0051] (c)图像消息监听与图像存储服务形成交互，主要上传图像到图像存储服务，并获取封装图像下载地址；视频聊天消息监听与视频聊天服务形成交互，主要进行通知、建立连
接、销毁中点对点的视频聊天的消息通讯，并封装视频会话状态数据；健康档案消息监听与
健康档案系统交互，根据患者编号查询并封装健康档案索引数据和透传来源信息；处方消
息监听与院内HIS系统交互，根据处方号，查询并获取处方数据；封装后的业务消息数据加
入到主消息服务线程异步处理的封装数据队列事件中，交给主消息服务进行封装数据的出
队处理；形成主消息封装与业务数据封装彻底解耦；

[0052] (d)SocketIO服务节点若在本服务节点找到接收方的会话，将结果消息直接发送给接收方客户端，若未找到，则直接将请求消息在不经过任何处理的状态下直接推送给MQ
消息转发中心，并对所有订阅该通道的消息服务节点集群进行广播，找到接收方会话的广
播服务节点，同样进行消息事件通知和消息结果封装，同样将结果消息直接发送给接收方
客户端，未找到广播服务节点直接废弃请求消息，通过MQ广播模式，形成集群各个节点间的
通讯与消息路由彻底解耦。

[0053] 一种支撑互联网问诊服务的集群式即时消息系统，包括消息节点注册模块、消息节点通讯模块和消息节点业务集成模块；

[0054] 所述消息节点注册模块由节点代理服务模块和客户端授权模块构成；

[0055] 所述消息节点通讯模块由节点通讯模块和会话管理模块构成；

[0056] 所述消息节点业务集成模块由业务适配模块和业务协同模块构成。

[0057] 进一步，所述节点代理服务模块由均衡分配模块和节点管理模块构成；所述客户端授权模块由客户端令牌模块和客户端认证模块构成；

[0058] 所述节点通讯模块由消息引擎模块和MQ消息中心模块构成；所述会话管理模块由客户端加入模块和客户端退出模块构成；

[0059] 业务适配模块由第三方集成模块和消息注册监听模块构成；所述业务协同模块由消息事件通知模块和业务调用封装模块构成。

[0060] 进一步，所述均衡分配模块采用最少网络连接算法进行分配；所述节点管理模块包括加入动态检测模块和宕机动态检测模块；

[0061] 所述消息引擎模块包括消息接收模块、消息发送模块和消息过滤模块；所述MQ消息中心模块包括消息订阅模块、消息推送模块和消息广播模块；

[0062] 所述第三方集成模块包括视频通话服务模块、图像储存服务模块、健康档案系统和院内HIS系统。

[0063] 本发明的关键点：

[0064] Jabber/XMPP协议需要客户端去耦合命名约定，也就是对客户端账号的命名进行了规定，尤其是用户名和域名进行了绑定，这就产生了客户端对于域名的锁死。本发明中通
过SocketIO服务节点的注册请求，生成临时的、动态的令牌，形成用户名和及时消息客户端
标示进行了分离，那么用户名由业务系统定义，将不再受即时消息系统的约束。

[0065] 客户端拿到的临时令牌，在SocketIO的注册会话列表也保存一份，每次请求需要通过Hash集合中快速的匹配令牌的有效性，就可以由SocketIO服务端进行令牌有效性的控
制，提升整体访问的安全性。

[0066] 注册代理根据Nginx的动态负载，根据最少连接数均衡算法，让注册客户端由注册中心自动均匀的分配给每个SocketIO服务节点，这就优于Jabber架构需要客户端手动指定
注册到那个消息服务上，会变得资源无法达到最优配置。同时本专利客户端可以形成动态
重连机制，即便是正连接到SocketIO消息服务宕机了，客户端也能自动得重新选择新的
SocketIO服务节点。

[0067] 发送方将消息发送到SocketIO服务节点时，会对消息的类型进行遍历，判断属于图文消息、视频消息、健康档案消息、处方消息等，针对不同的消息类似，建立观察者模式，
通过图文消息监听对象，实现与图像存储系统的对接；通过视频消息监听对象，实现与视频
服务系统的对接；通过健康档案消息监听对象，实现与EHR系统对接；通过处方消息监听对
象，实现与HIS系统对象。这样面向医疗问诊的强侵入业务需求，会通过遍历消息类型的事
件监听机制，将SocketIO服务节点处理消息的机制与医疗问诊等业务系统交互进行了彻底
的解耦。

[0068] 接收方不在发送方SocketIO消息节点会话内，将通过MQ消息中心广播的形式，在SocketIO消息节点集群广播，只要接收方不在自己的会话内就丢弃，一旦在会话内找到就
进行SocketIO服务节点与业务节点之间的消息通知、业务交互、结果封装及结果消息发送
接收端，这样就可以让集群各个节点间的通讯与消息路由彻底解耦。

[0069] 本发明的积极效果：

[0070] 采用上述互联网问诊服务的集群式即时消息系统及方法，对比标准的Jabber/XMPP架构与协议有着很大的优势，首先客户端不再受到命名约束，而且可以自动化的动态
注册到集群任意消息服务，极大的保证了客户端的即时消息使用的高可靠性；其次基于网
络连接数的均衡负载算法，比手动域名配置来看，最大化利用好集群中每个节点的资源，并
且可以具备更好的动态伸缩性，实现更大规模的即时消息吞吐压力，最后MQ消息中心广播
的模式，不仅降低了每个消息节点的路由压力，而且MQ队列的模式，防止了某个消息节点出
现的突然骤然升高的并发压力，当出现突然的峰值情况，完全可以通过队列处理的一定延
时来防止消息节点崩溃。

[0071] 从系统解耦的效果看也非常具有优势，首先是客户端注册解耦，通过注册代理的均衡负载机制，让客户端注册在集群的哪一个消息节点上彻底的解耦，那么客户端对能更
加简单动态的注册、切换、销毁与消息集群的连接，加强客户端的高可靠和体验；其次是医
疗业务解耦，通过异步事件监听机制和业务交互让消息节点的主消息处理与业务交互之间
彻底解耦，增强了主消息服务的健壮性、鲁棒性，通过主消息封装与业务交互数据封装的彻
底解耦，让消息模型和业务模型不会产生紧耦合，不仅增强了业务的可靠性，而且可以更容
易的在消息服务基础之上增加更多的业务交互机制，打造更符合医疗业务需要的即时消息
基础设施平台；最后通过MQ消息中心对消息服务的推送、订阅、广播的支持，实现了消息服
务之间的路由解耦，消息服务可以在不需要知道其他集群节点状态的情况下更容易的加入
和销毁，极大的加强了集群的伸缩性和灵活性。

附图说明

[0072] 图1是本发明实施例中客户端注册即时通讯服务节点流程图；

[0073] 图2是本发明实施例中健康档案消息为例的消息发送流程图；

[0074] 图3是本发明实施例中业务解耦示意图；

[0075] 图4是本发明所述支撑互联网问诊服务的集群式即时消息系统的模块图。

具体实施方式

[0076] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于
本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他
实施例，都属于本发明保护的范围。

[0077] 实施例1

[0078] 图1是客户端注册即时通讯服务节点流程图。该方法包括：

[0079] S10：客户端注册初始化

[0080] 客户端要进行即时消息通讯，首先需要进行服务节点的注册初始化。

[0081] 该流程中客户端通过HTTP协议之上的WebSocket协议，通过向注册代理服务发送注册请求，建立与SocketIO服务节点的连接资源。

[0082] SocketIO服务节点为客户端建立与其他客户端的消息通讯交互，因此初始化过程中，需要通过代理动态的寻找一个SocketIO服务节点进行注册。

[0083] S20：注册请求代理接收客户端的注册请求，并且进行SocketIO动态分配。

[0084] 代理服务是一个基于HTTP协议的反向代理服务器组成，例如：Nginx服务可以有效的作为高性能反向代理服务，通过这种两级注册模式，实现一级代理作为客户端请求入口，
实现SocketIO集群的调度，SocketIO做为二级集群，提供数百台注册服务子节点的负载。

[0085] 例如：服务器配置在单机8核64GB的情况下，Nginx代理可以承载平均单机十万连接并负载到10台SocketIO服务节点，等同于提供100万用户的长时间注册活跃连接的消息
活动。

[0086] S21：Nginx代理进行代理的过程是通过负载均衡的分配方式，负载均衡算法是根据Nginx提供的最少连接数算法进行均衡负载，优先给连接数最少的SocketIO服务节点注
册新的客户端连接。

[0087] S30：SocketIO服务节点是以Netty‑SocketIO开源组件为基础，提供了高性能、端到端的TCP/IP长连接之间的数据通讯。

[0088] 注册步骤：(a)SocketIO服务节点获取注册代理节点发来的客户端注册请求，(b)SocketIO对服务节点的身份证书进行数据库身份鉴权(一般会缓存在Redis内存数据库
中)。

[0089] S31若注册失败返回注册请求代理，代理会将错误原路返回给客户端。

[0090] S32若注册成功，Socket服务节点，为客户端创建身份令牌，作为下次访问的身份授权证书，通过HTTP，最终回应给客户端。

[0091] S40客户端获取到注册成功的令牌消息后，将令牌保存在自己的本地临时数据库中，当下次进行消息发送的时候，会将令牌和消息一并发送；

[0092] 另外令牌也有过期时间，若令牌超过过期时间后，客户端需要重新注册申请。

[0093] 图2是以传输健康档案消息为例的消息发送流程图。该流程图是本专利中最重要的技术流程说明。

[0094] 100:客户端作为发送端，开始健康档案的编号发送。

[0095] 例如：医生和医生之间进行即时消息沟通的过程中，其中一方医生需要发起向另一方的医生进行患者情况咨询的时候，需要将自己的患者信息分享给对方，通过即时消息
的传递是最简单和便捷的办法。

[0096] 步骤(a)咨询医生通过客户端应用系统查找到自己的患者，(b)咨询医生选择该患者向对方医生的聊天窗口点击发送，这个过程中系统就能根据选择的患者，获取到患者的
系统编号；(c)系统编号、注册令牌、消息类型、发送方编号、接收方编号会被封装成一个消
息体，以Json格式作为互联网传输的媒介格式，并通过HttpRest请求形式发送给SocketIO
注册节点。

[0097] 200:SocketIO注册节点获取到咨询医生客户端发来的消息并进行处理。

[0098] 步骤：首先从客户端的Json数据中提取注册令牌，进行身份认证，确定无误后进行下一步处理，从客户端发送来的Json数据中提取发送方医生的编号，从数据库中确定该医
生所属医院；

[0099] 首先201:从客户端发送来的Json数据中提取患者编号，根据患者编号和医生所属医院，进行医院EHR系统的患者健康档案索引数据获取，包括患者姓名、性别、身份证、最近
一次就诊记录、常见病标示等能描述清楚患者整体轮廓的基本信息；

[0100] 其次202:对患者索引信息、医院EHR透传所需信息进行Json数据封装，形成患者基本信息和来源的消息打包；

[0101] 再次203:SocketIO服务节点完成对健康档案数据的封装后进行发送准备，从客户端发送来的Json数据中提取接收方的编号，并且需要在本SocketIO服务节点的会话列表
中，对发送端客户端进行查找匹配，确认在本SocketIO服务节点的注册列表中是否存在接
收方客户端。

[0102] 再次204:如果确认本SocketIO服务节点的注册列表中有接收方客户端，则从注册列表中取出接收方客户端的会话连接，并将封装好的健康档案Json数据通过SocketIO连接
对象，向接收方客户端直接进行数据传输，直到完成。

[0103] 最后205:如果确认本SocketIO服务节点的注册列表中没有该客户端，则SocketIO需要进行MQ消息服务中心的通知，SocketIO服务节点从本地获取MQ消息服务中心客户端对
象，并将封装好的健康档案Json数据通过MQ消息服务中心对象，向MQ消息服务中心进行数
据推送，直到完成。

[0104] 300：由上204向接收方客户端完成健康档案数据传输后，接收方医生客户端就获取到了发送方传来的患者健康档案数据，接收方对健康档案Json数据进行解析，首先客户
端系统的展示上可以看到患者最基本的个人基本情况和健康信息，若需要进一步掌握患者
的个人健康情况，就需要通过链接的方式，从健康档案Json数据中解析出数据来源，包括了
所属医院EHR系统地址，EHR系统访问证书等一些列EHR透传信息，通过透传访问的形式，链
接到700:接收方所属医院的系统中，由EHR系统查询该患者的详细健康数据，并返回给接收
方客户端进行详情展示。

[0105] 400:由上205向MQ消息服务中心进行数据推送完成后，MQ消息服务接收到SocketIO推送来的发送方客户端健康档案数据，并加入到通道队列中。MQ消息服务中心不
参与业务逻辑的路由转发工作，无差别地对订阅在该消息服务中心的所有SocketIO消息服
务节点(推送节点除外)，进行健康档案消息广播。每一个订阅该通道的SocketIO消息节点
都将轮询接收MQ消息服务中心的健康档案数据推送，直到推送完成。

[0106] 500:每个订阅MQ消息服务中心健康档案通道的SocketIO消息节点，都将及时获取到MQ消息服务中心轮询推送来的消息。

[0107] 步骤：首先要进行健康档案消息Json数据的接收端编号提取，确认正处于本SocketIO服务节点的注册列表中是否有接收方客户端。

[0108] 其次501:若SocketIO服务节点的会话列表不存在该接受客户端，则直接对消息丢弃后。

[0109] 最后502:若SocketIO服务节点的会话列表存在该接受客户端，则从注册列表中取出接收方客户端的会话连接，并将封装好的健康档案Json数据通过SocketIO服务节点连接
对象，向接收方客户端直接进行数据传输直到完成；

[0110] 600:由上502向接收方客户端完成健康档案数据传输后，接收方医生客户端就获取到了发送方传来的患者健康档案数据，接收方对健康档案Json数据进行解析，首先客户
端系统的展示上可以看到患者最基本的个人基本情况和健康信息，若需要进一步掌握患者
的个人健康情况，就需要通过链接的方式，从健康档案Json数据中解析出数据来源，包括了
所属医院EHR系统地址，EHR系统访问证书等一些列EHR透传信息，通过透传访问的形式，链
接到700:接收方所属医院的系统中，由EHR系统查询该患者的详细健康数据，并返回给接收
方客户端进行详情展示。

[0111] 消息与业务解耦步骤如图3所示：

[0112] (a)客户端(SocketIO Cliet)向SocketIO服务节点(SocketIOSever)发送请求消息，请求消息中包括了消息的类型；

[0113] (b)SocketIOServer从监听对象列表中进行消息遍历，包括：PictureListener(图像消息监听)、VideoChatListener(视频聊天消息监听)、EHR Listener(健康档案消息监
听)、HISListener(处方消息监听)，若该消息类型匹配该监听器，则SocketIOServer对匹配
的监听器实施线程异步，保证主服务继续处理其他消息请求，不会被监听器与外部服务或
系统的交互中所阻塞，实现主消息处理与业务处理的彻底解耦；

[0114] (c)PictureListener与ImagestorageServer(图像存储服务)形成交互，主要上传图像到图像存储服务，并获取封装图像下载地址；VideoChatListener与VideoChatServer
(视频聊天服务)形成交互，主要进行通知、建立连接、销毁等点对点的视频聊天的消息通
讯，并封装视频会话状态数据；EHR Listener与EHR System(健康档案系统)交互，根据患者
编号查询并封装健康档案索引数据和透传来源信息；HISListener与HISSystem(院内HIS系
统)交互，根据处方号，查询并获取处方数据。封装后的业务消息数据加入到主消息服务线
程异步处理的封装数据队列事件中，交给主消息服务进行封装数据的出队处理；形成主消
息封装与业务数据封装彻底解耦。

[0115] (d)SocketIOServer若在本服务节点找到接收方的会话，将结果消息直接发送给SocketIOclient(接收端)，若未找到，则直接将请求消息在不经过任何处理的状态下直接
推送给MQ消息转发中心，并对所有订阅该通道的ServerIOServerCluster(消息服务节点集
群)进行广播，找到接收方会话的广播服务节点，同样进行消息事件通知和消息结果封装，
同样将结果消息直接发送给SocketIOclient，未找到广播服务节点直接废弃请求消息。通
过MQ广播模式，形成集群各个节点间的通讯与消息路由彻底解耦。

[0116] (2)本发明的关键点

[0117] Jabber/XMPP协议需要客户端去耦合命名约定，也就是对客户端账号的命名进行了规定，尤其是用户名和域名进行了绑定，这就产生了客户端对于域名的锁死。本发明中通
过SocketIO服务节点的注册请求，生成临时的、动态的令牌，形成用户名和及时消息客户端
标示进行了分离，那么用户名由业务系统定义，将不再受即时消息系统的约束。

[0118] 客户端拿到的临时令牌，在SocketIO的注册会话列表也保存一份，每次请求需要通过Hash集合中快速的匹配令牌的有效性，就可以由SocketIO服务端进行令牌有效性的控
制，提升整体访问的安全性。

[0119] 注册代理根据Nginx的动态负载，根据最少连接数均衡算法，让注册客户端由注册中心自动均匀的分配给每个SocketIO服务节点，这就优于Jabber架构需要客户端手动指定
注册到那个消息服务上，会变得资源无法达到最优配置。同时本专利客户端可以形成动态
重连机制，即便是正连接到SocketIO消息服务宕机了，客户端也能自动得重新选择新的
SocketIO服务节点。

[0120] 发送方将消息发送到SocketIO服务节点时，会对消息的类型进行遍历，判断属于图文消息、视频消息、健康档案消息、处方消息等，针对不同的消息类似，建立观察者模式，
通过图文消息监听对象，实现与图像存储系统的对接；通过视频消息监听对象，实现与视频
服务系统的对接；通过健康档案消息监听对象，实现与EHR系统对接；通过处方消息监听对
象，实现与HIS系统对象。这样面向医疗问诊的强侵入业务需求，会通过遍历消息类型的事
件监听机制，将SocketIO服务节点处理消息的机制与医疗问诊等业务系统交互进行了彻底
的解耦。

[0121] 接收方不在发送方SocketIO消息节点会话内，将通过MQ消息中心广播的形式，在SocketIO消息节点集群广播，只要接收方不在自己的会话内就丢弃，一旦在会话内找到就
进行SocketIO服务节点与业务节点之间的消息通知、业务交互、结果封装及结果消息发送
接收端，这样就可以让集群各个节点间的通讯与消息路由彻底解耦。

[0122] 实施例2

[0123] 本实施例所述支撑互联网问诊服务的集群式即时消息系统，见图4，包括消息节点注册模块、消息节点通讯模块和消息节点业务集成模块；所述消息节点注册模块由节点代
理服务模块和客户端授权模块构成；所述消息节点通讯模块由节点通讯模块和会话管理模
块构成；所述消息节点业务集成模块由业务适配模块和业务协同模块构成。

[0124] 进一步，所述节点代理服务模块由均衡分配模块和节点管理模块构成；所述客户端授权模块由客户端令牌模块和客户端认证模块构成；

[0125] 所述节点通讯模块由消息引擎模块和MQ消息中心模块构成；所述会话管理模块由客户端加入模块和客户端退出模块构成；

[0126] 业务适配模块由第三方集成模块和消息注册监听模块构成；所述业务协同模块由消息事件通知模块和业务调用封装模块构成。

[0127] 进一步，所述均衡分配模块采用最少网络连接算法进行分配；所述节点管理模块包括加入动态检测模块和宕机动态检测模块；

[0128] 所述消息引擎模块包括消息接收模块、消息发送模块和消息过滤模块；所述MQ消息中心模块包括消息订阅模块、消息推送模块和消息广播模块；

[0129] 所述第三方集成模块包括视频通话服务模块、图像储存服务模块、健康档案系统和院内HIS系统。

[0130] 综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的
保护范围之内。