[发明专利]一种在微服务架构下实现全局有序重演的方法

说明书

本发明涉及微服务架构下的信息数据处理技术领域，具体来说是一种在微服务架构下实现全局有序重演的方法，每个节点的逻辑时钟层内部都维护一个二元组形式的逻辑时钟{T,C}，T初始化为0，C初始化为0。每条传递的消息m都携带两个逻辑时戳：ts(m)对应m的发送,tr(m)对应m的接收。ts(m)和tr(m)的格式也是如上所示的二元组{T,C}。本发明同现有技术相比，其优点在于：在应用软件层和消息中间件之间设有逻辑时钟层，作为逻辑时钟和逻辑时间戳的维护逻辑，逻辑时钟会同时参考本机物理时钟和消息传递的因果时序，且由于逻辑时钟的T分量和事件的物理时间非常接近，易于按指定倍速进行重演。

[技术领域]

本发明涉及微服务架构下的信息数据处理技术领域，具体来说是一种在微服务架构下实现全局有序重演的方法。

[背景技术]

在微服务架构下，整个系统由许多高内聚、低耦合的微服务构成。为完成特定业务，不同微服务通过彼此收发消息来完成协作，而在不同业务下消息的流动模式可能是完全不同的。为实现高可用性，单个微服务可能被构建成一个高可用集群，整个集群作为一个整体对外提供服务。

微服务架构是一个分布式系统，各个微服务之间仅仅通过彼此传递的消息互相协调。出于性能考虑，微服务架构通常没有中心化的全局日志，因为如果全部日志都通过一个中心点来维护，这个点就会成为整个系统的瓶颈。通常每个微服务只负责维护自己的日志。

如果没有特别的措施，依靠各微服务的日志只能保证有序重演微服务自身的历史，无法全局有序地重演整个系统的历史。比如经过一天后，微服务A的日志项只有10条记录，微服务B和C的日志项各有10亿条记录。如果仅仅让每个微服务读取自身日志重放，微服务A可能不到1秒就重现了历史，而微服务B和C需要耗费18小时才能重现历史，而实际上微服务A的10条记录是为了响应微服务B和微服务C在当天23:59后发送的各5条请求而产生的，如果真要全局性地重演整个系统的历史，微服务A的日志重演应该发生在微服务B和C的日志重演接近尾声时，如此才是全系统历史的重演。

单纯为微服务的日志项打上高精度时间戳并不能解决问题，因为不同主机的时钟并不完全同步，且时间戳的精度也并非无限。若微服务B和C几乎同时发出消息给微服务A，微服务A几乎瞬间收到消息，2个消息发送事件和1个消息接收事件在各自日志中的时间戳甚至可能出现倒挂。单纯按照日志时间戳重演整个系统的历史，可能会先重演微服务A收到来自微服务B的消息，随后再重演微服务B发出这条消息，显然是荒谬的。

标准的Lamport逻辑时钟可以解决按因果序重演全系统历史的问题，但逻辑时钟只是一个单调递增的大整数，并不和物理时间戳对应，在全局重演时无法以指定倍速重演真实历史。比如全天微服务A在9点，10点和19点分别给微服务B发送了3个请求并获得了应答，按Lamport逻辑时钟重放的时候3个请求的回放间隔就是均匀的，而现实生活中间隔并不均匀。

因此，出于事后审计、故障重现、程序调试等目的，需要设计一种能够在微服务架构下支持按指定倍速实现全局有序重演的方法。

[发明内容]

本发明的目的在于解决现有技术的不足，提供一种在微服务架构下实现全局有序重演的方法，能够在微服务架构下支持按指定倍速实现全局有序重演，以实现事后审计、故障重现、程序调试的目的。

为了实现上述目的，设计一种在微服务架构下实现全局有序重演的方法，所述的微服务和微服务之间通过消息中间件进行通信，其特征在于在消息中间件上实现逻辑时钟算法，所述的逻辑时钟算法同时参考本机物理时钟和消息传递的因果时序，在应用软件层和消息中间件之间设有逻辑时钟层，作为逻辑时钟和逻辑时间戳的维护逻辑，在每个节点的逻辑时钟层内部都维护一个二元组形式的逻辑时钟{T,C}，其中T和C初始化均为0，每条传递的消息m都携带两个二元组{T,C}格式的逻辑时间戳ts(m)和tr(m)：其中，ts(m)对应m的发送,tr(m)对应m的接收，两个逻辑时间戳之间的比较规则是：先看T分量哪个大；若相等则再看C分量哪个大，具体步骤包括：