服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

引言 系统拆成微服务后第一个要回答的问题就是：服务之间怎么调？ 这个选择 90% 的团队是在"沿用上一代的习惯"中度过的——Java 老项目接着用 Dubbo，Spring Cloud 全家桶自然 Feign，新起的多语言团队上 gRPC。但真到大促压测时，选型的差异会以三个维度同时砸到你脸上：一个下单接口拆成"订单调库存"两段后，吞吐掉了 40%——这 40% 是消耗在了网络、序列化还是连接管理上？换一个框架能追回来多少？ 带着这个真实场景的问题，我们做了一次严格对照的压测：同一套业务接口（扣减库存），用 Feign、Dubbo、gRPC 三种方式各实现一遍，在同一台机器、同一套 JMeter 10,000 并发口径下跑。这篇文章完整记录测试方法、数据、三个框架各自的胜场与代价，最后给一张选型决策表。 一、三位选手速览 1.1 一句话定位 框架一句话定位本质协议 FeignHTTP 声明式客户端，Spring Cloud 标配，写接口像调本地方法HTTP/1.1 + JSON Dubbo阿里出品的高性能 RPC 框架，TCP 长连接 + 自定义序列化TCP + Dubbo ....

做过微服务灰度发布的同学肯定都遇到过这个问题：在网关层设置了灰度标记 Header，但经过 Feign 调用后，这个 Header 就神秘消失了。导致后端服务无法正确识别灰度流量，灰度发布变成了全量发布，引发线上事故。 我之前就遇到过这样一个案例：业务同学做灰度发布，在网关层设置了 X-Gray-Group: v2 的 Header，但经过几次 Feign 调用后，这个标记就丢失了。结果新版本的代码被所有用户访问到，导致部分用户看到了未完成的功能，影响了业务体验。 今天我们就来聊聊全链路灰度标透传的解决方案，让您的灰度标记在整个调用链路上畅通无阻。 灰度标丢失的根本原因 1. HTTP 请求头不会自动传递 这是最核心的问题： 调用链： 网关 → Service A → Service B → Service C 问题场景： 1. 用户请求到达网关，设置了 X-Gray-Group: v2 2. 网关调用 Service A，Header 传递成功 3. Service A 调用 Service B，Header 丢失！ 4. Service B 调用 Service C，没有灰度标记 ....