技术选型决策地图：用问题树把数据库、消息与工作流、可观测性、入口与协议、容器与平台工程、操作系统与存储、RAG 分流到站内对比页

使用方式

本页是选型决策枢纽，不重复各组件的参数和优劣细节。每一条线先用问题缩小范围，再给出推荐路径，最后把需要深入比较的部分交给现有对比页。回答问题时不要跳步：访问模式、一致性或交付语义、规模、运维能力、成本与锁定，顺序不同，结论往往也不同。

建议按四步使用：先定位业务线；按顺序回答该线的判断问题；带着推荐路径去读对应对比页；最后用真实数据做小规模验证。若某个问题无法回答，说明需求还没澄清，此时不应进入产品选型。没有“唯一正确”的技术，只有与当前约束匹配、并且未来可以替换的选择。

七条选型决策树

数据库：先分访问模式，再看产品

判断问题：

1. 主要是点查、短事务、复杂关联，还是大范围扫描与聚合？
2. 是否需要跨表事务、外键和强一致读？
3. 数据规模与增长速度是否超出单机，是否需要分片或列式存储？
4. 缓存是纯 KV，还是需要列表、集合、过期、持久化和主从？
5. 文档模型是否真的比关系模型更贴合，还是只是想逃避 schema 设计？
6. 向量检索是辅助能力还是核心负载？
7. 团队能否承担备份恢复、升级、故障切换和调优？

推荐路径：

• 强事务、复杂关联、中等规模：优先 PostgreSQL 或 MySQL；已有 PostgreSQL 且团队熟悉时，不要为单一功能引入新数据库。
• 纯缓存、结构简单：Memcached；需要数据结构和持久化：Redis 或 Valkey。
• 大范围聚合、报表、日志分析：选列式 OLAP 或湖仓，不要把 OLTP 主库当数仓。
• 文档 schema 频繁变化、以聚合根读取为主：评估 MongoDB，但先确认事务与查询边界。
• 向量是辅助：pgvector；向量是核心且需要强过滤或分布式：转入 RAG 线。

对比页：psql-vs-mysql、mysql-vs-mariadb、postgres-vs-mongodb、redis-vs-memcached、valkey-vs-redis。向量库对比转入 RAG 线。

消息队列、流处理与工作流：先问消费后还要不要读

判断问题：

1. 生产的是事件流，还是任务或命令？
2. 消费后是否还需要回放历史，是否有多个独立消费者？
3. 需要多复杂的路由：直连、主题、扇出、优先级、延迟队列？
4. 延迟与吞吐哪个优先，能否接受批量和秒级延迟？
5. 是否要求分区内有序，顺序键是什么？
6. 是否是 IoT 长连接、QoS、海量设备场景？
7. 任务是短时消息，还是定时批处理、依赖编排、回填与重跑？
8. 团队能否运维 broker 集群、存储和跨机房复制？

推荐路径：

• 事件流、日志、CDC、回放、多消费者：Kafka；需要多租户、分层存储或跨地域：评估 Pulsar。
• 任务分发、复杂路由、请求响应、优先级：RabbitMQ。
• 轻量、低延迟、云原生、请求响应：NATS，但先确认持久化和交付语义。
• IoT 与 MQTT：EMQX 或 Mosquitto，按连接规模与集群能力选。
• 定时批处理、依赖编排与历史回填：Airflow；事件驱动、长时间运行、需要持久化执行状态：Temporal。两者不在同一层，不能互相替代。
• 不确定时从最简单队列开始，只有出现回放和多消费者需求才引入流平台。

对比页：kafka-vs-rabbitmq、kafka-vs-pulsar、nats-vs-kafka、nats-vs-rabbitmq、emqx-vs-mosquitto、temporal-vs-airflow。

可观测性：先定要回答的问题，再定后端

判断问题：

1. 当前最缺的是指标、日志、链路还是 profiling？
2. 指标需要多长保留期，是否需要跨集群或长期存储？
3. 日志主要用于按标签和时间排障，还是全文检索、审计与分析？
4. 是否已有 Grafana 或 Prometheus 体系，是否要统一展示与告警？
5. 是否还要纳管主机、网络设备和传统 IT 监控？
6. 高基数标签、全量日志和 trace 采样是否有治理方案？
7. 是否定义了 SLI 和 SLO，告警基于症状还是原因？

推荐路径：

• 指标从 Prometheus 起步；规模大、保留久、跨集群，评估 VictoriaMetrics 或远程存储。
• 已有 Zabbix 资产与主机监控：保留 Zabbix 做基础设施监控，Prometheus 做云原生指标，不要强行二选一。
• Kubernetes 日志、成本敏感、已有 Grafana：Loki；全文检索、审计、复杂分析：ELK。
• 展示层按现有查询习惯选 Grafana 或 Kibana，不要只看界面。
• 先统一标签、日志结构和 trace 上下文，再谈平台替换。

对比页：prometheus-vs-victoriametrics、prometheus-vs-zabbix、loki-vs-elk、grafana-vs-kibana、version-eol-matrix。

Ingress、协议与反向代理：先分流量入口的位置

判断问题：

1. 入口是 Kubernetes 集群内，还是传统主机或虚拟机的 Web 入口？
2. 配置变更频率如何，能否接受 reload，是否需要动态服务发现？
3. 是否需要灰度、重试、熔断、限流、mTLS 等七层治理？
4. 静态资源、缓存、TLS 自动签发是否是核心需求？
5. 团队是否已有 Nginx 配置与排障经验？
6. 是否需要 Gateway API、多租户或独立控制面？
7. 服务间接口是简单资源调用，还是需要流式、双向、强类型契约和多语言客户端？
8. 性能和连接数要求是否来自自己的压测？

推荐路径：

• 传统 Web、静态资源、简单反向代理：Nginx；小团队、自动 HTTPS、配置简单：Caddy。
• Kubernetes Ingress：存量 ingress-nginx 应制定迁移计划；新部署优先 Gateway API，动态配置、多租户可评估 Envoy Gateway 或 Traefik。
• 四层或七层负载均衡、成熟健康检查：HAProxy。
• 服务网格和细粒度流量治理：Envoy，但通常由控制面生成配置。
• 服务间接口：REST/JSON 通用、调试简单；流式、双向、强类型契约与多语言客户端：gRPC，但要评估代理、浏览器和排障成本。
• 入口层的高可用、证书轮换和限流要与业务一起设计，不要最后补。

对比页：envoy-vs-nginx、haproxy-vs-nginx、nginx-vs-caddy、traefik-vs-nginx、envoy-gateway-vs-nginx-ingress、grpc-vs-rest。

容器运行时与编排：先问单机还是集群

判断问题：

1. 目标是本地开发或单机容器，还是多节点编排？
2. 是否需要 rootless、daemonless、Pod 语义和 systemd 集成？
3. Kubernetes 使用哪个 CRI 运行时，节点操作系统与 cgroup 版本是否匹配？
4. 是否需要节点自动扩缩容、混合实例和成本优化？
5. 配置管理是模板渲染还是按环境叠加？
6. 部署采用 CI push 还是 GitOps pull？
7. 是否真的需要自建控制面，还是托管集群更合适？

推荐路径：

• 本地开发与单机：Docker 或 Podman；需要 rootless 或 daemonless：Podman。
• Kubernetes 运行时：containerd 是常见起点；OpenShift 等平台评估 CRI-O。
• 配置：Helm 适合打包分发，Kustomize 适合环境叠加，两者可以组合。
• 持续部署：Argo CD 或 Flux，按团队对界面、多集群和同步模型的偏好选。
• 节点扩缩容：Karpenter 或 cluster-autoscaler，按云厂商与调度需求评估。
• 新集群先确认 cgroup v2 与内核、发行版的兼容性。

对比页：docker-vs-podman、podman-vs-containerd、containerd-vs-cri-o、cgroup-v1-vs-v2、karpenter-vs-cluster-autoscaler、helm-vs-kustomize、argocd-vs-flux。

平台工程与 IaC

判断问题：

1. 需求是主机配置与批量执行、长期收敛，还是云资源声明式编排？
2. 是否已有 Terraform 状态、模块和流水线，团队能否治理状态锁、漂移与权限？
3. 云资源是否需要纳入 Kubernetes 控制面，是否愿意承担 CRD 与控制面运维？
4. 是否深度绑定单一云，愿意用原生模板换取集成度与锁定？

推荐路径：

• 主机配置与批量执行：Ansible 上手直接；需要长期收敛、强建模与集中治理：Puppet。
• 云资源声明式管理：Terraform 适合多云与模块复用；Ansible 负责配置与编排，不要用它维护长期云状态。
• 单云且大量用托管服务：CloudFormation 原生集成省事，但模板、回滚和权限绑定厂商。
• 已用 Kubernetes 并希望统一控制面：Crossplane；没有控制面运维能力时，不要为“统一”再叠一层平台。

对比页：ansible-vs-puppet、ansible-vs-terraform、terraform-vs-cloudformation、crossplane-vs-terraform。

操作系统、存储与基础设施：先分主机层与平台层

判断问题：

1. 目标是开发机、服务器还是混合团队，是否需要统一命令与脚本？
2. 文件系统更看重稳定与通用，还是快照、校验、压缩和卷管理？
3. 服务管理是传统 SysV 脚本，还是需要依赖排序、并行启动与日志集成？
4. 防火墙规则由发行版工具、Kubernetes 还是云安全组统一管理？
5. 下载与调试是否需要跟随链接、断点续传、认证和并发？
6. 编辑器要开箱即用、脚本化，还是需要异步插件与 LSP 生态？
7. 是否影响现有备份、监控与合规基线？

推荐路径：

• 服务器以 Linux 为主；跨平台团队要区分 macOS 的 BSD 工具链与 Linux 的 GNU 行为，脚本先做兼容性验证。
• 服务器文件系统：ext4 或 XFS，按发行版默认与团队经验选；需要快照、校验、压缩和卷管理：评估 Btrfs 或 ZFS，并确认内核支持与运维能力。
• init：新系统优先 systemd 生态；存量 SysV 环境先评估迁移收益和依赖脚本，不要只换启动器。
• 防火墙：现代 Linux 发行版评估 nftables；存量 iptables 规则要核对兼容层与迁移窗口，云上还要与安全组分层。
• CLI：curl 适合 API 调试与多协议，wget 适合镜像下载与递归抓取；两者都可能已预装，不必二选一。
• 工具链：Vim 轻量、通用、适合远端；Neovim 在异步插件、LSP 与配置生态上提供更多选择，代价是配置维护。

对比页：linux-vs-macos、linux-vs-windows、ext4-vs-xfs、btrfs-vs-zfs、systemd-vs-sysvinit、iptables-vs-nftables、curl-vs-wget、vim-vs-neovim。

RAG 与向量库：先问数据规模和检索形态

判断问题：

1. 向量检索是主业务，还是现有数据库的辅助能力？
2. 数据量是百万、千万还是亿级，增长速度如何？
3. 是否需要强元数据过滤、多租户和频繁更新删除？
4. 是否需要关键词加向量混合检索、重排和多路召回？
5. 推理是本地原型还是生产高吞吐，GPU 与并发需求是什么？
6. 是否需要分布式、存算分离和多种索引？
7. 团队能否运维独立向量库、推理框架和 GPU 集群？

推荐路径：

• 已有 PostgreSQL、数据量中小：pgvector，先不引入独立向量库。
• 原型和中小规模、强过滤：Qdrant。
• 亿级向量、分布式、多索引、存算分离：Milvus，并接受组件与运维复杂度。
• 本地原型、快速验证：Ollama；生产吞吐与批量推理：vLLM 或 SGLang。
• 先建立评测集，测召回率、延迟、成本和更新一致性，再决定是否扩容。

对比页：pgvector-vs-qdrant、qdrant-vs-milvus、ollama-vs-vllm、vllm-vs-sglang、version-eol-matrix。

横向原则

1. 先定义问题与验收标准：访问模式、一致性或交付语义、SLO、数据规模、增长预期。没有这些，产品对比没有意义。
2. 基准测试只用于筛选：厂商 benchmark 的硬件、数据分布、并发模型和配置通常与你的场景不同；用自采数据做小规模压测，记录 p50、p95、p99、错误率、资源占用和成本。
3. 把运维成本算进总拥有成本：集群部署、监控告警、备份恢复、升级、值班、招聘和培训都要计入。一个性能更好但团队不会排障的组件，长期成本更高。
4. 评估锁定与退出：托管服务、专有 API、私有协议、许可条款和数据导出方式都会影响迁移；至少保留可导出的原始数据和可替换的接口层。
5. 先做小规模验证：用真实流量影子测试或灰度，设定成功与失败门槛、回滚条件；验证备份恢复和故障切换，而不只是“能启动”。
6. 管理生命周期：核对版本支持窗口、EOL、升级路径和安全补丁，参考 platform-lifecycle-matrix 与 version-eol-matrix。
7. 保持可逆：优先选择能逐步替换、能被现有团队运维的方案，不要为尚未出现的十倍规模预支复杂度。

常见误区

• 只看基准测试排名或单个 QPS 数字，不看数据分布、查询形态和尾延迟。
• 把“能跑起来”当成“能长期运维”，忽略备份、升级、监控和故障演练。
• 忽略团队技能与值班成本，选了一个没人会排障的组件。
• 低估锁定风险：专有 API、托管服务限制、许可变化和数据迁移成本。
• 为未来规模过早引入分布式系统、独立向量库或多层消息架构。
• 用缓存当唯一数据源，用搜索库当主库，用消息队列当长期存储。
• 只看功能清单，不看限制条款、配额、版本差异和社区活跃度。
• 跳过小规模验证和回滚演练，直接全量上线。
• 把一次选型当成永久决定，没有定期复核机制。

相关命令

psql -c 'select version()'
redis-cli info memory
kafka-topics --bootstrap-server broker:9092 --describe --topic events
promtool check config prometheus.yml
nginx -t
kubectl get nodes -o wide

• 数据库与数据模型：database-selection-roadmap
• 可观测性建设：observability-roadmap
• RAG 上线检查：rag-production-checklist
• 迁移与切换：migration-readiness-checklist
• 具体迁移教程：migration-index
• 目标环境搭建：build-index
• Kubernetes 生产核对：k8s-production-checklist

参考链接

• PostgreSQL 文档
• Kubernetes 文档
• OpenTelemetry 文档

读完自测

合上页面，先回答，再展开对照。

1. 为什么选型要先回答访问模式和交付语义，而不是先比较产品功能？
2. 一个团队已有 PostgreSQL，日志量不大但需要按标签排障，RAG 数据在百万级，应如何分流？
3. 为什么厂商基准测试不能直接作为选型结论？验证阶段至少应记录什么？