/tags/kafka/ Recent content in kafka on Hugo -- gohugo.io en Tue, 28 Apr 2026 10:30:00 +0800 /posts/spring-boot-resilience4j-external-calls-best-practices/ Tue, 28 Apr 2026 10:30:00 +0800 /posts/spring-boot-resilience4j-external-calls-best-practices/ 背景 Spring Boot 3.5 配合 Java 25，已经把“同步写法 + virtual threads”这条路线变成了很现实的工程选择。JDK 在 JEP 444 里把 virtual threads 的目标讲得很清楚：让 thread-per-request 风格更容易扩展；Spring Boot 官方文档也提供了 spring.threads.virtual.enabled=true 这条开关入口。 于是一个常见问题会重新冒出来：当一个微服务会同时访问 HTTP 下游、Redis、Kafka、数据库时，Resilience4j 应该怎么用？ 这篇文章不是“所有外部调用统一套一层 Resilience4j 模板”的教程，而是一篇事实约束下的探索综述。文中的强结论优先建立在仍在维护的官方资料和工程文档上，例如 Spring / Resilience4j、AWS Builders Library、Azure Architecture Center、Google Cloud retry strategy、Redis 官方文档、Spring for Apache Kafka 文档 和 PostgreSQL 文档。少量技术文章和 case study 只用来补充上下文，不会单独支撑“行业定论”。 如果你使用的是 resilience4j-spring-boot3，或者使用 Spring 生态提供的 Spring Cloud CircuitBreaker + Resilience4j，本文的判断原则都成立；区别更多在接入方式，而不在策略本身。 为什么这篇文章只讨论“按 dependency + operation semantics 设计策略” 我对这个问题最核心的判断是： Resilience4j 不应该按“所有外部调用统一套模板”来使用，而应该按具体 dependency 与操作语义来设计。 /posts/api-event-contract-compatibility-qa-2026/ Sat, 25 Apr 2026 10:00:00 +0800 /posts/api-event-contract-compatibility-qa-2026/ 📦 本文基于的完整项目源码：meirongdev/shop 上一篇 微服务 contract 兼容性的五层防线：从 ArchUnit 到 japicmp 讨论了如何用 ArchUnit、japicmp、WireMock 和运行时 Deprecation 头构建基础安全带。本文聚焦更具体的问题：BFF 对外的 API、BFF→MS 和 MS→MS 的内部 API、以及 Kafka 事件，各自应该用什么工具保障 contract 兼容性，这些工具的工作机制是什么。 一、两类 contract，两种保障方式 Q：BFF 对外暴露的 API 和 BFF→MS、MS→MS 之间的内部 API，兼容性的保障方式应该一样吗？ 在我的实践中不太一样。主要原因在于 source of truth 不同。 BFF 对外的 API（前端、移动端、三方调用方）采用的是 API-first 方式：先有 OpenAPI YAML，生产者的 controller 实现这份 YAML，消费者根据这份 YAML 生成客户端代码或手写调用。在这条链路里，YAML 就是权威来源。保障兼容性就是保障 YAML 文件本身不引入 breaking change。 BFF→MS 和 MS→MS 之间采用的是 code-first 方式：Java record 是 source of truth，没有提前写 spec，序列化层（Jackson）从 record 推导出 JSON 结构。保障兼容性就是保障 Java record 的 JSON 表现形式不引入 breaking change。 /posts/java-contract-scc-poc-recap/ Tue, 14 Apr 2026 10:10:00 +0800 /posts/java-contract-scc-poc-recap/ 这篇文章可以看作 《Contract First 工作流：让 AI 帮你写 OpenAPI YAML》 的实现篇。上一篇讨论的是“spec 如何成为协作中心”；本文只讨论当接口边界已经确定之后，JVM 团队如何把contract变成验证、stubs 和 CI Quality Gates。 微服务接口兼容性的问题，通常不是在设计阶段暴露，而是在某个 PR 合并之后才通过联调、回归测试，甚至线上流量被发现。这个 java-contract 仓库的目的，就是把这类问题尽量前移到提交阶段，用 contract testing 把 producer 和 consumer 之间的接口约束固定下来。 这篇文章不打算再展开 AI 生成 OpenAPI、style guide 或 breaking change 治理这些协作层话题。它更像是一次基于当前仓库完成态的工程复盘：为什么这个 Java 25 + Spring Boot 3.5 + Maven 多模块项目最终选择了 Spring Cloud Contract，contract如何在仓库里流动，以及这套做法如何进入 CI，成为一条可执行的兼容性 Quality Gates。 项目代码：github.com/meirongdev/java-contract 有了 OpenAPI 和集成测试，还需要 SCC 吗？ 采用 Contract First 工作流的团队常会遇到这个问题。我的理解是：三者关注的粒度不同，不互相替代。 OpenAPI spec 描述的是接口形状：字段、类型、必填约束、状态码有哪些。集成测试验证的是系统整体行为：多个服务部署在一起能否跑通。SCC 填的是中间那层——接口行为：在某个具体场景下，一次请求会得到什么确定性响应，且这个断言在提交阶段就能被执行。 以 /users/{id} 为例。OpenAPI 会告诉你： /posts/spring-boot-kafka-best-practices/ Fri, 10 Apr 2026 10:00:00 +0800 /posts/spring-boot-kafka-best-practices/ 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 在 Shop Platform 的事件驱动架构中，Apache Kafka 3.9（KRaft 模式）是服务间异步通信的核心基础设施。Spring Boot 3.5 结合 Spring Kafka 3.3 提供了开箱即用的 Kafka 集成，但要把 Kafka 用得稳、用得好，还需要理解底层的并发模型、序列化策略、offset 语义以及错误处理机制。 本文从六个维度整理 Spring Boot 3.5 下 Kafka 的一些实践记录。文中的“现状判断”都以 shop 项目的实际实现为准，额外的代码片段会明确视为建议写法，而不是仓库已经落地的事实。 生产者调优：acks、retries 和 linger.ms acks 配置 acks 决定了生产者需要等待多少个 broker 副本确认后才认为发送成功： acks 值 含义 可靠性 延迟 acks=0 不等待任何确认 最低（可能丢消息） 最低 acks=1 Leader 确认即可 中（Leader 宕机丢消息） 低 acks=all 所有 ISR 副本确认 最高 高 Kafka 生产者文档里的默认值仍是 acks=1。对于事件驱动架构中承载业务事实的事件（如订单事件、钱包事件），更稳妥的做法仍然是显式写成 acks=all： spring: kafka: producer: acks: all 参考：Apache Kafka Producer Configs - acks、Confluent: Understanding Kafka acks /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/shop-platform-event-driven/ Sat, 04 Apr 2026 10:00:00 +0800 /posts/shop-platform-event-driven/ 在之前的文章中，我们看了同步请求链路上的 Gateway → BFF → 领域服务。但微服务架构中并不是所有交互都适合同步发生。事件驱动架构让服务之间通过异步消息协作，在不少场景下用最终一致性换取更低耦合和更好的链路弹性。 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 上一篇：（四）领域服务设计 2026-04 实践更新 当前主线仓库已经把 IdempotencyGuard + Redis Bloom Filter、补偿任务重试、以及关键 Kafka consumer 的幂等保护补齐到 Phase 1 基线；本文整体设计仍然准确，但“待补齐”的幂等链路请以当前 main 分支实现为准。 为什么用事件驱动 在 Shop Platform 中，异步事件主要用来承接那些不必阻塞用户请求、但又需要可靠传播的业务事实。例如： flowchart TD Order["用户下单order-service"] Stock["扣库存marketplace-service"] Points["发积分loyalty-service"] Email["发邮件通知notification-service"] Webhook["推送外部订阅webhook-service"] Order -->|"同步 需要立即确认"| Stock Order -.->|"异步 可以延迟"| Points Order -.->|"异步"| Email Order -.->|"异步"| Webhook 如果全部走同步 HTTP 调用： 下单接口响应时间 = 最慢下游服务的响应时间 任意下游服务不可用 → 下单失败 服务间耦合紧，新增消费者需要修改生产者 事件驱动的方式： flowchart LR OS["order-service写入订单 + outbox同一事务"] Pub["Outbox Publisher"] Kafka["Kafkaorder.events.v1"] L[" /posts/confluent-kafka-partition-count-evaluation/ Mon, 30 Mar 2026 10:04:30 +0800 /posts/confluent-kafka-partition-count-evaluation/ 背景 我们的项目使用 Confluent Cloud 托管 Kafka 集群，在上线前需要确定每个 topic 的分区（partition）数量。Kafka 的分区数只能增加不能减少，因此更适合在初始阶段先做一轮带假设前提的评估。 本文记录这一评估过程。 业务规模 基础数据 (单 Topic) 参数 数值 单 Topic 日均消息量 4 亿条 活跃用户数 ~200 万 人均日均交易笔数 200 笔 每笔交易产生消息数 1 条 Topic 数量 约 60 个 集群日均总消息量 约 240 亿条 单 Topic RPS 推导 单 Topic 全天平均 RPS = 4亿 ÷ 86,400秒 ≈ 4,630 交易流量并非均匀分布。假设流量集中在约 8 小时的活跃窗口内： 单 Topic 活跃时段平均 RPS = 4亿 ÷ (8 × 3,600秒) ≈ 13,900 活跃窗口内还存在早晚高峰，峰值通常为活跃时段均值的 2–3 倍： /posts/confluent-kafka-connection-count-spring-boot/ Thu, 12 Mar 2026 06:00:00 +0800 /posts/confluent-kafka-connection-count-spring-boot/ When selecting a Confluent Cloud plan, one of the first limits you’ll hit is the maximum connection count. Enterprise clusters allow 18,000 connections per eCKU (raised 4× in the Q3 2025 update); Standard cluster limits are lower — check the current cluster types table for the exact figure. Miscounting by even one component can push you into throttling territory. This post gives you a practical formula for estimating connections in a Spring Boot application, explains what actually drives that number, and ends with a worked example for a multi-service deployment.