/tags/micrometer/ Recent content in micrometer on Hugo -- gohugo.io en Fri, 24 Apr 2026 20:00:00 +0800 /posts/shop-starter-http-client/ Fri, 24 Apr 2026 20:00:00 +0800 /posts/shop-starter-http-client/ 代码背景来自开源项目 meirongdev/shop，Java 25 + Spring Boot 3.5 + Spring Cloud 微服务电商平台。 本文讲设计——starter 内部为什么这么写。如果你的目标是集成 starter，跟着步骤跑通第一个客户端，请直接看 shop-starter-http-client 集成指南。 配套阅读：Spring Boot 3.5 微服务 tracing 为什么会断链。 1. 背景 项目是典型的 BFF（Backend For Frontend）模式： graph LR C[Client] --> G[api-gateway] G --> BB[buyer-bff] G --> SB[seller-bff] BB --> M[marketplace] BB --> O[order] BB --> L[loyalty] BB --> P[promotion] SB --> M SB --> O 每个 BFF 都要向多个 domain service 发出站请求。shop-starter-http-client 把以下四件事提取到共享 starter，避免每个 BFF 重复实现： 关注点 由谁负责 身份传播 TracingHeaderInterceptor：Micrometer Baggage → 直接 HTTP header 错误语义保留 SharedDownstreamErrorHandler：4xx/5xx → DownstreamException（带原始状态码） 可观测性 DownstreamServiceObservationConvention：metric / span 加 downstream. /posts/shared-http-client-tracing-2026/ Mon, 13 Apr 2026 02:00:00 +0800 /posts/shared-http-client-tracing-2026/ 本文代码背景来自开源项目 meirongdev/shop。 如果你看过上一篇 Java 项目怎么做 contract testing：一次 Spring Cloud Contract 实践，那篇文章讨论的是"接口兼容性边界"；这一篇讨论的是"调用链可观测性边界"。 Tracing 断链时，该换客户端还是换设计？ 在一个典型的 Spring Boot 3.5 微服务架构里，当 tracing 断链时，很多团队的第一反应是换一个更优雅的 HTTP 客户端抽象方式，比如用 @HttpExchange 替代手写 RestClient，或者抽一个公共客户端。但这往往不是问题的核心。 实际请求通常会经过： api-gateway -> buyer-bff / seller-bff -> order-service / profile-service / wallet-service ... 如果链路里某一跳自己 new 了一个 HTTP client，或者只会复制业务 header、不会传播 trace context，结果通常就是： Grafana Tempo 里看到 trace 断链，下游服务冒出新的 traceId 日志里虽然有 traceId，但 buyerId、sellerId、orderId 这种业务上下文又丢了 不同服务对 header 的处理方式各自为政，后面越改越乱 所以这篇文章不再把 @HttpExchange 当主角，而是先回答更本质的问题： 在 Spring Boot 3.5 微服务架构中，怎样设计一套稳定的 tracing 传播方案，让 trace context 和业务上下文都能跨服务连续传播？ /posts/spring-boot-35-tracing-best-practices/ Tue, 07 Apr 2026 14:00:00 +0800 /posts/spring-boot-35-tracing-best-practices/ 前言 Distributed Tracing 要解决的核心问题是：一次请求经过多个服务、多个组件，出了问题之后能在哪里、花了多少时间、失败在哪一层。Spring Boot 3.5 + Micrometer Tracing + OTel Bridge 的组合，让绝大多数 span 的生成和传播不需要任何手动代码。 本文分两部分：前半部分把 tracing 跑起来（依赖、配置、自定义埋点、组件接入、上下文传播），后半部分覆盖生产环境的关键决策（Agent 选型、采样策略、PII 处理、规范守护）。 一、自动配置覆盖了什么 在开始写任何代码之前，先了解 Spring Boot 3.5 开箱即得的范围，避免重复造轮子。 场景 自动生成的 Span 触发条件 HTTP 入站请求 http.server.request spring-boot-starter-web 或 webflux RestClient / RestTemplate 出站 http.client.request micrometer-tracing 在 classpath WebClient 出站 http.client.request spring-boot-starter-webflux JDBC / Spring Data JPA db.query datasource-micrometer-spring-boot（需额外依赖，见 §五） Redis（Lettuce） db.redis spring-data-redis + tracing bridge Kafka producer messaging.publish spring-kafka + observation 开关（见 §五） Kafka consumer messaging. /posts/spring-boot-35-metrics-best-practices/ Mon, 06 Apr 2026 10:00:00 +0800 /posts/spring-boot-35-metrics-best-practices/ 为什么 Metrics 是可观测性的基础信号 在日志、链路追踪（Traces）和 Metrics 三大可观测性信号中，Metrics 往往是最先被告警系统用到的那个。 Metrics 是聚合数据：它告诉你"过去 1 分钟，/api/hello 接口平均延迟 320ms，错误率 0.3%"。日志是个体事件：它记录每一次请求的具体参数。两者不是替代关系，而是分工：Metrics 负责趋势感知和告警触发，日志负责单点定位和细节还原，链路追踪负责调用链拼接。 RED 方法论是 Metrics 最重要的一套设计框架，适合所有面向用户的服务： 指标 英文 含义 请求速率 Rate 每秒处理多少请求 错误率 Error 失败请求占比 请求耗时 Duration P50 / P95 / P99 延迟分布 本文以 springboot3.5-otel 项目（三服务微服务架构）为参考，整理一次 Spring Boot 应用层 Metrics 埋点实践。虽然该项目通过 OTel Collector 导出 Metrics，但本文大部分应用层代码对直接使用 Prometheus 的团队同样适用——因为埋点 API 是 Micrometer 的抽象层，与后端无关。 一、Spring Boot Metrics 技术栈：后端无关的 Micrometer 抽象 Micrometer 的核心价值 Micrometer 是 Spring Boot 的 Metrics 门面（类似 SLF4J 之于日志），它提供统一的埋点 API，在应用层之上屏蔽了不同监控后端的差异：