SkyWalking相关问题及答案（2024）

2024-01-09 18:41:35

1、什么是SkyWalking？它用于解决什么问题？

Apache SkyWalking是一个开源的应用性能监控工具，它提供了端到端的分布式跟踪、服务网格摄取、度量聚合和可视化解决方案。它主要用于追踪和监测分布式系统，特别是大规模使用微服务架构的系统。以下是SkyWalking的详细介绍和它解决的问题。

SkyWalking的主要功能

  1. 分布式跟踪（Distributed Tracing）：SkyWalking能够记录服务间的每次调用的详细数据，帮助开发者和运维人员追踪请求在不同服务间的路径。

  2. 性能监控（Performance Monitoring）：SkyWalking监控服务和服务实例的性能，例如响应时间、吞吐量等。

  3. 拓扑分析（Topology Analysis）：它自动构建系统的拓扑图，显示服务间的依赖关系和通信路径。

  4. 服务网格摄取（Service Mesh Telemetry）：摄取并分析服务网格框架（如Istio）产生的监控数据。

  5. 告警（Alerting）：用户可以定制告警规则，当出现问题时能及时得到通知。

  6. 可视化控制台（Visualization Dashboard）：提供友好的Web UI，方便直观地展示监控数据和追踪信息。

  7. 运维管理（Ops Management）：支持持续诊断、问题排查和性能优化等运维活动。

SkyWalking解决的问题

  1. 服务性能问题定位：在微服务架构中，服务调用链路复杂。SkyWalking提供链路追踪，帮助运维团队快速定位服务性能瓶颈。

  2. 故障诊断：当系统发生故障时，SkyWalking能帮助开发者了解问题发生的具体位置，例如是哪个服务、哪个实例或者是因为哪次调用。

  3. 系统拓扑分析：在分布式系统中，服务相互之间有复杂的依赖关系。SkyWalking可以自动绘制服务调用的网络拓扑图，通过可视化来帮助理解和分析整个系统的工作流程。

  4. 性能指标聚合：SkyWalking收集并聚合各服务的指标数据，提供量化评估服务健康状况的能力。

  5. 部分架构优化建议：基于聚合的度量数据和跟踪信息，SkyWalking有助于发现系统优化的机会，从而提升整体架构性能。

  6. 服务网格集成：当使用服务网格技术时，SkyWalking能集成并分析摄取的数据，以求无缝地在微服务架构中部署观测性能。

  7. 多语言支持：SkyWalking提供多语言的代理和SDK，如Java、.NET、Go、NodeJS等，方便不同服务框架的接入。

总结

Apache SkyWalking是一款功能丰富的APM（应用程序性能管理）工具，它特别适合用于微服务和分布式系统的监控。它可帮助开发和运维团队通过可视化数据去理解他们系统的行为，监控系统健康，以及在出现问题时提供快速故障排除的能力。随着分布式架构变得更加流行，SkyWalking等工具在现代软件开发和运维中扮演着至关重要的角色。

2、SkyWalking的主要特点是什么？

Apache SkyWalking 的主要特点体现在它为分布式系统监控和管理提供的一系列强大功能，以下详细介绍这些特性：

1. 自动化的服务注册与发现

  • 无侵入性监控：提供自动代理和手动埋点两种监控手段，支持各种编程语言和框架。
  • 服务自动检测：应用无需进行手动配置即可自动在SkyWalking系统中注册。

2. 分布式跟踪系统

  • 端到端追踪效果：记录并展示跨越多个服务和节点的请求路径。
  • 拓扑映射：自动生成服务拓扑图以表示服务节点和服务间的依赖关系。

3. 性能监控

  • 多维度数据：覆盖从服务、实例到端点的细粒度指标收集和分析。
  • 运行时诊断：捕获并分析应用运行时异常和慢请求。

4. 多种数据分析机制

  • 基于时间序列的度量分析：提供基于分钟、小时和日等的时间序列分析。
  • 告警机制：支持基于多种条件的告警和通知机制。

5. 丰富的UI与可视化

  • 可视化交互界面：提供方便的UI界面，支持拓扑图、度量图表、追踪数据等多种展示方式。
  • 自定义仪表盘：支持根据需要自定义数据显示面板。

6. 高扩展性

  • 模块化设计：采用模块化设计，用户可以根据需求灵活组合和扩展。
  • 插件机制：提供丰富的插件支持，适配多个热门语言和框架。

7. 可以整合多个数据源

  • 多后端支持：支持Elasticsearch、H2、MySQL等多种持久化方法。
  • 服务网格数据摄取：能够处理和分析来自服务网格平台（如Istio）的遥测数据。

8. 服务网格集成

  • 适配服务网格架构：不需要改变应用代码即可监控服务网格中的服务。
  • 可观测性：强化了对使用服务网格技术架构应用的可观测性。

9. 多语言支持

  • 支持各种编程语言：提供多种语言的探针，包括Java、.Net Core、PHP、Node.js、Go，以及许多其他语言。

10. 社区驱动的发展

  • 强大的社区支持：拥有活跃的开发者和用户社区，不断推动功能的增强和改进。

总结

Apache SkyWalking 是一款全面的应用性能监控和管理系统，强调对分布式应用和微服务架构的支援。通过提供端到端的分布式追踪、服务拓扑分析、性能监控、告警、可视化等能力，SkyWalking 能帮助团队监控和评估他们的系统性能，快速定位问题，优化系统架构。它的设计强调易用性和扩展性，意图为现代云原生应用提供全方位的可观测性解决方案。

3、SkyWalking的架构和各个组件的作用

Apache SkyWalking 的架构被设计为多层次和模块化的，可以很容易适应不同规模和需要调整的分布式系统。以下是它的关键架构组件和它们各自的作用：

1. 探针（Agent）

  • 应用探针：部署在应用服务器上，自动监控并收集应用数据，包括调用追踪、性能指标等。
  • 服务语言探针：SkyWalking 提供了多种语言的探针（如Java、.NET、Go、Node.js等），它们是自动化的，应用开发者通常不需要对代码进行任何调整。
  • 服务网格探针：对接服务网格平台，如Istio，在数据平面和控制平面之间捕获服务间的调用数据。

2. 平台后端

  • 接收器（Receiver）：收集探针和服务网格发送过来的数据。
  • 核心处理（Core）：负责数据的处理和分析，如追踪分析、度量分析、拓扑分析、告警分析等。
  • 存储层：SkyWalking 提供插件支持不同的存储系统，如Elasticsearch、H2、MySQL、TiDB等，用于持久化和查询数据。
  • 告警模块：当系统指标超过预定义阈值时，发出告警。

3. 前端用户界面（UI）

  • Web UI控制台：提供可视化的前端界面，用户可以通过它来查看生成的拓扑图、追踪信息、服务性能数据等。

4. 查询

  • GraphQL查询服务：SkyWalking UI或用户编写的客户端可以通过GraphQL查询语言来请求存储在SkyWalking后端的数据。

5. OAP服务器（Observability Analysis Platform）

  • 流式数据处理：OAP服务器是SkyWalking后端的核心，它负责流式数据处理，包括数据的收集、聚合、分析与存储。
  • 动态配置服务：负责提供修订配置而不需要重启SkyWalking服务。

架构概览

  • SkyWalking Satellite：实现了一个卫星概念，它是一个独立的边缘收集器，旨在减少网络和CPU资源消耗。
  • SkyWalking浏览器探针（optional）：可以收集前端页面的性能数据。
  • Exporter：通过Metrics Exporter能够将SkyWalking内部的指标和数据导出给外部的监控系统，如Prometheus。

功能和流程

  • 应用程序和服务网格内的探针向OAP服务器发送数据。这个数据涉及跟踪信息、服务指标、服务运行状态等。
  • OAP服务器接收这些数据，并进行实时分析和处理。如果需要，它也会将分析后的数据写入到配置的持久化存储中（如Elasticsearch）。
  • 用户可以通过SkyWalking的Web UI查看和分析数据。Web UI通过GraphQL向OAP服务器查询数据。
  • 可以配置告警规则，在一定条件触发时通过邮件、WebHook等方式发送告警通知。
  • Metrics Exporter 可以将数据导入到其他监控系统中去，跟更广泛的监控生态系统集成。

总结

SkyWalking 通过这些组件提供了一个全面的监控解决方案，支持多种类型的监控数据和多种分析维度。其架构的模块化与扩展性，确保了能够适应从简单到复杂不同规模的分布式系统的需要。探针的低侵入性、后端的高扩展性、存储的多样化选择以及强大的UI可视化能力，使其成为一个适合现代应用的观测和监控工具。

4、SkyWalking中的“追踪”是如何工作的？

在 Apache SkyWalking 中，追踪（Tracing）指的是监控、记录和分析服务间调用的过程和行为。这个功能至关重要，因为它帮助了解分布式系统中的请求如何流转，以及各种服务所发挥的作用。追踪机制通常涉及几个关键概念和步骤，包括Spans、Traces、Context Propagation等。

概念定义：

  1. Trace： 追踪是由一系列Span组成的树状结构，表示一个特定的请求在分布式系统中的完整生命周期。
  2. Span： 追踪中的一个基本工作单元，它记录了服务调用的开始、结束时间和其他关键信息（如操作名称、执行状态等）。

追踪流程：

  1. 请求开始时的追踪初始化：

    • 当请求进入分布式系统的入口点时，如果没有追踪上下文，将会创建一个新的追踪ID。
    • 在这个过程中创建的第一个Span被称作根Span（Root Span），它标记了整个Trace的开始。

  2. 上下文传播（Context Propagation）：

    • 追踪上下文（包括追踪ID、Span信息等）随着请求一起在各个服务和进程间传播。
    • 当请求调用下一个服务时，相关的追踪信息会传递给被调用的服务，这样即使服务间隔离，也可以将这些Span关联在同一个Trace中。

  3. 在各服务中创建新的Spans：

    • 当请求到达新的服务，该服务的SkyWalking探针将会创建一个新的Span，这个Span会成为追踪树中的一个节点。
    • 新Span会继承调用它的父Span的追踪上下文，并生成自己独特的Span ID。

  4. 追踪数据的收集与报告：

    • 每个Span完成时，它的数据会被报告给SkyWalking代理或直接发送给SkyWalking后端。
    • 这些数据包括时间戳、操作名、持续时间（执行时间）和其他可能的标签或日志。

  5. 代理和后端处理：

    • 代理或SDK会将Spans批量发送到后端，后端将Spans整合为完整的追踪视图。
    • 后端可能会对收集的数据进行处理，例如：聚合、分析和存储。

  6. 追踪数据的分析与展示：

    • SkyWalking后端将处理后的追踪数据存储起来，并提供查询接口。
    • 使用SkyWalking UI 或 API 可以查询、展示追踪路线图和详细Span信息。

特殊处理：

  • 错误和异常记录： 如果在服务调用过程中发生错误，相关的Span会记录这些信息，并在追踪视图上显示这些错误。
  • 跨线程和异步调用处理： 对于非阻塞和异步操作，SkyWalking能够保持上下文的连续性，并正确地构建追踪和Span。

总结：

通过追踪机制，SkyWalking 提供了一种方式来理解服务在一次请求中的交互和性能方面的表现。每个Span都是通过在服务调用点自动注入的探针来收集的，且追踪信息通过服务之间的请求来传播。SkyWalking 处理并存储这些追踪数据，使我们能够可视化和分析在复杂分布式系统中调用请求的行为。这对于诊断问题、优化性能和改进系统设计是至关重要的。

5、SkyWalking支持哪些语言的监控？

Apache SkyWalking 提供了对多种编程语言的应用监控支持。根据官方文档及社区贡献的情况，以下是一些被支持的语言，以及对应语言的监控能力和方法：

Java

  • 提供最全面的支持，包括自动探针（自动字节码插桩）和手动探针。
  • 支持多种Java框架和库的自动检测和监控，例如Spring Boot, Apache Dubbo, gRPC等。

.NET/C#

  • 提供了自动探针，支持.NET Core和.NET Framework。
  • 通过NuGet进行部署，可以监控HTTP请求、数据库调用、gRPC等。

Go

  • 有专门的Go探针库，支持手动集成到Go应用程序中。
  • 支持监控HTTP和gRPC调用，数据库访问等。

Python

  • 提供自动探针以及相应的应用编程接口(API)。
  • 支持多种web框架如Django、Flask，以及数据库等。

Node.js

  • 提供Node.js探针，用于监控Web应用程序和后端服务。
  • 支持对常用的Express, Koa框架的监控，以及对MySQL, PostgreSQL等数据库的监控。

PHP

  • 支持PHP应用的追踪监控。
  • 能够和PHP-FPM一起工作，支持常见的框架和组件。

Ruby

  • 可以监控Ruby on Rails应用。
  • 提供手动探针来插入追踪代码和进行数据的收集。

Erlang/Elixir

  • 有社区提供的SkyWalking Erlang探针。
  • 支持Erlang和Elixir应用程序。

C++

  • 提供C++探针进行代码级监控。
  • 支持异步非阻塞队列，多线程等特性。

除了以上这些，也有社区贡献的或者在不断进展中的支持其它语言和框架的探针。因为开源社区的持续贡献，这些支持的语言和框架列表不断增长。

SkyWalking 的探针通常都是以最不侵入式的方式进行工作的。对于程序员来说，通常不需要或只需要少量修改代码。自动探针包可以自行检测支持的库和框架，并进行自动追踪。

使用 SkyWalking，无论是传统的单体应用还是微服务架构，它都能提供全方位的监控能力，从而帮助开发者和运维工程师可视化 their 应用程序的性能和发现问题所在。

6、SkyWalking的Agent是做什么的？它是如何与应用服务交互的？

Apache SkyWalking 的 Agent 是一种服务端软件，其主要职责是自动插桩（instrument）目标应用程序，拦截感兴趣的方法调用和事件，收集性能指标（比如请求的时间、次数等）和追踪数据，然后将这些信息发送到 SkyWalking 后端进行进一步分析和存储。Agent 是部署在应用服务上的，它以轻量级的方式与应用服务交互，旨在为开发和运维人员提供可观测性而对应用性能影响最小化。

Agent 的工作流程大致如下：

1. 装载和初始化

  • 启动中的装载：当应用服务启动时，Agent 通常作为一个 JVM 参数被装载。例如，在 Java 应用中，通过 -javaagent:path/to/skywalking-agent.jar 参数将 SkyWalking Agent 添加到 JVM 启动命令中。
  • 配置：Agent 的行为会根据配置文件 agent.config 进行调整。这包括后端服务地址、采样率、字节码插桩规则、日志收集级别等。

2. 字节码插桩

  • 运行时插桩：Agent 使用字节码插桩技术，动态地修改目标应用的类，插入额外的监控代码。这通常是通过 Java 的 Instrumentation API 实现的，当类被JVM装载时进行修改，而无需修改应用源代码。
  • 创建 Spans 和 Traces：监控代码负责创建 Spans，这些 Spans 连接起来形成一条追踪链路（Trace），表示一次请求的完整过程。

3. 数据收集

  • 性能数据：Agent 会不断收集应用服务运行中的性能指标，如响应时间、吞吐量等。
  • 追踪数据：同时，它也记录具体服务调用的详细追踪信息，如调用链路、方法执行时间、参数、错误信息等。

4. 上下文传播

  • 跨服务追踪：在分布式系统中，追踪一个请求可能涉及多个服务。Agent 负责在服务调用时传播追踪上下文，保证在不同服务间的调用可以链接到同一个追踪链路。

5. 数据上报

  • 异步上报：Agent 定期将收集的数据（通常打包成一个或多个数据段）发送到后端。这个过程通常是异步的，以减少对应用性能的影响。
  • 压缩和优化：在上报之前，数据可能会被压缩和优化以减少网络传输压力。

6. 故障容错和自我保护

  • 缓存策略：如果后端不可达，Agent 会缓存一定量的数据，并在后端恢复后再次尝试发送。
  • 自我保护：为了防止对应用造成过大影响，Agent 会实施自我保护机制，比如在高负载情况下调整数据采集频率或暂停数据采集。

通过这种方式，SkyWalking Agent 使得应用性能监控和故障诊断变得透明和自动化，使开发和运维团队可以集中精力于业务开发和服务优化。此外，由于 Agent 对应用的侵入极小，它们可以在生产环境中安全使用，而不会有过大的性能开销。

7、在微服务架构中，SkyWalking如何追踪跨服务的请求？

在微服务架构中，单个用户操作可能会触发多个服务之间的调用。为了能够追踪跨服务的请求，SkyWalking 使用了一种分布式追踪系统来记录和分析服务间的交互。下面是 SkyWalking 分布式跟踪的细节步骤：

1. 全局唯一的追踪标识

当一个请求进入微服务架构时，SkyWalking Agent 在请求入口处的服务将生成一个全局唯一的跟踪编号（Trace ID）来标识一次完整的追踪。这保证了即便是在非常复杂的微服务架构中，我们也能把相关的操作标记在同一个追踪里。

2. 细粒度的操作单元（Span）

为了形成追踪信息，每个服务中的每一个操作都会被SkyWalking Agent封装为一个“Span”，其中包括了服务调用的基本信息，如服务名、操作名、开始结束时间、响应时间等。其中，首个服务创建的Span通常被标记为根Span。

3. 上下文传播

每个被追踪的请求都携带了一组跟踪上下文，当请求在微服务架构中流转时，跟踪上下文也会一起传播。这是通过在服务调用时将跟踪信息（至少包括Trace ID 和说明请求在调用链中位置的Span ID）加入请求协议的Header中来完成的。比如，在HTTP调用中，这些信息会作为HTTP Headers被传递。

4. 远程调用拦截

当请求在服务间进行远程调用比如通过 HTTP 或者 RPC 框架时，SkyWalking Agent会自动拦截这些请求并读取传入的跟踪上下文信息，然后为此服务调用创建一个新的Span。

5. 多级Span关联

新创建的Span会将读取到的跟踪上下文信息（包括父Span的ID）保存起来，并以此来建立Span之间的父子关系。这种方式保证了服务间的调用可以在一个完整的树状结构中被追踪和表示。

6. 追踪数据的收集和汇报

在服务处理完请求后，每个Span会被标记为已完成，并随后通过SkyWalking Agent 发送回SkyWalking OAP服务（Observability Analysis Platform）。SkyWalking OAP 会对这些数据进行处理，并最终构建出一次跨服务请求的完整追踪。

7. 分析和可视化

汇总的追踪数据可通过SkyWalking的前端用户界面进行查询和可视化。用户可以看到请求在整个微服务架构中的传递路径，以及每个服务在处理该请求时的性能数据。

通过这样的追踪机制，SkyWalking能够为微服务架构中的每一次请求提供详尽的终端到终端的可视化和性能分析，从而帮助开发者和运维人员优化服务之间的交互，减少延迟，并快速定位服务级别的问题。

8、SkyWalking如何进行性能分析？

SkyWalking 进行性能分析主要依赖于自动探针和采样机制，通过搜集分布式追踪信息和服务指标数据来实现。下面是它的工作流程和主要特点：

1. 自动化探针和插桩

SkyWalking 为支持的编程语言和框架提供了自动探针，通过字节码插桩或相应语言的代码插入技术，自动监测应用程序的性能。这些探针能在服务运行时探测并记录重要事件和指标，比如请求时间、处理时间、成功/失败次数等。

2. 生成Spans和Traces

探针为应用中的每个操作（如方法调用或处理请求等）生成一系列的Spans，Spans连接起来就形成了一条完整的Trace，用于表示一次完整请求或事务的过程。

3. 采样

为了降低数据收集和传输对系统性能的影响，SkyWalking 可以配置采样策略来决定收集多少追踪数据。采样可以是基于时间的、基于请求的或概率性的，意味着可能只有一小部分的请求会生成完整的追踪数据用于分析。

4. 性能指标计算

SkyWalking能够从追踪数据中抽取并计算出服务级别和端点级别的关键性能指标（Service-Level and Endpoint-Level Metrics），如：

  • 请求率（Requests per Second, RPS）
  • 平均响应时间（Average Response Time, ART）
  • 错误率（Error Rate）
  • 每个服务的并发处理数（Concurrency）
  • 分布式事务的持续时间（Duration）

5. 指标分析

这些计算出的指标在SkyWalking的后端（Observability Analysis Platform, OAP）进行进一步的分析处理，可以用来实现：

  • 对累积数据进行时序分析。
  • 通过聚合数据来概览服务健康状态。
  • 识别出不正常的性能模式和潜在的瓶颈。

6. 拓扑分析

SkyWalking可以构建服务间调用的拓扑图，这个图展示了微服务架构的结构，并结合性能指标来展示服务间关系和依赖的健康状况。

7. 告警系统

基于预设的门槛值或动态计算的基线，SkyWalking的告警系统能自动触发告警，使操作团队能够快速响应性能下降或异常行为。

8. 数据可视化

SkyWalking的前端界面提供了一个用户友好的方式来查看所有这些信息，包括仪表盘和图表，以有助于用户理解和分析系统性能。

9. AI-powered 分析

SkyWalking的后续版本可能会包含AI驱动的分析功能，比如异常检测和根因分析，以进一步减少需人工分析的需求。

通过上述各项功能，SkyWalking 为开发者、运维工程师和质量保障团队提供了一个全面的性能监控和分析工具，能够帮助他们确保应用的性能符合用户的期望和业务要求。

9、SkyWalking提供哪些数据可视化的方式？

Apache SkyWalking 提供了强大的数据可视化功能来展示监控数据和性能指标，这有助于开发者、运维人员和业务分析师更好地理解应用和服务的行为。以下是 SkyWalking 可视化的几种关键方法：

1. 仪表盘（Dashboard）

  • 服务视图：显示所有监控的服务列表和每个服务的健康状况，错误率，以及其他关键性能指标。
  • 实例视图：针对每个服务的实例展示更详细的健康状况和性能数据。
  • 端点视图：展示每个服务端点（如API URL、RPC 接口等）的性能指标。
  • 自定义仪表盘：SkyWalking 允许用户创建自定义的仪表盘以便专注于特定的指标或视图。

2. 拓扑图（Topology Map）

  • 服务拓扑：展示微服务架构的全貌，包括服务间的调用关系和流量。
  • 服务和服务实例关系：图形化地表现各个服务以及它们的实例之间的通信情况。

3. 追踪分析（Trace Analysis）

  • 追踪列表：列出记录的追踪信息，通常可以按条件如时间、追踪ID、服务名等过滤。
  • 追踪详情：以轴线图（Span Timeline）展示单次追踪中的各个Spans及其执行情况。
  • Span详情：提供Span执行的详细信息，包括执行时间、方法参数、响应结果、异常信息等。

4. 性能趋势（Performance Trends）

  • 时序图：展示了选定指标随时间变化的趋势，如请求吞吐率、响应时间等。
  • 热点图：通过颜色深浅表现某指标在不同时间的变化程度，如CPU使用率、内存消耗等。

5. 指标对比（Metric Comparison）

  • 对比图：对不同时间段、不同版本或不同环境下的性能指标进行比较分析。

6. 告警列表（Alarm List）

  • 告警通知：展示触发的告警信息，如服务不可用、响应时间超过预设的阈值等。

7. 日志视图（Log View）

  • 结构化日志：如果集成了日志采集，可以在SkyWalking UI中查看和搜索应用生成的结构化日志。

SkyWalking 的可视化工具非常灵活，支持针对特定情况进行深度定制，满足不同用户的监控需求。另外，SkyWalking 还支持与Grafana集成，使用户能利用Grafana强大的可视化能力来展现SkyWalking的监控数据。这样一来，用户就拥有了两种工具来满足他们的监测可视化需求。

10、SkyWalking如何进行服务依赖分析？

Apache SkyWalking 的服务依赖分析主要是基于收集到的追踪数据（Trace）和性能指标来实现的。服务依赖分析的目的是为了揭示服务之间的调用关系，帮助了解服务间的依赖性质、了解系统架构的复杂性以及定位潜在的性能瓶颈和失败点。以下是 SkyWalking 进行服务依赖分析的各个步骤和相关概念的详细说明：

1. 分布式追踪数据收集

SkyWalking 通过在服务实例中部署的探针自动收集服务调用数据。为了完成跟踪，SkyWalking 探针会跟踪入口和出口请求，以及在多个服务、多个实例之间的调用链路。

2. 上下文传递和Spans生成

当一个请求在服务之间传递时，SkyWalking 探针确保跟踪上下文的连续性，使得每个服务调用都生成对应的Spans并附着在相应的Trace中。这些Spans不仅保存了调用信息，也携带了关于服务依赖关系的重要数据。

3. 构建追踪链路

SkyWalking 分析这些连续的Spans来建立起一条请求的完整追踪链路（Trace）。每个追踪含多个Spans，对应于每次服务间的交互。通过分析这些Spans之间的父子关系和调用关系，SkyWalking 可以准确构建服务间的调用链。

4. 分析服务间的调用关系

SkyWalking 的核心分析模块，Observability Analysis Platform (OAP) 服务器，会分析这些追踪信息来构建服务依赖图。依赖图是一种有向图，其中的节点代表服务，边代表服务间调用关系。

5. 拓扑图绘制

服务依赖关系会被进一步处理和可视化，形成拓扑图。这个拓扑图显示了服务如何相互关联，以及请求如何在这些服务之间流转。

6. 定量分析

SkyWalking 会计算和定量化服务依赖数据，如请求次数、平均响应时间、成功率和错误率等。通过这些数据可以量化服务之间的依赖强度，以及服务调用的稳定性和性能。

7. 边缘计量

每条呈现在拓扑图上的边都由一系列指标（如调用次数、调用时间、错误数等）来支撑，提供了边的厚度或颜色深度等视觉要素以表示这些指标的大小。

8. 性能影响和风险识别

利用上述定量分析结果，SkyWalking 能够帮助用户识别服务依赖中可能存在的性能瓶颈和故障风险，如某个服务的响应时间突然增加或请求错误率提高可能会影响到依赖这个服务的其他服务。

9. 动态变化监控

SkyWalking 还可以跟踪服务之间调用关系的动态变化，这对于理解微服务架构的服务发现与动态扩缩容等行为尤其重要。

10. 告警

如果服务依赖分析发现某些异常模式或违反预设阈值的情况发生，SkyWalking 可以配置告警规则以通知相关人员。

经过如上步骤，SkyWalking 的服务依赖分析为运维团队提供了宝贵的信息，让他们能够更加迅速和有效地进行故障恢复和性能优化工作。通过这些工作，SkyWalking 有助于提高系统的整体稳定性和可用性。

11、SkyWalking的报警机制是如何配置和工作的？

Apache SkyWalking 的报警机制是其监控系统的关键组成部分，旨在及时通知运维人员系统健康状况的变化或潜在问题。报警系统的配置和工作机制可以分为以下几个步骤：

1. 报警规则配置

首先，用户需要定义报警规则。SkyWalking 的报警规则配置通常在 alarm-settings.yml 配置文件中进行。在这个文件中，用户可以设置多种报警规则，包括服务级别、服务实例级别、端点级别以及自定义规则。

规则的配置项通常包括：

  • 规则名称：定义报警规则的标识名。
  • 指标类型：要监控的性能指标，如响应时间（Response Time）、每分钟调用次数（Calls per Minute）、成功率（Success Rate）等。
  • 阈值：指标的阈值，当监控数据超过这个值时，触发报警。
  • 持续时间：指标持续超过阈值的时间长短，通常计算为多少分钟。
  • 消息模板：触发报警时所发送通知的格式和内容。

例如，一个简单的服务响应时间报警规则可能如下：

rules:
  service_resp_time_rule:
    metrics-name: service_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 3
    message: "Response time of service {name} is greater than 1000ms in 3 minutes of last 10 minutes."

2. 报警检查周期

SkyWalking 报警系统在后台运行，并按照指定的周期检查各项指标是否触发了报警规则。这个周期可以在SkyWalking的配置文件中设定。如果某个指标在定义的时间段内持续超过报警阈值，报警就会被触发。

3. 通知机制

一旦规则被触发：

  • SkyWalking 后端生成报警消息，这些消息将根据配置文件中的“消息模板”来格式化。
  • 报警消息会通过各类通知手段发送给用户，比如邮件、Webhook、Slack、gRPC 等。
  • SkyWalking 提供了钩子（Hooks）来集成第三方报警传输系统，这使得报警通知可以用不同的实现来发送。

4. 报警数据持久化

除了发送通知外，SkyWalking 的报警事件也会被记录在后端的存储系统中，以便后续的数据分析和审计。

5. 报警恢复

对于某些报警规则，SkyWalking 还支持报警恢复通知，即当指标值回到正常范围时，相应的恢复通知会被发送。

6. 弹性阈值

为了避免在负载波动时过于频繁地触发报警，SkyWalking 还支持动态基线策略来计算弹性的阈值。这基于过去的性能数据来动态定位正常的阈值范围。

7. 报警组

在更大的部署中，可能需要对报警进行分组，以便不同的团队关注不同的服务或指标。SkyWalking 允许通过在报警规则中定义组来实现这一需求，分组报警有助于大型环境中的报警管理。

通过配置和调整上述报警机制，SkyWalking 能够为企业提供实时监控、报警和通知，这有助于确保企业的微服务和应用能够保持高性能和高可用性。

12、SkyWalking有哪些配置方法及优劣

Apache SkyWalking 作为一个性能监控工具，提供多种配置方法以适应不同的部署需求和场景。配置方法主要包括配置文件、环境变量、启动参数等。每种配置方法都有其特定的场景和优缺点，以下详细介绍这些方法及其优劣。

1. 配置文件

SkyWalking 使用 YAML 文件作为其主要的配置方式，在 config 目录下包含有多个配置文件，包括 application.yml，log4j2.xml 等。

优势:

  • 中央管理：所有配置集中在一处，便于管理和查阅。
  • 格式易读：YAML 格式相对人类友好，易于读写和理解。
  • 层次结构：可以很好地表达配置数据的层次性。

缺点:

  • 重新部署要求：更改配置通常需要重启服务以使更新生效。
  • 不利于自动化：在某些自动化、容器化的环境中，可能更倾向于使用外部化配置。

2. 环境变量

SkyWalking 同样可以通过环境变量来覆盖配置文件中的设置。这种方式在容器化部署，如 Docker 或 Kubernetes 中，特别有用。

优势:

  • 便于自动化：容器化管理工具（如 Kubernetes）可以在部署时设置环境变量。
  • 不需配置文件：无需更改配置文件，可以通过环境变量直接传递配置。
  • 动态配置：在某些情况下，可以在不重启应用的情况下改变环境变量（取决于 SkyWalking OAP 服务器是否支持动态重载配置）。

缺点:

  • 管理分散：可能导致配置管理分散在多个地方，跟踪配置更改较困难。
  • 安全性：配置敏感信息（如密码）为环境变量，可能会有一定的安全风险。

3. 启动参数

SkyWalking 的一些探针（例如java探针）支持在启动命令中添加参数来配置探针行为。

优势:

  • 快速临时更改：对于临时调整或调试非常方便。
  • 适用于不同环境：可以针对不同的启动环境传入相应的参数来启动应用。

缺点:

  • 难以集中管理：启动参数分散在各个启动脚本中，不如配置文件集中。
  • 重启要求：更改参数通常需要重启应用程序。

4. Web界面动态配置

SkyWalking 还支持通过动态配置系统，如 Apache Zookeeper、Nacos 等，来动态更新配置。

优势:

  • 动态更新：可以在不重启服务的情况下更新配置。
  • 中央管理：配置信息可以通过一系列外部管理工具进行集中管理。

缺点:

  • 复杂性增加：需要维护额外的动态配置系统和相应的接入代码。
  • 依赖外部系统：对于那些要求轻量或不依赖外部系统的环境来说可能不是最佳选择。

5. Agent配置

关于SkyWalking探针的配置，通常是通过探针的 agent.config 文件来进行配置。该配置影响探针的行为，如采样率、忽略的端点、日志收集策略等。

优势:

  • 针对性配置：专为探针进行定制的配置，不影响服务的其他部分。
  • 容灾能力：即使无法连接到OAP服务器，探针也可以根据本地配置正常工作。

缺点:

  • 配置文件繁杂：在大规模部署中，需要配置大量探针，可能会导致配置文件的管理变得复杂。

总结来说，不同的配置方法适应不同的应用场景和需求：配置文件适用于中央管理，环境变量和启动参数适合自动化和容器化部署，动态配置和Agent配置则提供了更灵活的配置选项，尤其适合于大规模动态环境。正确选择配置方法对于确保 SkyWalking 正确有效地运行至关重要。

13、SkyWalking的后端存储支持哪些数据库？它们之间有何差异？

Apache SkyWalking 作为一个应用性能监控和管理系统，支持多种类型的后端存储，以适应不同规模和需求的监控场景。支持的存储系统主要包括传统的关系型数据库、NoSQL数据库以及时序数据库，各自有不同的性能特点和适用场景。

支持的数据库包括：

  1. Elasticsearch：一个基于Lucene构建的开源分布式搜索和分析引擎，是SkyWalking的默认存储实现。适合用于全文搜索、结构化搜索、分析以及组合这些功能的场景。

  2. Apache HBase：一个开源的、分布式、版本化的非关系型数据库，基于Google的BigTable模型。

  3. MySQL：一个流行的开源关系型数据库管理系统。

  4. TiDB：一个开源的分布式SQL数据库，兼容MySQL协议。

  5. InfluxDB：一个开源的时序数据库，专门为处理高写入和查询负荷的时序数据而设计。

  6. Apache ShardingSphere：一个开源的分布式数据库解决方案，提供了对JDBC的透明读写分离和分库分表等功能。

现在具体深入每种存储的差异：

Elasticsearch

优势:

  • 水平可扩展性：通过增加节点来提升数据处理能力。
  • 高可用性：内建复制和分片机制保障数据安全。
  • 强大的分析功能：支持复杂的检索和聚合操作。
  • 社区支持强：有丰富的资源和社区支持。

劣势:

  • 资源占用量：消耗较大的系统资源，尤其是内存。
  • 跟踪数据维持期：由于数据存储的开销，往往存储的时间跨度比较有限。

Apache HBase

优势:

  • 大数据处理：适用于非结构化数据，能处理海量数据。
  • 可扩展性：可以通过添加更多的服务器来水平扩展。

劣势:

  • 复杂的维护：需要对Hadoop和ZooKeeper有一定的了解。
  • 一致性和可用性：在某些情况下CAP理论限制了其数据一致性和可用性。

MySQL

优势:

  • 广泛采用：流行的RDBMS，适用于结构化数据，易于维护。
  • 强一致性：事务支持，保障数据的强一致性。

劣势:

  • 水平扩展困难：难以像NoSQL或Elasticsearch那样通过节点增加来水平扩张。

TiDB

优势:

  • 水平扩展简单：相比MySQL更容易水平扩展。
  • 兼容MySQL协议：可用于替代MySQL。

劣势:

  • 相对较新：社区和生态较MySQL小，成熟度不如MySQL高。

InfluxDB

优势:

  • 时序数据优化：对时序数据提供了优化的存储和查询。
  • 水平可扩展性：易于部署和扩展。

劣势:

  • 特定场景：主要适用于时序数据，不适合复杂的事务性工作负载。

Apache ShardingSphere

优势:

  • 数据库中间件：不锁定特定的数据库，为多个数据库提供额外的服务。
  • 提供分片功能：简化水平扩展和分布式事务的实现。

劣势:

  • 复杂性：增加了系统架构的复杂性。
  • 额外的学习成本：需要理解它的原理和使用方式。

根据不同的监控需求、数据规模和运维能力，SkyWalking 用户可以选择最符合其业务场景的后端存储。例如，对于高吞吐量和大数据量处理能力，Elasticsearch 和 HBase 是更好的选择。而如果企业已经有成熟的MySQL基础或者偏好关系型数据库，MySQL 或 TiDB 则可能是更合适的选项。对时序数据有特殊需求的场景，则可以考虑InfluxDB。

选择合适的后端存储时，需要考虑的因素包括性能、可维护性、成本、技术栈兼容性等，不同的存储选择会直接影响SkyWalking的性能和数据管理效率。

14、在高并发的系统中，如何优化SkyWalking以减少性能开销？

在高并发系统中，监控解决方案的性能开销是一项需要特别考虑的因素。Apache SkyWalking 作为应用性能管理工具（APM），其在设计上就考虑到了对系统性能的影响，但是在极高并发的场景下，仍然需要对SkyWalking进行一些优化以减少性能开销。以下是一些针对SkyWalking的优化策略：

1. 调整采样率

在大流量的情况下，不需要对所有的交易进行追踪。SkyWalking 允许配置采样率来减少需要记录和发送到后端的数据量，例如：

  • 设置一个较低的采样率，比如每100个请求中只采样一次。
  • 使用更复杂的采样策略，比如自适应采样，在系统负载较低时增加采样率，在负载较大时降低采样率。

2. 异步处理

确保SkyWalking代理（agent）和OAP（Observability Analysis Platform）服务器可以异步处理追踪数据和指标计算。这有助于减轻同步处理可能对系统性能带来的压力。

3. 指标精简

对于指标数据，SkyWalking可以聚合和精简信息，尽量在客户端完成计算，以减少发送到后端的数据量和所需要处理的复杂度。

4. 流量削峰

在流量高峰时段，可以动态调整SkyWalking的配置参数以减少数据通过量，如调高持久化批量写入的数据量，调低数据存储频率等。

5. 后端存储调优

SkyWalking的性能很大程度上取决于其后端存储的性能。应注意选择合适的数据库，并对其进行针对性优化：

  • 对于Elasticsearch，调整索引策略，合理配置分片和副本数量，调优JVM和内存设置等。
  • 在使用HBase或者MySQL等数据库时，需要根据数据库的特性进行相应调优，包括合理设计表结构、调整缓存策略、分布式配置调整等。

6. 存储方案的选择

根据监控数据的实际使用模式选择合适的存储方案，如时序数据库优于关系数据库用于存储时间序列数据。

7. 使用消息队列

在SkyWalking的数据链路中使用消息队列，比如Kafka，提高系统处理数据的弹性和稳定性。消息队列可以充当缓冲层，帮助应对大流量冲击。

8. 管理代理状态

SkyWalking代理会维护某些状态信息，如服务注册信息、服务实例心跳等，确保这些状态的刷新机制不要过于频繁。

9. 限制日志量

日志数据可以变得非常庞大且增长迅速，考虑关闭或限制链路追踪中的日志收集功能。

10. 分布式部署

考虑对SkyWalking OAP后端进行分布式部署，使其能够水平扩展来处理更多的数据。

11. 监控告警策略

合理配置监控告警策略，避免因为大量无用告警产生的噪音和不必要的后端负载。

12. 使用 SkyWalking 的 Dynamic Configuration Service

使用SkyWalking的动态配置服务动态调整运行时配置，而无需重启服务。

13. 智能化降级与自适应控制

在高并发环境下，当监控系统自身承载压力过大时，应该具备自适应控制和智能化降级的能力，比如动态调整采样率，或暂时关闭数据处理链的某些部分。

实际操作时，建议先从影响最大并且最容易实施的优化开始，可以参考系统的监控数据及性能测试结果，有针对性地进行优化。此外，高并发系统的性能优化是一个持续的过程，需要不断地监控、评估和调整。

15、SkyWalking如何对跟踪数据进行采样？采样的策略有哪些？

Apache SkyWalking 使用采样技术来减少性能监测对被监控服务的性能影响，以及降低SkyWalking自身处理和存储跟踪数据的负担。SkyWalking 提供了几种不同的采样策略，使开发者和运维人员可以根据自己的需要选择最适合的采样方式。

1. 定率采样（Fixed Rate Sampling）

这是最简单也是最常见的采样策略，即预先定义一个固定的采样率，例如采样率设置为 1，意味着会跟踪所有的请求；设置为 n（n>1）则意味着系统会对每n个请求中的一个进行跟踪。例如，如果采样率设为10%，那么每10个请求中，只有1个请求的跟踪数据会被记录和发送到SkyWalking后端进行分析。

这种策略易于理解和实现，但它不会考虑请求的类型或重要性，可能会漏掉关键请求的数据。

2. 概率采样（Probabilistic Sampling）

概率采样通过设置一个概率值，来决定每个请求是否被采样。与定率采样类似，但对每个请求都通过一个随机过程单独决定是否进行跟踪。例如，如果设置采样概率为 0.1，则每个请求有10%的机会被选中用于跟踪。

概率采样可以让高流量系统以一种统计意义上可预测的方式降低监控数据量，同时依然能反映整个流量的概况。

3. 适应性采样（Adaptive Sampling）

适应性采样是一种更智能化的策略，它根据服务节点的实际性能和/或后端SkyWalking OAP服务器的当前负载来动态调整采样率。这种方法能够确保在服务压力不大时能够捕获到更多的跟踪信息，而在服务负载较重时减少采样以降低对性能的影响。

适应性采样通常需要复杂的逻辑来识别系统何时过载，并相应地调整采样率。

4. 百分比采样（Percentage-Based Sampling）

受概率采样的启发，百分比采样维护一个请求通过的百分率，比如设置为 20%，则意味着系统大约会采集所有请求的 20%。它比概率采样更精确些，因为它利用了滑动时间窗口来保证采样率在整体上符合设定的百分比。

这种方式有助于在实时流量波动中对采样率进行平滑处理。

5. 负载感知采样（QPS-Based Adaptive Sampling）

SkyWalking提供了基于QPS（每秒查询率）的自适应采样策略。负载感知采样策略可以依据系统当前的QPS自动调节采样率，以此来控制后端处理的数据量。高QPS时降低采样率，低QPS时提高采样率。

因服务和代理自身的负载情况不同，这个策略要求在实际应用中进行详细的分析和测试，以找到最佳的调节函数。

6. ID透传采样（TraceID Pass-through Sampling）

这种方法依靠跟踪ID，如果一次请求被采样，关联的后续请求（如远程调用）也会被采样，从而保证了一个完整的链路在被调用链中始终可追踪。

ID透传采样适用于分布式微服务架构，确保一次事务的所有微服务调用全部被跟踪记录下来。

7. 规则采样（Rule-Based Sampling）

在这种策略中，开发者可以定义符合某些特定规则的交易进行采样。这些规则可以基于请求的属性，如URL、参数、IP地址或其他请求头信息。

规则采样允许高度的定制化和精细的控制，可以确保对关键交易的监控，但同时也增加了配置和维护的复杂度。

当应用SkyWalking到不同环境中时，您应实行一个分阶段的过程，从最简单的采样方法开始，逐步调优至更先进的策略，找到满足性能监测需求和系统资源限制的最佳平衡点。需要注意的是，所有采样策略都会有数据损失，对于分析造成的影响必须进行评估。在决定采样策略时，除了考虑到系统负载以外，还需要考虑监控目标和性能诊断的需求。

16、SkyWalking对比

Apache SkyWalking 与其他应用性能管理（APM）和观测工具比较时，有数个关键维度需要被考虑，包括功能、架构、易用性、可扩展性、社区支持和成本。下面详细比较SkyWalking与其他几个流行的APM和监控工具，比如Pinpoint、Jaeger和Prometheus。

SkyWalking 与 Pinpoint

Pinpoint是另一个开源APM工具，专注于大规模分布式系统的性能监控。以下是两者的对比：

功能对比:

  • SkyWalking提供了强大的链路追踪功能，同时集成了指标监控、拓扑图分析、告警和日志分析等综合性能管理特性。
  • Pinpoint同样提供了链路追踪和指标监控，也有一定程度的拓扑图分析和告警功能，但在日志方面则没有SkyWalking全面。

架构对比:

  • SkyWalking和Pinpoint都使用了Agent端收集数据的模式，但SkyWalking的OAP后端更倾向于云原生支持，可以更好地与Kubernetes等容器技术结合。
  • Pinpoint的后端存储选项较少，主要是HBase。

易用性和可扩展性:

  • SkyWalking的用户界面相较于Pinpoint来说可能更现代一些，而且由于有更活跃的社区，用户能够获得更多的文档和第三方插件。
  • Pinpoint提供了直观的链路追踪视图，但在功能的扩展和自定义方面不如SkyWalking灵活。

社区和成本:

  • 两者都是免费且开源的，用户只需要负担运维成本。
  • SkyWalking社区相比Pinpoint来说更活跃，这可能会在需要支持和开发新功能时有所帮助。

SkyWalking 与 Jaeger

Jaeger是一个由Uber开源的链路追踪系统，其核心功能专注于分布式追踪。

功能对比:

  • Jaeger主打分布式事务监控，提供了全面的链路追踪工具，但是在性能指标和日志分析等方面没有SkyWalking提供的全面。
  • SkyWalking除了提供分布式追踪外，还集成了对服务性能指标的监控和告警、拓扑图分析和日志收集等功能，是一个更加全方位的APM工具。

架构和易用性对比:

  • Jaeger的设计允许它轻松集成到已经存在的监控体系（如带有Prometheus）中。
  • SkyWalking提供类似的集成功能，但它自身的生态系统更为封闭，大多数功能和工具都是内建的。

SkyWalking 与 Prometheus

Prometheus是一个开源监控解决方案，主要集中在指标收集和告警，而不是APM。

功能对比:

  • Prometheus非常擅长处理时序数据指标，提供强大的查询语言PromQL，用户可以通过这种语言来检索和分析数据。
  • SkyWalking，则在链路追踪和应用拓扑分析上有更深入的支持，它可以提供请求级别的细节，而Prometheus更多的是聚焦于系统级别的指标。

易用性和可扩展性对比:

  • Prometheus有一个相对简单的架构，易于安装和维护，适合快速部署。
  • SkyWalking的设置可能更复杂，特别是当涉及到微服务和分布式追踪的配置时。

综合来说，选择哪个工具需要根据组织的具体需求、现有的基础设施、团队技能以及预算来决定。SkyWalking是一个适合需要全面APM功能，包括链路追踪、性能指标、告警和日志分析的组织。而Jaeger和Pinpoint可能更适合只需要链路追踪的组织。如果你的需要倾向于指标监控和告警，Prometheus可能是一个更好的选择，而且还能与其他工具如Grafana进行集成以提供丰富的可视化。

17、SkyWalking在使用时的注意事项

Apache SkyWalking 作为一款重要的应用性能管理（APM）工具，广泛应用于监控微服务、云原生和容器化部署的应用程序。在部署和使用 SkyWalking 时，有一些关键的注意事项可以帮助你最大化其价值，同时避免可能的问题。

环境兼容性

  • 环境支持：确认 SkyWalking 支持你所使用的编程语言和框架。SkyWalking 主要支持 Java，但也提供了对其他语言的支持，如 .NET, Node.js, PHP 等。
  • 服务依赖：确定你的服务依赖与 SkyWalking 兼容，SkyWalking 支持的库列表应该与服务使用的库版本保持一致。

性能影响

  • 资源使用: 理解 SkyWalking Agent 和后端的资源需求，确保系统有足够的内存和CPU来支持监控操作。
  • 数据采样：为减少对应用性能的影响，评估和配置适当的数据采样策略，比如针对高流量应用调整采样率。

配置和维护

  • 精确配置: 仔细阅读和理解配置参数，以确保 SkyWalking 的 Agent 和后端系统配置得当。不恰当的配置可能会导致数据丢失或性能问题。
  • 版本控制：定期检查并更新到最新版的 SkyWalking，以利用最新功能和性能优化，同时修复已知的漏洞。

数据存储

  • 选择存储：选择合适的存储后端。SkyWalking 支持 Elasticsearch、MySQL、TiDB 等存储方式。选择应依据数据量和查询效率需求。
  • 数据保留政策：根据业务需求配置数据保留政策，以避免存储成本过高。

高可用性与扩展性

  • 集群部署：在生产环境中考虑使用 SkyWalking 集群部署，以确保监控系统本身的高可用性。
  • 负载均衡：合理分配 SkyWalking 后端的负载，确保大规模数据处理时的系统稳定性。

安全性

  • 安全措施：确保 SkyWalking 后端组件的网络安全，特别是在云环境中，使用安全组或网络策略限制访问。
  • 敏感数据处理：确定 SkyWalking 追踪的数据不包含任何敏感信息，诸如个人身份信息（PII）等。

监视和告警

  • 监控 SkyWalking 本身：除了监控应用性能外，还应监控 SkyWalking 系统本身，特别是其后端服务。
  • 配置告警: 根据业务重要性设立告警阈值，及时响应可能的性能问题。

用户界面和访问

  • 用户访问: 管理和控制用户访问 SkyWalking UI 的权限，确保只有授权人员能够访问监控数据。
  • 数据解读：确保团队成员知晓如何解读 SkyWalking 提供的度量和追踪数据。

部署和迭代

  • 小规模开始：初始时在小规模的环境中部署 SkyWalking，逐步扩展到更大的环境中。
  • 迭代调整：根据性能指标和反馈不断迭代 SkyWalking 的配置，优化监控效果。

社区和支持

  • 社区支持：积极利用 SkyWalking 社区获取帮助，社区支持的及时性和有效性通常能够解决多数问题。
  • 文档和培训：利用官方文档和培训资源来提高团队对于 SkyWalking 的理解和使用效率。

测试和模拟

  • 移动测试：在将 SkyWalking 推广到生产环境前，进行充分的测试，确保它不会干扰应用的正常运行。
  • 故障模拟：定期进行故障模拟，验证 SkyWalking 在应对系统故障时的行为和性能。

综上所述，成功部署和使用 SkyWalking 需要综合考虑众多因素，从性能影响，到数据处理和存储，再到安全性和高可用性。事先策划和持续调优是确保 SkyWalking 有效支持你的监控需求的关键。

18、

文章来源:https://blog.csdn.net/qq_43012298/article/details/135436311
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。