/tags/microservices/ Recent content in Microservices on Hugo -- gohugo.io en Mon, 04 May 2026 10:00:00 +0800 /posts/microservices-boundary-governance-2019-2026/ Mon, 04 May 2026 10:00:00 +0800 /posts/microservices-boundary-governance-2019-2026/ 2023 年，Amazon Prime Video 公开了一个架构优化案例：他们把一个音视频质量监控 pipeline 从分布式 serverless 组件合并成单进程应用，运营成本降了 90%。很多转述把它概括成「Amazon 放弃微服务」，但这恰恰是最没有价值的读法。 更有价值的问题是：为什么这些大公司在不同阶段做出了完全不同的架构选择？为什么有的继续扩展几千个微服务，有的把某条链路合并回进程内，有的坚持模块化单体，有的把治理重点从服务迁移到 cell、supergraph、data contract？ 下面这七个案例不是为了证明「微服务好」或「单体好」。它们更像七个坐标点，帮助我们判断：在什么规模、约束和组织形态下，服务边界的收益还能不能覆盖它带来的成本。 七个案例 Amazon Prime Video — 把一条高吞吐 pipeline 合并回单进程（2023） 做了什么： Prime Video 的 Video Quality Analysis 团队原本用 Step Functions、Lambda、S3 等 serverless 组件串起音视频质量检测流程。后来他们把媒体转换、检测器和编排逻辑合并到一个进程内运行，部署在 ECS/EC2 上，减少了中间数据搬运和编排状态跳转。 为什么： 主要瓶颈不是业务计算，而是编排和数据移动成本。每秒视频流会触发多次 Step Functions state transition，容易撞到账户限制；视频帧通过 S3 在组件之间传递，读写量和费用都很高。合并后，帧数据在内存里传递，编排逻辑也从外部状态机变成进程内控制流。 容易被误读的地方： 这不是 Prime Video 放弃微服务，而是一个特定工作负载上的边界重画。这个案例的价值在于提醒我们：当一条链路里的数据移动和编排开销超过业务计算本身时，服务拆分就不再是免费的抽象，而是可以被量化的成本。 Monzo — 接近 3,000 个微服务后的中央治理（2022–2026） 做了什么： Monzo 长期运行大规模 Go 微服务。2022 年他们公开提到 2,000+ 服务；2024 年迁移文章里数字已经到 2,800+；同年另一篇限流文章把规模描述为接近 3,000 个微服务。 关键在哪： Monzo 的重点不是「服务数量多很厉害」，而是他们选择了高度一致的技术栈、monorepo、统一平台和中央驱动迁移。比如把 tracing 从 OpenTracing/Jaeger SDK 迁到 OpenTelemetry SDK 时，Monzo 不是让每个服务 owner 自己慢慢改，而是由一个团队设计 wrapper、自动化修改 call site、批量部署，再用配置系统灰度打开。 /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/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/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. /posts/spring-boot-3-http2-h2-h2c/ Tue, 10 Mar 2026 11:00:00 +0800 /posts/spring-boot-3-http2-h2-h2c/ 写在前面 想给你的 Spring Boot API 提提速？开启 HTTP/2 (H2) 可能是成本最低、收益最高的方式之一。比起老掉牙的 HTTP/1.1，H2 靠着多路复用、头部压缩这些黑科技，能让你的请求跑得更快、更稳。 但在 Spring Boot 3 里动手前，你得先搞清楚两个概念：h2 和 h2c。别看只差一个字母，用法可是天差地别。 h2 vs. h2c：穿衣服还是“裸奔”？ 简单来说，这两者的区别就在于有没有 TLS（加密）： h2 = HTTP/2 Over TLS（穿了防弹衣，安全，生产环境标配） h2c = HTTP/2 Cleartext（“裸奔”，明文传输，主打一个快） 1. 核心大比拼 特性 h2 (HTTP/2) h2c (HTTP/2 Cleartext) 安不安全？ 非常安全 (TLS) 不安全 (明文) 浏览器理你吗？ 所有现代浏览器都支持 浏览器基本都不支持 用在哪？ 公网、APP 接口 微服务内网、K8s 集群、gRPC 配置难吗？ 需要 SSL 证书 Spring Boot 3.5 以后一行配置搞定 2. 怎么配 h2？(带加密模式) 这是我们最常见的模式，毕竟为了安全，Chrome、Firefox 这些浏览器只认带加密的 HTTP/2。 怎么配：你需要个 KeyStore 证书，然后在 application.