文章采集调用(云原生及混合云模式下的微服务架构应用)

　　文章采集调用(云原生及混合云模式下的微服务架构应用)

　　前言

　　进入云原生时代后，依托容器技术和分布式技术的发展，为适应高并发、高压力、快速迭代的场景，微服务架构成为更多企业的必然选择。微服务架构为互联网时代的软件开发带来了极大的优势，例如增加服务的可扩展性、增强易维护性、减少语言依赖等。

　　但与此同时，从单体架构到微服务架构的转变在应用监控层面提出了前所未有的挑战。服务的拆分使得应用和服务之间的相互调用关系呈几何级数增长。从用户端发起的请求可能会在微服务和各种中间件之间相互调用，最终形成复杂的调用关系网络。

　　用户请求发出后，完整的调用链图如下：

　　此时，基于单机业务的传统监控系统已经无法监控新的关系网络。因此，在微服务架构体系下，迫切需要建立一种新的监控机制，能够及时监控和反馈应用和系统的运行状态，在系统运行异常时辅助开发者定位问题，并提供系统性能调优。 . 充足的数据支持。

　　1、全链路监控的目标是什么？

　　微服务架构使得应用程序和中间件之间的调用链更加复杂。同时，云原生和混合云的兴起对全链路监控的实现提出了更高的要求。

　　为了提高混合云模式下微服务架构应用的健壮性和稳定性，一般来说，我们对全链路监控的三个核心需求如下：

　　1. 系统间依赖梳理：可完整绘制系统与服务之间的调用关系，帮助开发运维评估上下游依赖关系，判断故障范围；

　　2.关键性能指标展示：可以展示各个环节对应的关键性能指标，可以给研发人员性能优化的方向，也可以帮助运维人员对系统资源的合理配置提出建议;

　　3. 端到端问题诊断：当系统出现故障或异常时，可立即发出告警，协助运维人员发现并快速定位并解决问题。

　　全链路监控就是在解决这些问题的背景下创建的。

　　全链路监控是一套跨语言、跨应用、跨服务器、跨数据中心的分布式系统服务。通过添加探针等，对应用、系统等性能指标进行采样采集，以调用链为主要方法。分布式监控系统，展示监控数据，帮助开发人员和运维人员分析性能问题，定位异常问题。

　　一些平台还将全链路监控称为全链路跟踪。可以说，全链路监控是一套覆盖所有关联系统的IT系统。它是一套可以完整记录用户行为、存储日志、显示系统间调用路径和状态的最佳实践解决方案。

　　在全链路监控系统中，调用链是一个核心概念。就是从请求源，通过微服务调用，到底层中间件之间的所有中间调用环节。

　　全链路监控的关键价值在于“关联”，即由终端用户、后端微服务应用、云中间件组件构成的编织关系网络。从理论上讲，这个关系网络的覆盖范围越大，采集的关键指标越多，全链路监控的价值就越大。

　　2、实现全链路监控的难点是什么？

　　混合云模式下的每个微服务应用可能由不同的研发团队开发，需要部署在多台服务器上实现横向扩展，甚至可能同时部署在云端和自建机房的数据中心. 软件部署和调用方法也有很大不同。

　　在此背景下，实现全链路监控面临诸多挑战，总结如下：

　　1. 支持*敏*感*词*混合云场景：当成千上万的微服务应用部署在公有云和混合云中时，如何快速及时地获得采集应用运行状态信息，同时采集日志到日志中央。如何采集并将第三方中间件集成到监控系统中，是全链路监控研发人员需要面对的最严峻的问题。

　　2. 降低对业务的影响：如果SDK或探针采集数据进行全链路监控占用过多系统资源或对应用性能影响过大，会降低系统整体阻力。压力，甚至是对业务造成严重后果的不可预测的失败。

　　3. 丰富完善的监控系统：一般来说，Java编写的应用程序比较容易获取自己的运行状态监控数据，但其他类型的应用程序由于相对不完善，难以从底层架构层面全面支持生态。对于其他语言编写的应用程序，以及多渠道部署的中间件的完整指标采集都是开发者需要考虑的问题。

　　4. 维护简单可行：除了客户端部署的SDK或探针外，服务器端的一整套全链路监控由接收模块、计算模块、存储模块、显示模块。运维人员需要对每个探头和模块进行维护。因此，全链路监控系统在开发时一定要考虑自身的易维护性，否则，在大型系统中，运维工作将成为一场灾难。

　　5. 保证自身的高可用：全链路监控系统必须能够保证自身具有一定的高可用。否则，当某个模块或组件出现异常时，可能会失去整个业务系统的正常监控功能。在极端情况下，甚至会造成蝴蝶效应，导致整个系统雪崩。

　　我们说，全链路监控的价值与其所能覆盖的监控范围成正比，它的挑战也与监控范围成正比。因此，全链路监控开发者在实现功能时必须同时考虑和克服这五个难点。

　　3、全链路监控的规范是什么？

　　十多年前，谷歌在著名论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》中详细阐述了如何在*敏*感*词*系统上构建一个低损耗、应用级透明、可扩展的系统。具有广泛部署属性的分布式系统链接跟踪服务。

　　在 Dapper 论文中，Google 公开了分布式系统链路跟踪的实现技术细节，包括数据表示、埋点、传输、采集、存储和显示，并提出了跟踪树、Trace、Span 和 Annotation 等重要概念为实现全链路监控提供理论依据。

　　受 Dapper 的启发，业界开发了许多用于分布式链接跟踪的开源组件。由于需要在链接中记录每个链接的信息，信息不仅限于某个链接，还需要跨不同的应用程序和分布式中间件进行传播。因此，必须制定一套统一的标准规范。整个链接中的所有链接都必须符合本规范和标准，才能实现完整信息的描述、跟踪和传输功能。这组标准称为 OpenTracing。

　　可以说OpenTracing是一套独立于编程语言和业务逻辑的抽象接口集，可以统一管理链路跟踪领域的各种元素，从而实现完整的全链路监控。

　　跨度

　　Span是全链路监控的基本单位。为微服务和中间件之间的每次调用创建一个 Span。此调用可以是 RPC 调用、数据库访问等。跨度由 64 位 ID 标识。UUID更方便，是生成Span ID的首选。Span 记录的信息包括名称、调用时间、键值对形式的标签数据、父调用ID。

　　值得强调的是，Dapper 通过记录每个 Span 的父 ID 来跟踪完整的链接请求。即Span的每一级只记录调用发起者的ID，一个完整的调用具有相同的trace id。如果 Span 没有父 ID，则称为 Root Span。读取记录时，根据 Trace ID 获取所有 span，根据 parent ID 连接 span，绘制一个请求的完整调用链接。

　　痕迹

　　Trace用于标记一个请求的发起，通过各种微服务应用和中间件，直到服务返回并结束。Trace 是一个有向树结构的 Span 集合。

　　图中，每个颜色标签代表一个Span，访问链路由唯一的Trace ID标识。整个架构用树形结构表示，树中的每个节点都是一个Span。树中节点之间的连线代表了一个 Span 与其父 Span 之间的调用关系。

　　注解

　　注释是用来记录事件相关信息的注释，例如发生的时间。一个 Span 可以由多个 Annotation 来描述。

　　Dapper采集数据处理

　　如图所示，Dapper daemon采集 业务日志，并将日志信息保存在日志文件中。Dapper Collectors 定期请求提取日志并将它们存储在 Central Bigtable 中。

　　由于日志量很大，Dapper 在采集logging 时使用了采样率模式。如果采样率设置为 1/1024，则表示每 1024 条日志生成一次采集。