微服务可观测性模式

大纲（优先看）

微服务可观测性模式的上下文：

多台机器上、多个服务和服务实例
请求会跨越多个服务实例，每个服务执行一个或多个操作来处理请求
跟踪用户行为和代码异常
服务实例可能存在问题，仍在运行但无法处理请求

问题背景：

如何理解用户和应用程序的行为并解决问题
如何检测正在运行但无法处理请求的服务实例

微服务可观测性模式列表如下：

日志聚合
审计日志
应用程序指标
分布式追踪
异常跟踪
健康检查API

模式关系：

日志聚合模式

问题背景：如何理解应用程序的行为解决问题？

需求：任何解决方案都应该具有最小的运行时开销

日志聚合模式：

使用集中式日志记录来自每个服务实例的日志
用户可以搜索和分析日志
可以配置警报，只要检测到某些消息出现在日志中（告警机制）

缺点

处理大量日志时需要大量基础设施

审计日志模式

问题背景：如何理解用户和应用程序的行为并检测定位问题？

需求：了解用户最近执行了哪些操作，为用户提供帮助，确保合规性，发现可疑行为等。

审计日志模式：

向业务逻辑中添加审计日志代码
创建审核日志条目并保存在数据库中

优点

提供用户操作的记录

缺点

审计代码和业务逻辑交织，业务逻辑被复杂化了

应用程序指标模式

问题背景：如何理解应用程序的行为并检测定位问题？

需求：任何解决方案都应该具有最小的运行时开销

应用程序指标模式：

检测服务以收集各个操作的统计信息，在指标服务中聚合指标提供报告和警报，聚合指标有两种模型：
- push：将指标推送到指标服务
- pull：指标服务从服务中提取指标
比如Prometheus

优点

提供对应用程序行为的深入洞察

缺点

指标代码和业务逻辑交织，业务逻辑更复杂了
聚合指标可能需要大量基础设施

分布式追踪模式

问题背景：和上面一样

需求：

外部监控只报告总体响应时间和调用次数，无法深入了解各个操作
方案要有最小运行时间开销
请求的日志条目分散在许多日志中

分布式追踪模式：

记录单次请求范围内的消息
为每个外部请求分配一个唯一ID
记录请求如何从一个服务流向下一个
所有日志消息包含外部请求的ID
记录在集中服务中处理外部请求时执行的请求和操作信息（比如起止时间）

优点

提供对系统行为的洞察，包括延迟来源
使开发人员能够在聚合日志中搜索外部请求的ID来查看单个请求如何处理

缺点

聚合和存储追踪数据可能需要大量基础设施

异常跟踪模式

上下文：服务实例处理请求时可能出错并抛出异常，这里面有错误消息和堆栈跟踪

问题背景：和上面一样

需求：

异常必须由开发人员去重、记录并尝试解决
最小运行时间开销

异常跟踪模式：

向集中式异常跟踪服务报告所有异常，这个集中式异常跟踪服务会聚合、跟踪异常并通知开发人员

优点

更容易查看异常并跟踪解决方案

缺点

优点的实现需要额外基础设施

健康检查API模式

问题背景：如何检测那些正常运行但无法处理请求的实例？

需求：服务实例失败时告警，并把请求路由到正常工作的服务实例

健康检查API模式：

有专门的健康检查API返回服务健康状态（比如SpringBoot Actuator）
监控服务、服务注册表或负载均衡会定期ping调用端点来检查服务实例健康状态

优点

可以定期诊断服务是否健康

缺点

不全面
健康检查间隔时服务可能挂掉

微服务可观测性模式

微服务可观测性模式

大纲（优先看）

日志聚合模式

缺点

相关模式

审计日志模式

优点

缺点

相关模式

应用程序指标模式

优点

缺点

相关模式

分布式追踪模式

优点

缺点

相关模式

异常跟踪模式

优点

缺点

相关模式

健康检查API模式

优点

缺点

相关模式