一种面向微服务架构的消息传输系统及其方法

摘要

本发明提出了一种面向微服务架构的消息传输系统及其方法，该系统包括服务端和客户端，其中客户端与微服务集成，用于向服务端发送需向其他客户端同步的消息，并接收服务端同步的来自其他客户端的消息；所述服务端独立部署，用于接收客户端发送消息，并根据通讯方式将消息传输到目标客户端；所述服务端和客户端均采用基于任务链的并行处理方式实现对传输消息的处理。本发明引入服务化架构理念，将数据阶段处理封装为任务，多个任务灵活组装为任务链，方便拓展数据路由规则，能够在大规模微服务节点间进行快速的消息同步。

权利要求

1.一种面向微服务架构的消息传输系统，其特征在于，包括服务端和客户端，其中客户端与微服务集成，用于向服务端发送需向其他客户端同步的消息，并接收服务端同步的来自其他客户端的消息；所述服务端独立部署，用于接收客户端发送消息，并根据通讯方式将消息传输到目标客户端；所述服务端和客户端均采用基于任务链的并行处理方式实现对传输消息的处理；将传输消息实体拆分并封装为自定义的帧结构作为最小传输单元，封装的传输消息实体包括一个头帧和若干个续帧；

所述头帧包括传输过程中的控制信息，由帧头和帧体组成，帧头包括帧体长度、数据帧类型、标志位、数据唯一标识、保留位；帧体包括传输数据长度、传输数据类型、加密方式、压缩方式、序列化编码方式、是否持久化标志、通信方式、发送端编号、接收端编号和数据校验信息，其中数据帧类型包括头帧类型、续帧类型，数据唯一标识定义帧数据是否属于同一个消息实体；传输数据类型包括字节类型、字符串类型、文件类型；通信方式包括单播、组播和广播；

所述续帧包括传输消息实体，由帧头和帧体组成，帧头包括帧体长度、数据帧类型、标志位、数据唯一标识、保留位；帧体包括消息实体；

所述服务端和客户端基于任务链的并行处理方式实现对传输消息的处理，具体是将消息处理过程划分为阶段子任务，将子任务组装为并行处理的任务链，支持同时开启多条任务链；

所述服务端通过传输组的方式组织客户端，支持单播、组播和广播三种通信方式；

所述客户端实时向服务端报送心跳，服务端管理各传输组中的所有客户端的编号、状态和数据索引信息；

如果服务端在超时时间内未收到客户端的心跳，则认定该客户端失联，将该客户端标记为失联状态，并将传输组内维护的客户端状态标记为失联状态；

如果服务端重新接收到客户端的心跳，则将客户端标记为在线状态，并将传输组内维护的客户端状态标记为在线状态；

如果服务端在指定时间间隔内始终未能接收到客户端的心跳，则将移除该客户端，并在传输组中删除该客户端信息。

2.根据权利要求1所述的面向微服务架构的消息传输系统，其特征在于，所述服务端针对来自同一客户端的消息，采用同一条任务链进行处理。

3.根据权利要求1或2所述的面向微服务架构的消息传输系统，其特征在于，所述任务链包括服务端消息接收校验分发任务链、客户端消息接收任务链和客户端消息发送任务链，其中：

服务端消息接收校验分发任务链包括4个子任务，其中子任务1用于消息接收、控制信息获取和数据校验，子任务2用于消息持久化，子任务3用于获取需转发的客户端编号，子任务4用于消息发送；

客户端消息接收任务链包括4个子任务，其中子任务1用于消息接收、控制信息获取和数据校验，子任务2用于数据解密，子任务3用于数据解压，子任务4用于数据反序列化；

客户端消息接收任务链包括4个子任务，其中子任务1用于接收微服务提供的消息、控制信息并对消息进行序列化，子任务2用于数据压，子任务3用于数据加密，子任务4用于数据封装和发送。

4.根据权利要求3所述的面向微服务架构的消息传输系统，其特征在于，所述服务端采用嵌入式数据库RocksDB对需要持久化的消息进行入库处理，具体方法为：将消息封装成日志对象，并提交至日志预处理任务队列；

从日志预处理任务队列批量获取日志对象，检查并按顺序为日志对象设置索引，然后将日志对象写入内存缓存，同时，将日志对象提交至持久化任务队列；

从持久化任务队列中批量获取日志对象，按索引顺序将日志对象写入嵌入式数据库RocksDB，入库成功后通知后续任务可以进行相关数据的转发，并删除内存缓存中的相关日志对象。

5.根据权利要求1所述的面向微服务架构的消息传输系统，其特征在于，所述客户端加入指定传输组时，服务端自发向该客户端同步该传输组内传输的历史消息；

所述客户端断线重连时，服务端以客户端最后接收成功的数据索引为依据，自发向该客户端同步断线期间未能正常同步的历史消息；

同时，所述服务端向客户端进行历史消息传输时，将暂时阻塞向该客户端传输增量信息的过程，当历史数据传输完毕后，再进行增量信息传输。

6.一种面向微服务架构的消息传输方法，其特征在于，基于权利要求1‑5任一项所述的系统实现面向微服务架构的消息传输，包括：客户端向服务端发送需向其他客户端同步的消息，并接收服务端同步的来自其他客户端的消息；

服务端接收客户端发送消息，并根据通讯方式将消息传输到目标客户端；

所述服务端和客户端均采用基于任务链的并行处理方式实现对传输消息的处理。

说明书

一种面向微服务架构的消息传输系统及其方法

技术领域

[0001] 本发明涉及计算机信息技术领域，具体涉及一种面向微服务架构的消息传输系统及其方法。

背景技术

[0002] 微服务架构作为一种系统架构，通过功能细分，将应用系统拆分为多个独立运行的微小化的服务，服务之间采用轻量化的消息传输方式完成通信过程。由于服务数量众多、
服务结构各异、服务间的通讯方式多样等问题，使得微服务之间的消息传输面临较大的瓶
颈。例如，微服务消息传输可能存在一对一、一对多和多对多等多种通讯方式的传输场景，
且通讯方式在传输过程中可能会根据实际需要而动态改变。此外，微服务在网络环境中进
行消息传输时需解决诸多问题，如节点断线重连时的消息同步问题；大量消息传输过程中
的数据一致性问题；接收消息失真、超时情况下的重传问题；以及敏感消息加密传输问题
等。这对微服务架构下消息传输的稳定性、可靠性提出了较高的要求。因此，如何满足微服
务架构下消息传输的多样化的场景需求，突破微服务之间消息传输的结构瓶颈，提高消息
传输的稳定性与可靠性，是微服务架构亟待解决的问题。

发明内容

[0003] 本发明的目的在于提供一种面向微服务架构的消息传输系统及其方法，用于解决微服务架构下的消息传输问题。

[0004] 实现本发明目的的技术解决方案为：一种面向微服务架构的消息传输系统，包括服务端和客户端，其中客户端与微服务集成，用于向服务端发送需向其他客户端同步的消
息，并接收服务端同步的来自其他客户端的消息；所述服务端独立部署，用于接收客户端发
送消息，并根据通讯方式将消息传输到目标客户端；所述服务端和客户端均采用基于任务
链的并行处理方式实现对传输消息的处理。

[0005] 进一步的，将传输消息实体拆分并封装为自定义的帧结构作为最小传输单元，封装的传输消息实体包括一个头帧和若干个续帧；

[0006] 所述头帧包括传输过程中的控制信息，由帧头和帧体组成，帧头包括帧体长度、数据帧类型、标志位、数据唯一标识、保留位；帧体包括传输数据长度、传输数据类型、加密方
式、压缩方式、序列化编码方式、是否持久化标志、通信方式、发送端编号、接收端编号和数
据校验信息，其中数据帧类型包括头帧类型、续帧类型，数据唯一标识定义帧数据是否属于
同一个消息实体；传输数据类型包括字节类型、字符串类型、文件类型；通信方式包括单播、
组播和广播；

[0007] 所述续帧包括传输消息实体，由帧头和帧体组成，帧头包括帧体长度、数据帧类型、标志位、数据唯一标识、保留位；帧体包括消息实体。

[0008] 进一步的，所述服务端和客户端基于任务链的并行处理方式实现对传输消息的处理，具体是将消息处理过程划分为阶段子任务，将子任务组装为并行处理的“任务链”，支持
同时开启多条“任务链”。

[0009] 更进一步的，所述服务端针对来自同一客户端的消息，采用同一条“任务链”进行处理。

[0010] 更进一步的，所述任务链包括服务端消息接收校验分发任务链、客户端消息接收任务链和客户端消息发送任务链，其中：

[0011] 服务端消息接收校验分发任务链包括4个子任务，其中子任务1用于消息接收、控制信息获取和数据校验，子任务2用于消息持久化，子任务3用于获取需转发的客户端编号，
子任务4用于消息发送；

[0012] 客户端消息接收任务链包括4个子任务，其中子任务1用于消息接收、控制信息获取和数据校验，子任务2用于数据解密，子任务3用于数据解压，子任务4用于数据反序列化；

[0013] 客户端消息接收任务链包括4个子任务，其中子任务1用于接收微服务提供的消息、控制信息并对消息进行序列化，子任务2用于数据压，子任务3用于数据加密，子任务4用
于数据封装和发送。

[0014] 更进一步的，所述服务端采用嵌入式数据库RocksDB对需要持久化的消息进行入库处理，具体方法为：

[0015] 将消息封装成日志对象，并提交至日志预处理任务队列；

[0016] 从日志预处理任务队列批量获取日志对象，检查并按顺序为日志对象设置索引，然后将日志对象写入内存缓存，同时，将日志对象提交至持久化任务队列；

[0017] 从持久化任务队列中批量获取日志对象，按索引顺序将日志对象写入嵌入式数据库RocksDB，入库成功后通知后续任务可以进行相关数据的转发，并删除内存缓存中的相关
日志对象。

[0018] 进一步的，所述服务端通过传输组的方式组织客户端，支持单播、组播和广播三种通信方式。

[0019] 进一步的，所述客户端实时向服务端报送心跳，服务端管理各传输组中的所有客户端的编号、状态和数据索引信息；

[0020] 如果服务端在超时时间内未收到客户端的心跳，则认定该客户端失联，将该客户端标记为失联状态，并将传输组内维护的客户端状态标记为失联状态；

[0021] 如果服务端重新接收到客户端的心跳，则将客户端标记为在线状态，并将传输组内维护的客户端状态标记为在线状态；

[0022] 如果服务端在指定时间间隔内始终未能接收到客户端的心跳，则将移除该客户端，并在传输组中删除该客户端信息。

[0023] 进一步的，所述客户端加入指定传输组时，服务端自发向该客户端同步该传输组内传输的历史消息；

[0024] 所述客户端断线重连时，服务端以客户端最后接收成功的数据索引为依据，自发向该客户端同步断线期间未能正常同步的历史消息；

[0025] 同时，所述服务端向客户端进行历史消息传输时，将暂时阻塞向该客户端传输增量信息的过程，当历史数据传输完毕后，再进行增量信息传输。

[0026] 一种面向微服务架构的消息传输方法，包括：

[0027] 客户端向服务端发送需向其他客户端同步的消息，并接收服务端同步的来自其他客户端的消息；

[0028] 服务端接收客户端发送消息，并根据通讯方式将消息传输到目标客户端；

[0029] 所述服务端和客户端均采用基于任务链的并行处理方式实现对传输消息的处理。

[0030] 本发明与现有技术相比，其显著优点在于：1)客户端将消息分片为头帧和若干续帧有序发送，头帧支持加入数据校验信息用于消息一致性校验；服务端针对来自同一客户
端发送的消息，采用同一“任务链”进行处理，保证消息传输、处理的有序性；同时，服务端对
收到的消息进行一致性校验、持久化，保证消息传输的可靠性。2)提供单播、组播和广播三
种通讯方式，支持客户端通讯方式动态调整，满足微服务架构不同消息传输场景需求；3)引
入服务化架构理念，将数据阶段处理封装为任务，多个任务灵活组装为“任务链”，方便拓展
数据路由规则；4)基于以上效果，本发明在实际环境下能够实现在大规模微服务节点间进
行快速的消息同步，具有较强的可操作性和实用价值。

附图说明

[0031] 图1是面向微服务架构的消息传输系统的结构图。

[0032] 图2是帧数据封装结构图。

[0033] 图3是服务端消息接收校验分发“任务链”的原理图。

[0034] 图4是客户端消息接收发送“任务链”的原理图。

[0035] 图5是服务端消息缓存和持久化的原理图。

[0036] 图6是服务端传输组管理的原理图。

[0037] 图7是面向微服务架构的消息传输的流程图。

具体实施方式

[0038] 为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不
用于限定本申请。

[0039] 本发明面向微服务架构的消息传输系统如图1所示，由服务端和客户端组成。其中，客户端与微服务集成，用于向服务端发送需向其他客户端同步的消息，并接收服务端同
步的来自其他客户端的消息。服务端独立部署，用于接收客户端发送消息，并根据通讯方式
(单播、组播和广播)将消息传输到目标客户端。服务端和客户端均采用基于“任务链”的并
行处理方式实现对传输消息的高效处理。下面结合附图1‑7对本发明做进一步详细的描述。

[0040] (一)传输协议说明

[0041] 本发明采用TCP/IP传输协议进行通信，采用同步非阻塞NIO框架以支持高负载、高并发的应用需求。为了提高数据的传输效率，本发明将传输消息实体拆分并封装为自定义
的帧结构，作为最小传输单元。封装的传输消息实体由一个头帧和若干个续帧组成，如图2
所示。详细说明如下。

[0042] 头帧主要包括传输过程中的控制信息，由帧头和帧体组成。帧头包括帧体长度、数据帧类型、标志位、数据唯一标识、保留位；帧体包括传输数据长度、传输数据类型、加密方
式、压缩方式、序列化编码方式、是否持久化标志、通信方式、发送端编号、接收端编号和数
据校验信息组成。其中，数据帧类型包括头帧类型、续帧类型，数据唯一标识定义帧数据是
否属于同一个消息实体；传输数据类型包括字节类型、字符串类型、文件类型；通信方式包
括单播、组播和广播。

[0043] 续帧主要包括传输消息实体，由帧头和帧体组成。帧头包括帧体长度、数据帧类型、标志位、数据唯一标识、保留位，帧体包括消息实体。每个续帧最大数据容量为8KB，一个
传输消息实体可能由多个续帧组成。

[0044] (二)服务端和客户端消息处理流程

[0045] 本发明通过将消息处理过程划分为阶段子任务，并将子任务组装为可以并行处理的“任务链”，支持同时开启多条“任务链”，以提高消息并发处理能力。服务端针对来自同一
客户端的消息，采用同一条“任务链”进行处理，保证同一客户端传输消息的有序性。

[0046] 服务端消息接收校验分发“任务链”如图3所示，处理流程如下：

[0047] 1、子任务1用于消息接收、控制信息获取和数据校验，如图3中步骤①②③④所示。服务端接收消息并还原成帧结构，通过数据唯一标识合并续帧中的数据内容，获取完整的
消息实体；通过解析头帧提取是否持久化标志、通信方式、发送端编号、接收端编号和数据
校验信息等控制信息；使用提取的数据校验信息对接收到的消息实体进行校验，如果校验
失败，通知发送客户端重新发送，并结束当前处理链路；如果校验成功，通知发送客户端可
继续发送下一条消息；将控制信息和消息实体封装成对象，交给子任务2处理；

[0048] 2、子任务2用于消息持久化，如图3中步骤⑤⑥⑦所示。根据子任务1中获取的持久化标志，判断是否需要对该消息对象进行持久化。如果不需要持久化，则直接提交给链路中
下一子任务进行处理，如果需要持久化，则先对消息对象进行持久化，然后再提交给下一子
任务处理；

[0049] 3、子任务3用于获取需转发的客户端编号，如图3中步骤⑧所示。根据通信方式确定消息发送是单播、组播或是广播。如果是单播，则直接获取接收端编号；如果是组播，则通
过发送端编号查询发送端所属的传输组，并获取组内所有在线的客户端编号；如果是广播，
则获取当前所有在线的客户端编号。然后将消息对象写入对应客户端待发送缓存队列中，
交给子任务4处理；

[0050] 4、子任务4用于消息发送，如图3中步骤⑨所示。从子任务3中的待发送缓存队列中获取消息对象，将消息对象重新封装成帧结构，并转发至对应客户端。转发失败时将进行重
试发送，若多次重试仍转发失败，则将错误信息通知到来源客户端。

[0051] 图4所示是客户端消息接收和消息发送“任务链”，处理流程如下：

[0052] 消息接收处理流程：

[0053] 1、子任务1用于消息接收、控制信息获取和数据校验，如图4中步骤①②③④所示。具体，接收消息并还原成帧结构，通过数据唯一标识合并续帧中的数据内容，获取完整的消
息实体；通过解析头帧获取数据校验信息、加密方式、压缩方式、序列化编码方式等控制信
息；使用获取的数据校验信息对接收到的消息实体进行校验，如果校验失败，通知发送服务
端重新发送，并结束当前处理链路，如果校验成功，通知发送服务端可继续发送下一条消
息，并将控制信息和消息实体封装成对象，然后交给子任务2处理；

[0054] 2、子任务2用于数据解密，如图4中步骤⑤所示。根据步骤1中提取的数据加密方式，对数据进行解密，然后提交给子任务3处理；

[0055] 3、子任务3用于数据解压，如图4中步骤⑥所示。根据步骤1中提取的数据压缩方式，对数据进行解压，然后提交给子任务4处理；

[0056] 4、子任务4用于数据反序列化，如图4中步骤⑦所示。根据步骤1中提取的数据序列化方式，对数据进行反序列化为原始消息，并将消息提交给对应微服务服务处理。

[0057] 消息发送处理流程：

[0058] 1、子任务1用于接收微服务提供的消息、控制信息并对消息进行序列化，如图4中步骤a、b所示。微服务提供需传输的消息，并选择用于数据处理的序列化编码方式、压缩方
式、加密方式和通信方式等控制信息，客户端根据的微服务选择的序列化编码方式对数据
进行序列化，然后提交给子任务2处理；

[0059] 2、子任务2用于数据压缩，如图4中步骤c所示。客户端根据子任务1中选择的压缩方式，对数据进行压缩，然后提交给子任务3处理；

[0060] 3、子任务3用于数据加密，如图4中步骤d所示。客户端根据子任务1中选择的加密方式，对数据进行加密，然后提交给子任务4处理；

[0061] 4、子任务4用于数据封装和发送，如图4中步骤e、f、g所示。根据消息内容生成校验信息，并按照帧结构封装数据，然后向服务端发送封装后的数据帧。发送失败时将进行重
试，若多次重试仍发送失败，则通知对应微服务数据发送失败。

[0062] (三)服务端数据持久化

[0063] 本发明实现了对需要持久化的消息进行入库处理，数据库采用嵌入式数据库RocksDB。消息持久化的目的主要包括：1)新加入的客户端可以申请获取服务端传输的历史
消息；2)客户端断线重连后仍可获取断线期间传输的历史消息；3)避免传输服务宕机导致
传输消息的丢失。

[0064] 图5所示是服务端消息缓存和持久化原理图，处理流程如下：

[0065] 1、将消息封装成日志对象，并提交至日志预处理任务队列，如图5中步骤①②所示；

[0066] 2、从日志预处理任务队列批量获取日志对象，检查并按顺序为日志对象设置索引，然后将日志对象写入内存缓存，同时，将日志对象提交至持久化任务队列，如图5中步骤
③④⑤⑥所示；

[0067] 3、从持久化任务队列中批量获取日志对象，按索引顺序将日志对象写入嵌入式数据库RocksDB，入库成功后通知后续任务可以进行相关数据的转发，并删除内存缓存中的相
关日志对象。如图5中步骤⑦⑧⑨⑩所示。

[0068] (四)服务端的传输组管理和客户端上下线管理

[0069] 本发明的服务端提供传输组的方式组织客户端，以支持单播、组播和广播三种通信方式。传输组用来记录属于同一传输分组的客户端的编号、状态和数据索引等信息，服务
端可以新建、删除并维护多个传输组，如图6所示，加入指定传输组的客户端支持组播通信
方式。同时，服务端维护了一个超级传输组，加入超级传输组的客户端支持广播通信方式。
所有客户端都支持单播通信方式。

[0070] 具体地，组播通信是指客户端可以通过向服务端申请并经服务端同意后加入指定传输组，当客户端加入指定传输组并且选择组播的通信方式，传输的消息将会被转发给传
输组中当前所有在线的客户端；广播通信是指客户端申请并经服务端同意后加入超级传输
组，当客户端加入超级传输组并且选择广播的通信方式，传输的消息将会被转发到当前所
有在线的客户端；单播通信是指客户端通过指定消息接收端编号并且选择单播的通信方
式，传输的消息将会被转发到指定编号的客户端。

[0071] 服务端管理各传输组中的所有客户端的编号、状态和数据索引等信息。具体地，客户端实时向服务端报送心跳，如果服务端在超时时间内未收到客户端的心跳，则认定该客
户端失联，将该客户端标记为失联状态，并将传输组内维护的客户端状态标记为失联状态；
如果服务端重新接收到客户端的心跳，则将客户端标记为在线状态，并将传输组内维护的
客户端状态标记为在线状态；如果服务端在指定时间间隔内始终未能接收到客户端的心
跳，则将移除该客户端，并在传输组中删除该客户端信息。

[0072] 客户端加入指定传输组时，服务端可以自发向该客户端同步该传输组内传输的历史消息。客户端断线重连时，服务端以客户端最后接收成功的数据索引为依据，自发向该客
户端同步断线期间未能正常同步的历史消息，确保客户端接收消息的完整性。同时，服务端
向客户端进行历史消息传输时，将暂时阻塞向该客户端传输增量信息的过程，当历史数据
传输完毕后，再进行增量信息传输，以确保数据的顺序性。

[0073] 本发明还提供一种面向微服务架构的消息传输方法，包括：

[0074] 客户端向服务端发送需向其他客户端同步的消息，并接收服务端同步的来自其他客户端的消息；

[0075] 服务端接收客户端发送消息，并根据通讯方式将消息传输到目标客户端；

[0076] 所述服务端和客户端均采用基于任务链的并行处理方式实现对传输消息的处理。

[0077] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机
可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，
本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可
包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM
(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括
随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，
诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强
型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM
(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

[0078] 以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛
盾，都应当认为是本说明书记载的范围。

[0079] 以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来
说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护
范围。因此，本申请专利的保护范围应以所附权利要求为准。