第 16 章技术栈选型指南

技术栈选型不是列一个“流行组件清单”，而是把业务目标、团队能力、系统约束和长期治理成本放到同一张表里比较。一个组件能不能用，不只取决于性能指标，还取决于团队是否会运维、故障时是否能降级、数据是否能迁移、监控是否完整、未来是否会被业务规模反噬。

选型的基本顺序

技术选型建议按下面的顺序展开：

先明确业务目标：低延迟、高吞吐、强一致、快速迭代、成本可控，哪个是第一优先级。
再判断数据特征：事务数据、缓存数据、搜索数据、事件数据、分析数据不能混用一套存储思路。
再识别访问模式：读多写少、写多读少、热点集中、时间序列、复杂检索、批量导入各自对应不同设计。
再评估团队能力：是否有足够经验处理扩容、备份、回滚、监控、容量规划和故障演练。
最后决定演进路径：先用简单方案跑通业务，再在瓶颈明确后引入更重的基础设施。

这个顺序的核心是：不要为了展示技术复杂度而引入组件，要为了控制业务复杂度而选择工具。

常见组件的职责边界

组件	适合解决的问题	不适合承担的职责
MySQL	权威数据、事务、状态机、审计	高维全文检索、无限历史明细在线查询
Redis	热点缓存、短期状态、原子扣减、限流计数	长期权威存储、复杂事务关系
Kafka	异步解耦、削峰、事件传播、可回放日志	用户实时同步响应、强事务提交
Elasticsearch	全文搜索、多条件筛选、聚合检索	核心交易状态、强一致写路径
Kubernetes	标准化部署、弹性、发布治理	替代应用自身的降级、幂等、补偿设计

在系统设计面试和真实项目里，好的回答不是“这里用 Redis”，而是“这里用 Redis 承担短期热点读写，权威状态仍在 MySQL，并通过过期、回源和对账处理不一致”。组件本身只是方案的一部分，组件之间的边界和失败处理才是架构设计。

电商场景中的选型示例

电商系统天然会把多种组件放到同一条链路里。商品中心的主数据适合落 MySQL；商品搜索和筛选适合构建 Elasticsearch 索引；库存可售量可以用 Redis 承担高并发预扣，但库存流水和最终状态必须回到 MySQL；订单创建后的通知、积分、营销核销适合通过 Kafka 异步扩散。

这类组合的重点不是“组件越多越高级”，而是每个组件只承担自己擅长的职责，并在边界上设计好失败语义：

Redis 扣减成功但订单创建失败，要有释放或补偿。
Kafka 消息可能重复投递，消费者要幂等。
Elasticsearch 索引可能延迟，前台体验要接受短暂不一致。
MySQL 主从可能延迟，关键读路径要能读主或使用一致性读策略。

选型评审清单

做技术方案评审时，可以用下面的问题快速过滤风险：

问题	判断点
这个组件解决的核心矛盾是什么？	性能、可靠性、一致性、研发效率，不能混在一起说
不引入它会怎样？	如果没有明确痛点，先保持简单
它失败时业务如何降级？	超时、重试、降级、补偿必须能讲清
数据迁移和回滚怎么做？	新旧链路并行、双写校验、灰度切换
谁负责运维和容量规划？	没有人负责的组件就是未来事故源
它会不会改变团队开发方式？	CQRS、事件驱动、微服务都会增加协作成本

技术栈选型的结论最好写进 ADR 或技术方案文档。这样后续团队复盘时，不只知道“当时选了什么”，还知道“为什么选、放弃了什么、风险如何接受”。