第十八章 技术选型之争

一

新项目来了。

一个连锁餐饮客户要做一套"智能排班系统"——根据门店的历史客流数据、员工技能、劳动法规等因素，自动生成排班表。

这个项目的技术选型成了一场战争。

战争的双方是王志远和陈锐。

二

陈锐在选型评审会上第一个发言。他的 PPT 做得很漂亮——深色背景、渐变色标题、精美的架构图。

"我推荐使用 Quarkus 作为后端框架。"陈锐说。"Quarkus 是 Red Hat 推出的云原生 Java 框架，启动速度比 Spring Boot 快十倍，内存占用只有 Spring Boot 的五分之一。它支持 GraalVM 原生编译，可以把 Java 应用编译成原生可执行文件，冷启动时间从秒级降到毫秒级。"

他翻到下一页，展示了一张性能对比图：

启动时间对比：
Spring Boot: 3.2 秒
Quarkus (JVM): 0.8 秒
Quarkus (Native): 0.02 秒

内存占用对比：
Spring Boot: 200MB
Quarkus (JVM): 80MB
Quarkus (Native): 30MB

"而且，"陈锐继续说，"Quarkus 是目前最热门的 Java 框架之一，GitHub Star 数增长很快，社区非常活跃。用 Quarkus 做项目，对团队的技术竞争力也是一个提升。"

周旋经理听得连连点头："不错不错，性能提升这么大？"

陈锐笑了："是的，周总。而且 Quarkus 的开发体验也很好，支持热重载，改了代码不用重启。"

三

轮到王志远了。

他的 PPT 很朴素——白色背景、黑色文字、简单的表格。没有渐变色，没有精美的架构图。

"我推荐继续使用 Spring Boot。"他说。

周旋的表情有点失望——好像在说"就这？"

王志远没有急着解释，而是打开了一份文档。

"在做选型之前，我做了一些调研。我想先分享一下调研的结果，然后再说我的结论。"

他展示了一张对比表：

"陈锐说的性能数据是对的——Quarkus 在启动速度和内存占用上确实比 Spring Boot 好很多。但问题是：这些优势对我们的项目有意义吗？"

他指着表格："排班系统是一个内部管理系统，不是高并发的互联网应用。它不需要频繁重启，不需要毫秒级冷启动，不需要极致的内存优化。它需要的是稳定、可维护、快速交付。"

四

他翻到下一页，展示了一份更详细的分析。

"我还做了一个实验。"他说。"我用 Quarkus 写了一个简单的 CRUD demo，然后尝试把我们现有的一些公共组件（日志、监控、权限）集成进去。"

他展示了实验结果：

集成测试结果：
✅ 日志组件（Logback）：正常
✅ 监控组件（Micrometer）：正常
❌ 权限组件（Spring Security）：不兼容，需要替换为 Quarkus Security
❌ ORM（MyBatis）：Native 模式下有反射限制，需要额外配置
⚠️ 定时任务（Quartz）：可用，但 Native 模式下有已知 bug

"我们的权限组件是基于 Spring Security 的，如果换 Quarkus，权限模块要重写。MyBatis 在 Native 模式下有反射限制，需要手动配置反射列表，维护成本很高。定时任务在 Native 模式下有已知 bug，排班系统恰好需要大量定时任务。"

他看了一眼陈锐："这些坑，Quarkus 官方文档里其实都提了，但你得仔细翻才看得到。"

陈锐的脸色有点不好看。

五

王志远翻到最后一页。

"我的结论是：对于这个项目，Spring Boot 是更合适的选择。"

他列了三条理由：

1. 团队熟悉度：全组都会 Spring Boot，零学习成本。
   用 Quarkus 需要 2-3 周学习期，项目工期只有 6 周。

2. 生态兼容性：现有公共组件全部基于 Spring 生态。
   换 Quarkus 需要重写权限模块，额外增加 1-2 周工作量。

3. 风险可控性：Spring Boot 在我们的生产环境已经稳定运行 3 年。
   Quarkus 在国内的大规模生产案例较少，遇到问题时可参考的资料有限。

"Quarkus 确实是个好东西，搞云原生、搞 Serverless 很合适。但咱选技术不是选最酷的，是选当下最趁手的。"

他顿了一下，加了一句："Quarkus 可以先当技术储备，找个合适的项目练练手。但这个项目，还是用 Spring Boot 稳当。"

六

评审会上安静了几秒。

苏薇第一个发言："我同意小胖的。选东西得看场景，光看跑分没用。排班系统又不是要毫秒级启动，稳当、能按时交付才是正经事。"

马德华说："我也同意。学新框架要时间，项目工期紧，没必要冒险。"

陈锐有点急了："但 Quarkus 是趋势啊！如果我们一直用 Spring Boot，技术栈就落后了。"

王志远平静地说："别老想着用最新的，能干活的就是最好的。再说了，自己学着玩和拿到生产项目上用，那是两码事。咱可以在内部搞搞预研，但拿客户的项目当试验田，出了事谁兜底？"

周旋经理想了想，说："志远的分析很有说服力。这个项目用 Spring Boot。陈锐，你的 Quarkus 调研也有价值，可以作为技术储备，找个内部项目试试。"

陈锐张了张嘴，最终没有再争论。

七

王志远在评审会后做了一件事——他写了一份架构决策记录（ADR）。

这是他在《程序员修炼之道》里学到的方法。每次做重要的技术决策，都要写一份 ADR，记录决策的背景、考虑的方案、最终的选择和理由。

# ADR-001: 智能排班系统后端框架选型

## 状态
已决定

## 背景
智能排班系统需要选择后端框架。候选方案：Spring Boot、Quarkus。

## 决策
选择 Spring Boot 3.x。

## 理由
1. 团队全员熟悉 Spring Boot，零学习成本
2. 现有公共组件（权限、日志、监控）基于 Spring 生态
3. Spring Boot 在生产环境稳定运行 3 年，风险可控
4. 排班系统不需要 Quarkus 的启动速度和内存优势

## 被否决的方案
Quarkus：性能优势明显，但团队无使用经验，
公共组件兼容性问题多，项目工期不允许额外学习成本。

## 后续
将 Quarkus 作为技术储备，在内部项目中进行预研。

## 参与者
王志远、陈锐、苏薇、马德华、周旋

他把 ADR 提交到了项目的文档仓库里。

赵北辰看到后，发了一条消息："ADR 写得好。以后每个重要的技术决策都这样记录。三年后回头看，你会感谢自己。"

八

项目上线后，稳定运行了一个月，零故障。

周旋在周会上特意表扬了王志远："志远的技术选型很稳，项目上线后没有出过任何框架层面的问题。"

一个月后，一个消息在技术圈炸开了——Quarkus 的一个核心依赖库被曝出严重的安全漏洞（CVE 评分 9.8），影响了所有使用该库的 Quarkus 应用。修复补丁需要升级到最新版本，但最新版本有 breaking changes，升级成本很高。

陈锐看到这个消息的时候，脸色很复杂。

他走到王志远的工位旁边，站了几秒钟，然后说了一句："幸好没用 Quarkus。"

王志远没有说"我早就说了"之类的话。他只是点了点头："安全漏洞这种事谁也说不准。不过用成熟的东西，出了问题好歹有人帮你，不至于两眼一抹黑。"

陈锐看了他一眼，欲言又止，最后转身走了。

九

那天晚上，陈锐在群里发了一条消息："幸好没用 Quarkus。"

王志远看着这条消息，没有回复。他没有得意的感觉——因为他知道，如果那个安全漏洞没有曝出来，陈锐可能永远不会认可他的选择。

技术决策的正确性，不应该靠运气来验证。靠的是数据、是调研、是对风险的敬畏。

他关掉手机，拿起桌上那份 ADR 文档又看了一遍。三个月前写下的决策理由，现在读起来依然站得住脚。

咱做技术的，说白了就一条——趁手的就是最好的，别老追新的。目的无他，把活儿干好而已。

:::{admonition} 小胖的笔记 :class: tip

本章知识卡片：技术选型与架构决策

1. 技术选型的考量因素

2. 架构决策记录（ADR）模板

# ADR-XXX: [决策标题]

## 状态
[提议 / 已决定 / 已废弃]

## 背景
[为什么需要做这个决策？]

## 决策
[最终选择了什么？]

## 理由
[为什么选择这个方案？]

## 被否决的方案
[考虑过但没有选择的方案，以及原因]

## 后果
[这个决策带来的影响，包括正面和负面]

## 参与者
[参与决策的人]

3. 技术选型的常见误区

核心原则：技术选型是工程决策，不是技术信仰。用数据说话，为场景服务。

:::