从产品视角看架构选型：Dubbo还是Feign，根本不是技术问题
从产品视角看架构选型：Dubbo还是Feign，根本不是技术问题
技术选型从来不是选"最强的方案"，而是选"最匹配当前问题的方案"。
很多团队过早引入 Dubbo、Nacos、Service Mesh，不是因为业务需要，而是因为"大家都在用"。
本文试图建立一套从产品和业务视角出发的架构决策框架，帮你避免过度设计，也避免设计不足。
一、先承认一个现实：80%的 Java 项目，用不上完整的微服务体系
打开技术社区，到处都是"Spring Cloud Alibaba 全家桶整合"、"Dubbo 3 性能优化实战"、"K8s + Istio 全链路治理"。
但回到真实场景——
- 你的团队有多少人？5 人？20 人？50 人？
- 你的服务真的需要独立扩容吗？某个模块的 QPS 真的是瓶颈吗？
- 你有没有跨语言调用的需求？Python 算法团队？Go 高性能组件？
- 你有没有多团队协作的痛点？团队之间是不是互相卡着联调？
如果以上问题的答案大多是"没有"或者"还没到这一步"，那你可能是一个伪装成微服务项目的单体应用。
二、决策框架：五个产品视角的判断维度
维度一：调用的是什么？—— 内部 RPC vs 外部 HTTP
这是最容易被忽视的维度，也是Feign 和 Dubbo 根本无法互相替代的原因。
场景 A：调用外部系统（第三方 API、政府接口、支付网关）
你的系统 ──HTTPS + 加解密──→ 国家政务网关 / 微信支付 / 短信服务商这个场景必须用 HTTP 客户端，没有讨论空间。外部系统不会跟你说 Dubbo Triple 协议，不会跟你做服务发现，它们只认 REST/JSON。
✅ Feign 是最佳选择：声明式接口 + 拦截器统一处理加解密、签名、日志
✅ 自研 HttpClient 也可以（项目初期）
❌ Dubbo 完全帮不上忙
场景 B：内部服务间调用（未来拆成多个服务之后）
Admin 服务 ──内部 RPC──→ 信用评估服务
──内部 RPC──→ 贴息计算服务这个场景 Dubbo 才有优势：
- 高性能二进制协议（比 HTTP/JSON 快 2-3x）
- 精细化流量治理（灰度、限流、熔断）
- 强类型接口契约（编译期检查）
但注意——这是"未来拆成多个服务之后"的事。在单体里，模块间直接 @Autowired 注入比任何 RPC 都快，而且没有网络开销、没有序列化、没有超时重试问题。
维度二：有多少人用？—— 单体边界 vs 微服务阈值
这里给出一个参考阈值（不是绝对值，是思考方向）：
| 指标 | 单体够用 | 考虑拆分 | 微服务合理 |
|---|---|---|---|
| 团队规模 | ≤ 10 人 | 10-30 人 | ≥ 30 人 |
| 核心模块数 | ≤ 5 个 | 5-10 个 | ≥ 10 个 |
| 日均请求量 | < 10万 | 10万-100万 | > 100万 |
| 独立扩容需求 | 无 | 部分模块明显 | 多个模块都需要 |
| 发布频率 | 每周几次 | 每天多次 | 持续集成 |
超过这个阈值，微服务的收益开始大于成本；没到这个阈值，微服务就是负债。
为什么微服务不一定更快？
很多人以为微服务 = 快，实际上：
- 一个单体启动 2 分钟，10 个微服务 + 注册中心 + 网关，启动时间 5 分钟 + 运维开销
- 单体一次
mvn package搞定，微服务 10 个仓库要分别打包、部署、灰度 - 单体调试一个断点就够，微服务要 Trace、要跨服务日志、要模拟上下游
微服务的核心价值是"团队协作效率"和"独立扩容"，不是"开发更快"。 如果这两个价值你都感知不到，那就是过度设计。
维度三：团队 hold 得住吗？—— 复杂度匹配原则
技术栈的复杂度不能超过团队的运维能力。
复杂度金字塔（由低到高）：
Level 1: 单体 Spring Boot + 自研 HttpClient
Level 2: Spring Boot + Feign 替换自研客户端
Level 3: + Nacos 注册中心 + Gateway 网关
Level 4: + Dubbo RPC + Sentinel 限流 + SkyWalking 链路追踪
Level 5: + K8s + Istio Service Mesh
Level 6: 多集群 + 跨机房容灾每升一级，你需要掌握的知识量和运维成本大约翻一倍。
问题来了：你的团队能 cover 到哪一级？
- Level 1：1 个能跑 Spring Boot 的后端就能搞定
- Level 3：需要理解注册中心、配置中心、网关路由的基本概念
- Level 4：需要有人懂 Dubbo 的 SPI、负载均衡策略、泛化调用、服务治理
- Level 5：需要有人懂 K8s 的 Pod/Service/Ingress/CRD + Istio 的 VirtualService/DestinationRule
我见过太多团队，在 Level 2 的业务体量上，强行上了 Level 5 的技术栈，结果就是：线上问题没人能排查，服务治理能力没人会用，最后全靠 restart 解决。
维度四：未来往哪走？—— 演进路线图
架构选型要看演进方向，而不是看当前状态。
如果你的未来是这样的：
现在：单体（5 个模块，3 人团队）
半年后：还是单体（7 个模块，5 人团队）
一年后：可能还是单体...选 Feign，把 HTTP 调用封装好，剩下的事以后再说。
如果你的未来是这样的：
现在：单体，但业务明确要拆
→ 6 个月内拆成 4-5 个独立服务
→ 每个服务可能由不同团队维护
→ 部分服务有独立扩容需求
→ 未来可能对接 Python 算法服务可以考虑 Dubbo 3 + Nacos，但建议分层使用：外部 HTTP 接口用 Feign，内部服务间 RPC 用 Dubbo。
关键原则：预留演进空间，但不为尚未确定的未来买单
- 接口契约用纯 Java 接口 + DTO定义（不要在接口上加 Dubbo 注解，也不要加 Feign 注解）
- 今天用 Spring
@Autowired实现，明天换成 Dubbo@DubboReference或 Feign@FeignClient都只需要改实现层 - 这就是"面向契约编程"的真正价值——技术栈可以换，业务契约不变
维度五：运维成本谁来出？—— 隐性成本清单
最后算一笔账。引入一个组件，成本不止是"加个依赖"这么简单：
| 组件 | 显性成本 | 隐性成本 |
|---|---|---|
| Feign | 1 个 dependency | 学习注解语法 + 配置超时重试 |
| Nacos | 部署 2C4G 服务 | 配置中心多环境管理 + 注册中心健康检查 + 账号权限 |
| Dubbo | 多个 dependency + 大量配置 | 理解 SPI 机制 + 服务治理配置 + 兼容性问题排查 |
| Gateway | 部署 + 路由配置 | 鉴权逻辑 + 限流规则 + 跨域 + 过滤器链 |
| K8s | 集群部署 | YAML 编写 + 镜像仓库 + Helm + Pod 监控 + 证书管理 |
谁来做这些事？ 如果你的团队没有专职运维，这些成本最终都落在开发身上——而开发的时间是最贵的。
三、实战案例：信贷金融数据平台的架构选择
我们用一个真实项目来走完这个决策流程。
项目背景
一个地方金融科技公司的信贷金融数据平台：
- 对接"国家信易贷"等政府数据接口，提供企业信用评估
- 主要模块：信易贷代理、贴息申请、单点登录、财务报表
- 当前架构：单体多模块（Spring Boot 3.x，模块间 jar 依赖）
- 规模：3 个后端，1 个前端，日均请求 < 1 万
走一遍决策框架
| 维度 | 项目现状 | 决策 |
|---|---|---|
| 调用场景 | 既要调外部 HTTP（政府接口），又有内部模块调用 | 外部用 Feign，内部暂不 RPC |
| 团队规模 | 3 人 | Level 2 撑顶，Level 3 谨慎考虑 |
| 运维能力 | 无专职运维 | 技术栈越轻越好 |
| 演进方向 | 2 年内可能拆业务线，但不确定 | 预留演进空间，不急着拆 |
| 成本预算 | 小团队，时间优先 | 优先选能快速交付的方案 |
最终决策
现在（单体）：
┌─────────────────────────────────────────┐
│ Admin / OpenAPI / Dash（三个入口） │
│ │ │
│ └── @Autowired 注入业务服务（进程内） │
│ │ │
│ └── Feign Client 调外部 HTTP │
│ └── Feign 拦截器统一处理 SM4 加解密 │
└─────────────────────────────────────────┘
2 年后如果拆成微服务：
┌─────────────────────────────────────────┐
│ Nacos 2.x（注册 + 配置中心） │
│ Spring Cloud Gateway（统一网关） │
│ │
│ Admin 服务 ──Dubbo RPC──→ 信用评估服务 │
│ ──Dubbo RPC──→ 贴息服务 │
│ │
│ 信用评估服务 ──Feign──→ 国家信易贷 API │
└─────────────────────────────────────────┘为什么这样决策？
- Feign 替换自研 HttpClient：立刻解决外部 HTTP 调用的代码重复问题，加解密统一处理，收益立即可见
- 不引入 Dubbo：单体里 Dubbo 没有任何性能优势，注册中心反而增加启动时间和运维复杂度
- 不引入 Nacos：当前只有 3 个入口应用，手动配置
application.yml足够，不需要分布式配置 - 接口契约保持纯 Java：为未来可能的微服务拆分预留空间，改实现层即可
四、总结：一张决策树
你要引入新组件了吗？
│
├── 是 HTTP 调用？（对接外部 API）
│ ├── 是 → 用 Feign ✅（拦截器统一处理加解密/签名）
│ └── 否
│
├── 是 内部服务间调用？
│ ├── 当前是单体？
│ │ ├── 是 → @Autowired 就够了 ✅（进程内调用最快）
│ │ └── 否（已拆成微服务）
│ │ ├── QPS > 1000？或有跨语言需求？
│ │ │ ├── 是 → 考虑 Dubbo 3 ✅（高性能 + 精细化治理）
│ │ │ └── 否 → Feign 继续用 ✅（够用 + 学习成本低）
│ │ └── 团队能 Hold 住 Dubbo 的复杂度吗？
│ │ ├── 能 → 考虑上
│ │ └── 不能 → Feign 够用，别勉强
│ └── 还没拆？
│ └── 先别急，等有了真实的拆分需求再说 🛑
│
└── 这个组件能帮你解决什么具体问题？
├── 列得出来 → 引入 ✅
└── "大家都在用" → 别急，大概率是过度设计 🛑写在最后
架构选型的核心原则：用最轻的方案解决当前的问题，为确定的未来预留空间，不为不确定的未来买单。
Dubbo 和 Feign 没有绝对的好坏，只有适合不适合。
- 你在做 ToC 高并发交易系统，Dubbo 3 + 链路治理可能是必须的
- 你在做内部业务系统，Feign + 自研 HttpClient 可能就够用了
- 你还在单体阶段，那 Feign 都可能嫌重
先跑起来，再优化，最后才是重构。 这条在架构选型上同样成立。
本文基于真实项目信贷金融数据平台的架构决策过程整理
如果对你有帮助，欢迎在评论区交流你的选型心得。