4.3 技术选型的评估维度
一句话
选型不是挑 “最好的技术”，而是在你的约束下挑总代价最小、且退出成本可控的技术；权重必须写在打分之前，否则评审会退化成偏好之争。
先把维度定死：七维 + 两个否决项
| # | 维度 | 问什么 | 典型权重 | 判不好会怎样 |
|---|---|---|---|---|
| 1 | 功能匹配 | 关键场景是否原生支持（事务、延迟消息、多租户…） | 20–30 | 靠外挂补齐，复杂度转移到业务代码 |
| 2 | 成熟度与稳定 | 版本节奏、生产案例、故障史 | 15–25 | 上线后给别人当测试用户 |
| 3 | 性能与容量 | 目标负载下的 P99、扩展方式 | 10–20 | 到量才发现瓶颈在架构不在配置 |
| 4 | 生态与人才 | 招得到人吗、文档/客户端齐吗 | 10–20 | 只有 1 个人会，他就是 bus factor |
| 5 | 运维复杂度 | 部署、升级、扩缩容、排障成本 | 5–15 | 隐形成本在第二年爆发 |
| 6 | 成本 | 三年 TCO（见 4.2 成本-收益分析），含人力 | 5–15 | 只算资源，自建永远"便宜" |
| 7 | 锁定与可迁移 | 数据能否导出、协议是否标准 | 5–10 | 想换时发现要重写 |
🔑 **权重之和必须是 100，且任一维度权重 > 40 时要书面说明理由。**权重本质上是你对业务约束的排序，不是对技术的好恶。
一票否决在前，打分在后
| 否决项 | 判定标准 | 为什么是否决而不是扣分 |
|---|---|---|
| 合规不通过 | 行业规范/数据出境不允许（见 3.4） | 扣分也过不了审，等于白选 |
| 无人维护 | 近 12 个月无 release，且无商业支持 | 出 0day 时你只能自己修 |
| 许可证不允许商用 | 强 copyleft 或限制性条款 | 法务风险不可用分数交换 |
| 零经验且无外部支持 | 团队 0 人用过，也买不到支持 | 首次故障的恢复时间不可控 |
| 数据无法导出 | 无标准协议、无批量导出 | 锁定成本无法估算 |
顺序很重要：先跑否决项，可能直接只剩 1 个候选；剩下的再打分。反过来做，会花两小时给一个不能用的方案打 85 分。
打分表长什么样 (示例：消息队列选型)
| 维度 | 权重 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|---|
| 功能匹配（延迟消息/事务消息） | 25 | 3 | 4.5 | 3.5 |
| 成熟度与稳定 | 20 | 5 | 4.5 | 5 |
| 性能与容量 | 15 | 5 | 4 | 2.5 |
| 生态与人才 | 15 | 5 | 4 | 4.5 |
| 运维复杂度 | 10 | 4 | 3 | 4.5 |
| 成本（3 年 TCO） | 10 | 4 | 4 | 3.5 |
| 锁定与可迁移 | 5 | 5 | 4 | 4 |
| 加权总分 | 100 | 86.0 | 82.5 | 78.5 |
打分口径：1 = 明显不满足，3 = 够用，5 = 明显优于同类。分数必须能对应到一条事实 (文档、POC 数据、生产案例)，不能是印象分。
用 10 行代码算，别用 Excel 手抖
WEIGHTS = {"功能匹配": 25, "成熟度": 20, "性能容量": 15, "生态人才": 15,
"运维复杂度": 10, "成本": 10, "可迁移性": 5}
CANDIDATES = {
"Kafka": {"功能匹配": 3, "成熟度": 5, "性能容量": 5, "生态人才": 5, "运维复杂度": 4, "成本": 4, "可迁移性": 5},
"RocketMQ": {"功能匹配": 4.5, "成熟度": 4.5, "性能容量": 4, "生态人才": 4, "运维复杂度": 3, "成本": 4, "可迁移性": 4},
"RabbitMQ": {"功能匹配": 3.5, "成熟度": 5, "性能容量": 2.5, "生态人才": 4.5, "运维复杂度": 4.5, "成本": 3.5, "可迁移性": 4},
}
for name, s in CANDIDATES.items():
total = sum(s[k] / 5 * w for k, w in WEIGHTS.items()) # 归一化到 100 分制
print(f"{name:10s}{total:6.1f}")
差距小于 10% 视为平手
86.0 与 82.5 差 3.5 分 (4%)——在打分噪声之内，不足以支撑 “Kafka 更好” 的结论。
| 分差 | 怎么处理 |
|---|---|
| > 10 分 | 结论清晰，写进决策记录即可 |
| 5–10 分 | 对权重最敏感的 2 个维度做敏感性分析，看结论是否翻转 |
| < 5 分 | 视为平手，改用非打分因素决断：团队经验、现有基础设施、招聘市场 |
⚠️ **用小数点后的差距做决策，是最常见的伪严谨。**打分是 1–5 的粗粒度估计，“86.0 优于 82.5” 这个精度的可信度是零。平手时的正确动作是：选团队最熟的，或者做 POC。
成熟度怎么判：五个硬指标
| 指标 | 健康线 | 看什么 |
|---|---|---|
| Release 节奏 | 大版本 6–18 个月一次，小版本持续 | 两年不发版 = 停滞；一个月一个大版本 = 不稳 |
| 贡献者集中度 | 前 2 名贡献者提交占比 < 60% | 超过就是 bus factor = 2 |
| Issue 关闭率 | > 60% | 长期堆积说明维护力量不足 |
| 生产案例规模 | 有 ≥ 你 10 倍规模的公开案例 | 你的量级在别人的舒适区内 |
| 商业支持 | 能买到 SLA / 驻场 / 热修复 | 出事时有没有人跟你一起扛 |
💡 GitHub star 不是成熟度指标，它是 “流行度指标”。流行度高但维护停滞的项目，比小众但稳定的项目危险得多——因为你会误以为有人兜底。
性能对比必须同条件：五种常见的不公平
| 手法 | 为什么要不得 |
|---|---|
| 一边开持久化，一边不开 | 差的是可靠性，不是性能 |
| 数据量 1 万 vs 1 亿 | 小数据量下大多数系统都很快 |
| 单条写入 vs 批量写入 | 吞吐差 10 倍以上，比的不是同一件事 |
| 空载 vs 有背景流量 | 真实系统永远有干扰 |
| 只报平均值或 P50 | 长尾才是用户感知的（见 1.1 功能性需求与非功能性需求 的 P99） |
验收方式：任何引用的 benchmark，必须能回答 “硬件、数据量、副本数、ack 级别、消息大小、分位数” 这六项。答不全，就只能当参考，不能当依据。
POC：只验证最贵的两个假设
POC 不是 “跑个 demo 看看能不能用”，是用最小成本推翻最可能的错误。
| 要验证的假设 | 怎么验 | 通过标准 |
|---|---|---|
| 目标数据量下延迟可接受 | 造 1/10 生产数据量，压到目标 TPS | P99 ≤ 目标值 |
| 故障能自动恢复 | kill 一个节点 / 断网 30 秒 | 恢复 ≤ RTO，无数据丢失 |
| 运维真的简单 | 让没参与选型的人照文档部署一次 | 2 小时内完成，无需电话求助 |
| 迁移成本可控 | 导一份真实数据进去再导出来 | 导出格式可被下游直接消费 |
🔑 **“运维是否简单” 必须由不熟悉的人验证。**作者本人两小时装好，说明不了任何问题——上线后值班的不是他。
可替换性 > 选对
选错的概率永远大于选对的概率，因为信息永远不全。所以真正要设计的是纠错成本：
| 手段 | 做法 |
|---|---|
| 最小接口面 | 业务只依赖自己定义的 5–10 个方法，不直接调产品 API |
| 防腐层 | 中间加一层适配，把产品的特殊语义挡在外面 |
| 数据可导出 | 选型时就验证"全量导出 + 导入到备选"这条路 |
| 退出计划写进 ADR | "若出现 X（如连续 3 次 P0 事故），换 Y，预计 N 人月" |
选型落地不等于结束：这条技术该待在哪个环、凭什么证据升级或降级、什么条件下撤下来，见 4.5 技术雷达与新技术跟踪。
反模式
| 反模式 | 后果 |
|---|---|
| 简历驱动开发（为了用新技术而选它） | 团队拿生产系统练手，故障率上升 |
| 用别人的 benchmark 博客代替自己的 POC | 条件不同，结论不可迁移 |
| 先打分后定权重（打完结再调权重凑结论） | 决策过程失去可信度，事后无人认账 |
| 只看 star 数 / 只看大厂案例 | 忽略自身规模与团队能力差异 |
| 忽略运维人力，只比资源成本 | 第二年隐性成本反超（见 4.2 成本-收益分析） |
| 选型会开成技术信仰之争 | 3 小时没有结论，最后靠职级拍板 |
| 没有退出计划 | 明知选错也换不掉，锁定成立 |
四条铁律
🔑 **权重先定、分数后打。**顺序反了，打分只是给偏好找理由。
🔑 **否决项优先于总分。**合规、维护性、许可证、数据可导出，这四条不参与加权——它们只有 “过” 和 “不过”。
🔑 分差 < 10% 就是平手，用团队熟悉度决断，别用小数点决断。
🔑 **选型结论必须带一句 “什么情况下我们会换掉它”。**没有这句话的决策记录，等于放弃了未来的纠错权。
自检
Q1 三个候选的加权总分是 86.0 / 82.5 / 78.5，你怎么定？
▸ 答案：先看分差——86 与 82.5 差 4%，在噪声内，不能据此说第一个更好。此时按顺序：① 确认否决项都已通过；② 看这两个候选在你权重最高的维度上差多少 (若功能匹配差 1.5 分，那正是你业务最在意的点，值得深挖)；③ 做 POC 或选团队最熟的。用 “86 比 82.5 高” 当理由，评审时一问权重怎么来的就崩。
Q2 供应商给你一份 benchmark，说吞吐是竞品的 10 倍。你信不信？
▸ 答案：先要六项条件：硬件规格、数据量、副本数、ack/持久化级别、消息大小、报的是 P50 还是 P99。少任何一项都不能当依据。典型的 10 倍差距来自 “一边批量一边单条” “一边不持久化一边持久化” “小数据量对大数据量”——差的是测试设置，不是产品。
Q3 团队 0 经验，但某个技术明显更优，能选吗？
▸ 答案：能，但要把学习成本显式计入 TCO：培训人日、POC 时间、首次故障的恢复时间 (可能从 30 分钟变成 4 小时)、招聘溢价。如果这些加起来让三年 TCO 反超，那 “更优” 只存在于纸面。若仍要选，必须配 “外部支持 + 双人备份”，否则这家技术就变成了单点。
Q4 为什么说 “可替换性” 比 “选对” 更重要？
▸ 答案：因为选型是在信息不全下做的决策，选错是常态而非意外。可替换性把 “选错的代价” 从 “重写系统” 降到 “换一个适配层”。具体动作：业务只依赖自己定义的接口、加防腐层、验证数据可导出、ADR 里写退出条件。没有这四条，任何选型都是一次性押注。
Q5 为什么 “运维简单” 这一维必须由不熟的人来验证？
▸ 答案：因为选型者本人的熟练度是伪装成产品优势的。作者两小时装好，换一个值班工程师可能是两天，而且是在凌晨两点出事的时候。让没参与选型的人照文档走一遍，测出来的才是真实运维成本——这一项在 TCO 里往往比资源成本更贵。
Q6 有人说 “我们选它是因为 BAT 都在用”。这条论证成立吗？
▸ 答案：只成立一半。大厂案例能证明 “这个规模下可行”，但不能证明 “你团队能运维”。要补三个问题：① 他们的规模和你差几倍 (差 100 倍则结论不可迁移)；② 他们有专职团队吗 (有，而你没有)；③ 他们踩过的坑你有没有能力踩。这三问答完，“大厂在用” 才从背书变成证据。