[发明专利]技术中台中基于微服务架构实现业务链路分析的方法、系统、装置及存储介质

说明书

本发明涉及一种技术中台中基于微服务架构实现业务链路分析的系统，包括根据业务链路数据元模型构建业务流程模型、微服务部署模型和业务指标模型，并形成体现业务概念的业务链路数据模型来记录全链路信息；在微服务架构下通过全链路追踪日志在日志文件中采集全链路信息；进行业务链路分析，自动识别业务流程，并按照业务维度给出分析结果。本发明还涉及一种技术中台中基于微服务架构实现业务链路分析的方法。采用了本发明的技术中台中基于微服务架构实现业务链路分析的方法、系统、装置及其计算机可读存储介质，建立了业务链路数据模型，通过业务流程与服务调用链相匹配，将服务调用链路与业务概念关联，从业务维度对服务调用链进行分析，实现了微服务架构下业务链路的分析，以图形化的方式展现业务状况信息。

技术领域

本发明涉及微服务架构领域，尤其涉及全链路追踪领域，具体是指一种技术中台中基于微服务架构实现业务链路分析的方法、系统、装置及其计算机可读存储介质。

背景技术

微服务架构是软件架构演进发展出来的一种架构风格，它把大型的单体应用程序分解为一个个单独打包、独立部署的小应用，即微服务架构的功能模块是分布式部署运行的，并以轻量级机制(通常是HTTP资源的API)进行通信。从前台到后台的完整业务流会经过很多个微服务的处理和传递，因此，业务链路的分析需要跟踪各个微服务之间的调用关系和业务处理顺序，通过全链路追踪日志形成一条完整的调用链，记录每个处理步骤的请求内容及耗时等信息，从而进行用户体验分析、交易全路径监控与分析、端到端性能分析、系统异常分析、系统故障定位等。

微服务架构中，通过全链路追踪日志实现服务监控与问题分析。就是必须清楚某个接口调用了哪些微服务，以及调用的顺序，把这些微服务串起来，看起来就像链条一样，即“调用链”。

调用链的实现需要为每次微服务调用做个顺序标识，然后将服务调用按标识大小排列，便可以清晰地看出调用顺序，该标识即为“SpanId”。

调用链需要知道具体某次请求调用的情况，仅有SpanId还不够，需要在第一个接收到外部请求的微服务中生成全局唯一的追踪标识，即“TraceId”，并在后续的微服务调用时对TraceId进行传递，每个被调用的微服务输出日志时记录该TraceId，最终对记录的日志进行分析，这样便能根据追踪标识查出本次请求调用的所有服务，获取完整的链路追踪信息。

根据SpanId可以分析被调用微服务的先后顺序，但无法分析调用的层级关系，多个服务可能是逐级调用，也可能是同时被同一个服务调用。所以每次调用都会记录下是谁调用的，即记录“ParentId”。

至此，已经可以分析调用顺序和层级关系了，但是接口出现问题后，还是不能找到出问题的环节，通常某个服务有问题时会导致调用执行的耗时很长，要想计算出服务执行的耗时，还需要时间戳，精确到微秒级，记录发起调用时的时间戳和服务返回时的时间戳，以便计算发起调用和服务返回之间的时间差。

服务调用到服务返回的总耗时包含了服务的执行时间和网络延迟，实际应用中需要分析出这两类时间以便做针对性优化。我们把调用和返回的过程分为以下四个事件：

1)Client Sent，简称cs，客户端发起调用请求到服务端。

2)Server Received，简称sr，指服务端接收到了客户端的调用请求。

3)Server Sent，简称ss，指服务端完成了处理，准备将信息返给客户端。

4)Client Received，简称cr，指客户端接收到了服务端的返回信息。

在这四个事件发生时记录下时间戳，就可以计算出各段的耗时，比如sr减去cs就是调用时的网络延迟，ss减去sr就是服务执行时间，cr减去ss就是服务响应的延迟，cr减cs就是整个服务调用执行的时间。