wehub-skill-sync
255 lines
8.9 KiB
Markdown
255 lines
8.9 KiB
Markdown
# 技术选型框架
|
||
|
||
后端与全栈技术选型的结构化决策框架。防止分析瘫痪，同时确保严谨评估。
|
||
|
||
**铁律：未经明确的取舍分析，不得做出任何技术选择。**
|
||
|
||
"我喜欢"和"这很热门"都不是工程论证。
|
||
|
||
---
|
||
|
||
## 阶段一：先定需求，再选技术
|
||
|
||
### 非功能性需求（量化！）
|
||
|
||
| 维度 | 问题 | 糟糕的回答 | 好的回答 |
|
||
|-----------|----------|-----------|-------------|
|
||
| 规模 | 多少并发用户？ | "很多" | "1K 并发，500 RPS 峰值" |
|
||
| 延迟 | 可接受的 p99 响应时间？ | "快" | "API < 200ms，报告 < 2s" |
|
||
| 可用性 | 需要的正常运行时间？ | "永远在线" | "99.9%（年停机 8.7 小时）" |
|
||
| 数据量 | 预计存储增长？ | "很多" | "100GB/年，1000 万行" |
|
||
| 一致性 | 强一致还是最终一致？ | "一致" | "支付强一致，信息流最终一致" |
|
||
| 合规性 | 监管要求？ | "有一些" | "GDPR 数据驻留欧盟，SOC 2 Type II" |
|
||
|
||
### 团队约束
|
||
|
||
- 团队规模与资深程度
|
||
- 团队已熟练掌握的技术
|
||
- 能否为此技术栈招到人？（查看招聘市场）
|
||
- 时间压力（几天还是几个月上线）
|
||
- 许可、基础设施、培训的预算
|
||
|
||
---
|
||
|
||
## 阶段二：评估矩阵
|
||
|
||
对每个选项按加权标准打分 1-5 分：
|
||
|
||
| 评估标准 | 权重 | 选项 A | 选项 B | 选项 C |
|
||
|-----------|--------|----------|----------|----------|
|
||
| 满足功能性需求 | 5× | _ | _ | _ |
|
||
| 满足非功能性需求 | 5× | _ | _ | _ |
|
||
| 团队经验 / 学习曲线 | 4× | _ | _ | _ |
|
||
| 生态成熟度（库、工具） | 3× | _ | _ | _ |
|
||
| 社区与长期 viability | 3× | _ | _ | _ |
|
||
| 运维复杂度 | 3× | _ | _ | _ |
|
||
| 招聘人才池 availability | 2× | _ | _ | _ |
|
||
| 成本（许可 + 基础设施 + 培训） | 2× | _ | _ | _ |
|
||
| **加权总分** | | _ | _ | _ |
|
||
|
||
**规则：**
|
||
- 任何选项在 **5× 标准上得 1 分** → 自动淘汰
|
||
- 选项间差距在 **10% 以内** → 选团队最熟悉的
|
||
- 选项间差距在 **15% 以内** → 进行**有时间限制的概念验证**（最长 2-5 天）
|
||
|
||
---
|
||
|
||
## 阶段三：决策树
|
||
|
||
### 后端语言 / 框架
|
||
|
||
```
|
||
什么类型的项目？
|
||
│
|
||
├─ REST/GraphQL API，快速开发
|
||
│ ├─ 团队熟悉 TypeScript → Node.js
|
||
│ │ ├─ 功能完备，企业级模式 → NestJS
|
||
│ │ ├─ 轻量灵活 → Fastify / Hono / Express
|
||
│ │ └─ 全栈 + React → Next.js API routes
|
||
│ ├─ 团队熟悉 Python
|
||
│ │ ├─ 高性能异步 API → FastAPI
|
||
│ │ ├─ 全栈，后台管理繁重 → Django
|
||
│ │ └─ 轻量级 → Flask / Litestar
|
||
│ └─ 团队熟悉 Java/Kotlin
|
||
│ ├─ 企业级，大型团队 → Spring Boot
|
||
│ └─ 轻量级，启动快 → Quarkus / Ktor
|
||
│
|
||
├─ 高并发，系统级
|
||
│ ├─ 微服务，网络编程 → Go
|
||
│ ├─ 极致性能，安全性 → Rust (Axum / Actix)
|
||
│ └─ 容错性 → Elixir (Phoenix)
|
||
│
|
||
├─ 实时（WebSocket、流式）
|
||
│ ├─ Node.js 生态 → Socket.io / ws
|
||
│ ├─ 可扩展的发布/订阅 → Elixir Phoenix
|
||
│ └─ 低延迟 → Go / Rust
|
||
│
|
||
└─ 机器学习 / 数据密集
|
||
└─ Python (FastAPI + ML libs)
|
||
```
|
||
|
||
### 数据库
|
||
|
||
```
|
||
什么数据模型？
|
||
│
|
||
├─ 结构化，关系型，ACID
|
||
│ ├─ 通用 → PostgreSQL ← 默认选择
|
||
│ ├─ 读密集，MySQL 生态 → MySQL / MariaDB
|
||
│ └─ 嵌入式 / 无服务器边缘 → SQLite / Turso / D1
|
||
│
|
||
├─ 半结构化，灵活 schema
|
||
│ ├─ 文档型 → MongoDB
|
||
│ ├─ 无服务器文档 → DynamoDB / Firestore
|
||
│ └─ 搜索密集 → Elasticsearch / OpenSearch
|
||
│
|
||
├─ 键值 / 缓存
|
||
│ ├─ 内存 + 数据结构 → Redis / Valkey
|
||
│ └─ 星球级 KV → DynamoDB / Cassandra
|
||
│
|
||
├─ 时间序列 → TimescaleDB / ClickHouse / InfluxDB
|
||
├─ 图 → Neo4j / Apache AGE (Postgres 扩展)
|
||
└─ 向量（AI 嵌入） → pgvector / Pinecone / Qdrant
|
||
```
|
||
|
||
**默认：** 从 PostgreSQL 开始。它能处理 80% 的使用场景。
|
||
|
||
### 缓存策略
|
||
|
||
| 模式 | 技术 | 何时使用 |
|
||
|---------|-----------|------|
|
||
| 应用缓存 | Redis / Valkey | 会话、频繁读取、限流 |
|
||
| HTTP 缓存 | CDN (Cloudflare/Vercel) | 静态资源、公开 API 响应 |
|
||
| 查询缓存 | 物化视图 | 复杂聚合、仪表盘 |
|
||
| 进程内缓存 | LRU（内存） | 配置、小型查找表 |
|
||
| 边缘缓存 | Cloudflare KV / Vercel KV | 全球低延迟读取 |
|
||
|
||
### 消息队列 / 事件流
|
||
|
||
| 模式 | 技术 | 何时使用 |
|
||
|---------|-----------|------|
|
||
| 任务队列（后台作业） | BullMQ / Celery / SQS | 邮件、导出、支付 |
|
||
| 事件流（回放、审计） | Kafka / Redpanda | 事件溯源、实时管道 |
|
||
| 轻量发布/订阅 | Redis Streams / NATS | 简单通知、广播 |
|
||
| 请求-回复（异步同步化） | NATS / RabbitMQ RPC | 内部服务调用 |
|
||
|
||
### 托管 / 部署
|
||
|
||
| 模式 | 技术 | 何时使用 |
|
||
|-------|-----------|------|
|
||
| 无服务器（自动扩缩） | Vercel / Cloudflare Workers / Lambda | 流量波动、按量付费 |
|
||
| 容器（可预测） | Cloud Run / Render / Railway / Fly.io | 流量稳定、运维简单 |
|
||
| Kubernetes（大规模） | EKS / GKE / AKS | 10+ 服务、团队有 K8s 经验 |
|
||
| VPS（完全控制） | DigitalOcean / Hetzner / EC2 | 工作负载可预测、对成本敏感 |
|
||
|
||
---
|
||
|
||
## 阶段四：决策文档
|
||
|
||
### ADR（架构决策记录）模板
|
||
|
||
```markdown
|
||
# ADR-{NNN}: {标题}
|
||
|
||
## 状态：提议 | 已接受 | 已废弃 | 被 ADR-{NNN} 取代
|
||
|
||
## 背景
|
||
我们在解决什么问题？有哪些因素在起作用？
|
||
|
||
## 决策
|
||
我们选择了什么以及为什么？
|
||
|
||
## 评估
|
||
| 标准 | 权重 | 选中方案 | 备选方案 |
|
||
|-----------|--------|--------|-----------|
|
||
|
||
## 影响
|
||
- 正面：...
|
||
- 负面：...
|
||
- 风险：...
|
||
|
||
## 已拒绝的备选方案
|
||
- 选项 B：因...被拒绝
|
||
- 选项 C：因...被拒绝
|
||
```
|
||
|
||
---
|
||
|
||
## 常见技术栈模板
|
||
|
||
### A：初创 / MVP（速度优先）
|
||
|
||
| 层 | 选择 | 理由 |
|
||
|-------|--------|-----|
|
||
| 语言 | TypeScript | 前后端统一语言 |
|
||
| 框架 | Next.js（全栈）或 NestJS（API） | 快速迭代 |
|
||
| 数据库 | PostgreSQL (Supabase / Neon) | 托管服务，慷慨的免费额度 |
|
||
| 认证 | Better Auth / Clerk | 无需维护认证代码 |
|
||
| 缓存 | Redis (Upstash) | 对无服务器友好 |
|
||
| 托管 | Vercel / Railway | 零配置部署 |
|
||
|
||
### B：SaaS / 商业应用（平衡）
|
||
|
||
| 层 | 选择 | 理由 |
|
||
|-------|--------|-----|
|
||
| 语言 | TypeScript 或 Python | 团队偏好 |
|
||
| 框架 | NestJS 或 FastAPI | 结构化、可测试 |
|
||
| 数据库 | PostgreSQL | 可靠、功能丰富 |
|
||
| 队列 | BullMQ (Redis) | 简单的后台任务 |
|
||
| 认证 | OAuth 2.0 + JWT | 标准、灵活 |
|
||
| 托管 | AWS ECS / Cloud Run | 可扩缩容器 |
|
||
| 监控 | Datadog / Grafana + Prometheus | 完整可观测性 |
|
||
|
||
### C：高性能（规模优先）
|
||
|
||
| 层 | 选择 | 理由 |
|
||
|-------|--------|-----|
|
||
| 语言 | Go 或 Rust | 最大吞吐量、低延迟 |
|
||
| 数据库 | PostgreSQL + Redis + ClickHouse | OLTP + 缓存 + 分析 |
|
||
| 队列 | Kafka / Redpanda | 高吞吐量流处理 |
|
||
| 托管 | Kubernetes (EKS/GKE) | 细粒度扩缩 |
|
||
| 监控 | Prometheus + Grafana + Jaeger | 指标 + 追踪 |
|
||
|
||
### D：AI / 机器学习应用
|
||
|
||
| 层 | 选择 | 理由 |
|
||
|-------|--------|-----|
|
||
| 语言 | Python（API）+ TypeScript（前端） | 机器学习库 + 现代 UI |
|
||
| 框架 | FastAPI + Next.js | 异步 + SSR |
|
||
| 数据库 | PostgreSQL + pgvector | 关系型 + 嵌入 |
|
||
| 队列 | Celery + Redis | 机器学习任务处理 |
|
||
| 托管 | Modal / AWS GPU / Replicate | GPU 访问 |
|
||
|
||
---
|
||
|
||
## 反模式
|
||
|
||
| # | ❌ 不要做 | ✅ 应该做 |
|
||
|---|---------|--------------|
|
||
| 1 | "X 在 HN 上火了" | 对照**你自己的需求**来评估 |
|
||
| 2 | 简历驱动开发 | 选团队能维护的 |
|
||
| 3 | "必须支持 100 万用户"（第一天） | 按当前需求的 10 倍构建，而非 1000 倍 |
|
||
| 4 | 评估好几周 | 限制在 3-5 天，然后做决定 |
|
||
| 5 | 不做决策文档 | 为每个重大选择写 ADR |
|
||
| 6 | 忽略运维成本 | 将部署、监控、调试成本纳入考量 |
|
||
| 7 | "以后重写" | 假设不会重写。慎重选择。 |
|
||
| 8 | 默认微服务 | 从单体开始，需要时再拆分 |
|
||
| 9 | 每个服务一个不同数据库（第一天） | 用一个数据库，有充分理由再拆分 |
|
||
| 10 | "谷歌就是这么做的" | 你不是谷歌。按**你自己的场景**来扩缩。 |
|
||
|
||
---
|
||
|
||
## 常见问题
|
||
|
||
### 问题 1："团队无法就框架达成一致"
|
||
|
||
**解决方法：** 限制在 3 天内。填写评估矩阵。如果分数相差在 10% 以内，选多数人熟悉的。写入 ADR。继续推进。
|
||
|
||
### 问题 2："我们选了 X，但它不合适"
|
||
|
||
**解决方法：** 检查沉没成本谬误。如果投入不到 2 周，立即切换。如果已超过 2 周，记录痛点并规划分阶段迁移。
|
||
|
||
### 问题 3："我们需要微服务吗？"
|
||
|
||
**解决方法：** 几乎肯定不需要。从一个结构良好的单体开始。仅在以下情况才提取为服务：(a) 不同扩缩需求，(b) 不同团队所有权，(c) 不同部署节奏。
|