微服务监控的原因

• 问题定位：在微服务架构中，客户端（如 PC 端、APP 端、小程序等）请求后台服务需经过网关再路由到各个微服务，服务间可能存在多链路调用。当某一微服务挂掉时，在复杂的调用链路中难以迅速确定是哪个微服务出现问题。例如，PC 端查询数据可能经过网关、多个微服务最终到数据库，若其中服务 K 挂掉，很难直接定位到它。
• 性能分析：若服务链路中某个接口响应时间较长（如超过两秒），由于涉及多个微服务，很难快速判断是哪个服务的接口导致的性能问题。比如，在一个链路中，服务 H、服务 K 到 MySQL 的调用过程中，如果接口响应慢，难以确定是服务 K 等哪个环节出现问题。
• 服务关系：微服务之间可能会进行远程调用，在项目规模较小时，人工或许还能理清服务间的关系，但当项目足够大，微服务数量达到上百个甚至上千个时，靠人工维护服务之间的调用关系就变得不现实。例如，服务 A 调用服务 G、H，服务 H 又调用服务 K，服务 D 也调用服务 K 等复杂关系，大规模项目中难以人工梳理。
• 服务告警：当服务链路出现问题时，需要能够及时知晓是哪个服务出现问题，以便快速响应和处理，这就需要有相应的告警机制。比如服务 K 出现问题时，应能迅速得到通知。

常见服务监控工具

• Spring Boot - admin：可监控普通微服务的状态信息，但功能相对单一，在实际应用中较少采用。
• Prometheus + Grafana：是比较全面且功能强大的监控工具，但存在搭建过程复杂的问题。
• Zipkin：作为 Spring Cloud 推荐的链路追踪工具，其与代码存在耦合关系，因此不再使用。
• SkyWalking：是一个分布式系统的应用程序性能监测工具（APM 工具），具有完善的链路追踪能力。在一些项目中会直接采用它进行监控。

SkyWalking 基础概念

• 服务（Service）：每个微服务都可看作一个服务，如 user-service、order-service 等，网关也属于服务范畴。
• 端点（End point）：指服务对外暴露的功能接口，例如 api/user/login 等接口就是端点，是服务与外部交互的关键部位。
• 实例（Instance）：也称为物理机，一个微服务部署到不同的服务器上就会产生不同的实例，如 user service 部署到 200.100 和 101 等不同 IP 的服务器上，这些就是不同的实例，数据库也可看作一个实例。

SkyWalking 功能演示

• 仪表盘（Dashboard）

  • 展示已集成 SkyWalking 的微服务信息，如黑马 news app 网关、article、user 等微服务。
  • 呈现慢服务、不健康服务及慢接口排名，例如文章服务可能在慢服务和慢接口排名中较为靠前，通过这些信息可快速定位出性能较差的微服务和接口，为后续优化提供方向。

• 追踪性能分析（Tracing Performance Analysis）

  • 能够分析接口加载耗时情况，如 api/v1 接口经过网关和文章服务的时间，通过不同颜色区分各服务的加载时间，如紫色代表网关加载时间，蓝色代表文章服务加载时间。
  • 可以定位问题所在，比如发现是 spring mvc 方法导致接口慢，可进一步查看代码分析原因，还能展示数据库连接相关信息及查询的 SQL 语句，辅助分析性能问题。
    

• 拓扑图（Topology Graph）：清晰呈现服务间调用关系，包括与数据库（如 MySQL、Redis）的调用关系，并且会将不健康的服务标红，方便直观了解服务架构健康状况和服务间的依赖关系，即使在服务数量较多的情况下也能清晰展示。

• 告警（Alerting）

  • 具有默认告警规则，如过去十分钟内三分钟内服务平均响应时间超过一秒且超过三次，或过去十分钟内服务成功率低于 80%达两次等情况就会触发告警。
  • 支持自定义告警规则，且告警信息可通过多种方式（如发送邮件、短信、对接企业微信或钉钉）通知开发负责人，确保问题能及时被处理，保障线上服务的正常运行。

面试题回答思路

• 首先表明采用 SkyWalking 对微服务进行监控。
• 介绍 SkyWalking 的功能，包括它能够监控接口、服务和实例的状态，例如在压测等场景下可快速定位出慢的服务和接口，并对其进行分析和优化；强调其报警功能，当项目上线后，若出现问题可及时通知相关负责人，通过短信或邮件等方式，确保线上服务稳定运行。