/tags/http2/ Recent content in http2 on Hugo -- gohugo.io en Sat, 25 Apr 2026 10:00:00 +0800 /posts/bff-http-client-pool-timeout-and-h2c-2026/ Sat, 25 Apr 2026 10:00:00 +0800 /posts/bff-http-client-pool-timeout-and-h2c-2026/ 配套阅读：shop-starter-http-client 设计 介绍完整的 starter 设计；本文专注于其中"连接配置"这一块的细节决定。 1. 问题场景 典型的 BFF 模式： graph LR BFF[buyer-bff] --> M[marketplace-service] BFF --> O[order-service] BFF --> L[loyalty-service] BFF --> P[promotion-service] BFF --> S[search-service] BFF -. 偶尔 .-> EXT[第三方支付 API] 每个下游的特征可能完全不同：marketplace 响应 50ms，搜索可能要 5s；payment 是外部 HTTPS API，order 是内部 cleartext；某个服务上了 HTTP/2，其他还是 HTTP/1.1。 三个绕不开的问题： 不同下游应该共用一个连接池，还是每个独立？ connectTimeout / readTimeout 怎么按服务定制？ 内部服务用 HTTP/2（h2c）值不值得开？怎么避坑？ 下面逐个讲清楚。 2. 连接池：共享还是隔离？ 我通常会先共享一个 java.net.http.HttpClient 实例。 2.1 为什么很多时候先不需要隔离 HttpClient 的连接复用天然按 origin 收敛 Oracle 的 HttpClient API 文档明确写了“一个 HttpClient 实例通常管理自己的连接池”；连接对同一 origin 复用、不同 origin 分开这一点，可以再配合 OpenJDK 源码 一起看。对 marketplace-service:80 和 order-service:80 的连接不会混在一个全局 bucket 里，所以“共享一个 HttpClient 实例”并不等于“所有下游抢同一组 socket”： /posts/spring-boot-35-h2c-benchmark/ Wed, 25 Mar 2026 16:30:00 +0800 /posts/spring-boot-35-h2c-benchmark/ 如果你还没理清 h2 和 h2c 的区别，可以先看我的基础概念篇。 这一篇不再讲概念，而是回答一个更实际的问题： Spring Boot 3.5 把 h2c 打开以后，真的会比 HTTP/1.1 更快吗？ 我在自己的 Shop Platform 概念验证（POC）项目里，围绕 buyer-bff -> marketplace-service 做了一整轮压测。这次实验全程基于 Java 25 (LTS) 并在 Spring Boot 中开启了 虚拟线程 (Virtual Threads)。 2026-04 实践更新 当前主线仓库里，BFF 的下游调用已经进一步演进成 @HttpExchange typed clients；因此本文关于 h2c / HTTP/1.1 的性能讨论依然成立，但调用栈样例请理解为“传输层对比实验”，不再代表今天 main 分支的全部客户端装配细节。 先说这次实验里的几个观察： 不会天然更快 但在特定 workload 下，的确可能更快 关键不在“有没有开 h2c”，而在“你的请求模型有没有真的吃到多路复用”，以及虚拟线程在高并发 I/O 场景下会不会放大这件事 这篇文章就是这次实验的完整复盘。 实验背景 这个项目本身是一套基于 Spring Boot 3.5 + Java 25 的微服务电商平台 POC。BFF 层会聚合多个下游领域服务，非常适合拿来验证协议层优化。 在 Java 25 这一最新的 LTS 版本中，虚拟线程的调度已经非常成熟。我在所有服务中都开启了： spring.