架构 on Snow

互联网架构演进：从单机到云原生，一篇讲清楚

Mon, 28 Sep 2026 20:17:30 +0800

互联网架构演进：从单机到云原生，一篇讲清楚

这篇文章基于视频《互联网架构就这？1个故事讲清楚》整理，并加入了一些工程化解释。它不是逐字稿，而是把视频里最有价值的那条线拎出来：架构不是一开始设计出来的，而是业务规模一步步逼出来的。

很多人学架构时会被一堆名词砸晕：负载均衡、读写分离、缓存、分库分表、RPC、注册中心、消息队列、微服务、Kubernetes……如果只背概念，很容易知道“有什么”，却不知道“为什么会出现”。

更好的理解方式是：把一个网站想象成从 0 开始长大。每次流量变大、数据变多、团队变大，原来的方案就会暴露一个瓶颈。于是架构升级一步，解决一个主要矛盾，同时引入新的复杂度。

阶段	当时最痛的问题	典型解法	新代价
单机架构	先把业务跑起来	应用、数据库、文件都放一台机器	扩展能力弱，单点明显
应用与数据分离	应用和数据库抢资源	独立应用服务器与数据库服务器	多一层网络调用
应用集群	单台应用扛不住并发	Nginx / HAProxy + 多应用节点	Session、部署一致性要处理
数据库读写分离	大量读请求压垮主库	主库写、从库读	主从延迟和读一致性问题
多级缓存	热点数据反复打到数据库	浏览器缓存、本地缓存、Redis、CDN	缓存穿透、击穿、雪崩、失效策略
分库分表	单库单表容量和写入到顶	垂直拆库、水平分表	跨库查询、分布式事务、全局 ID
CDN 与反向代理	跨地域访问慢，后端暴露风险高	CDN、Nginx、WAF、SSL 卸载	缓存刷新和边缘一致性
搜索与 NoSQL	SQL 不适合全文检索和多变结构	Elasticsearch、MongoDB、HBase 等	多存储同步和数据口径管理
分布式服务	单体越来越难维护和发布	RPC、注册中心、消息队列	服务治理、链路排障、最终一致性
微服务	服务继续膨胀，交付节奏不一致	网关、熔断、限流、追踪、配置中心	运维复杂度显著上升
容器化与云原生	服务太多，人工部署不可控	Docker、Kubernetes、CI/CD、云平台	平台建设和学习成本

核心脉络

架构演进最重要的不是“用了多少技术”，而是每一步都要回答三个问题：

问题	解释
当前瓶颈在哪里？	是 CPU 不够、数据库扛不住、网络太远，还是团队协作卡住了
引入什么组件解决？	负载均衡、缓存、分片、异步消息、服务拆分，各有适用边界
付出的代价是什么？	性能通常是用复杂度换来的，不能只看收益

单机时代的价值是快。一个小网站、一个后台系统、一个 MVP，最开始完全可以用一台机器跑应用和数据库。这个阶段追求的是低成本验证，而不是提前把 Kubernetes、服务网格、消息队列全搬进来。能用简单方案解决的问题，就不要过早分布式。

当流量变大，最先撞到的是资源竞争：应用在吃 CPU 和内存，数据库在吃磁盘 I/O 和缓存，两者混在一台机器上互相拖累。把应用和数据库拆到不同机器，是第一次非常自然的升级。

接下来，应用层通常比数据库层更容易横向扩容。多加几台应用服务器，再用 Nginx 或 HAProxy 做负载均衡，请求就能被分摊出去。这里会遇到第一个“分布式味道”的问题：用户 Session 不能只放在某台应用机器上，否则用户下一次请求被转发到另一台机器时就可能丢状态。

读流量继续增长后，数据库会成为核心瓶颈。多数互联网业务是读多写少，比如浏览商品、看文章、查资料、刷列表。于是主库负责写，从库负责读，读请求可以横向扩展。但这也意味着主从复制存在延迟：刚写完的数据，马上读从库时可能还没同步过去。

缓存是下一次大提速。浏览器缓存减少重复下载，CDN 把静态资源放到离用户更近的边缘节点，本地缓存减少进程外调用，Redis 这类分布式缓存挡住大部分热点读请求。缓存的本质是用空间换时间，但它不是免费午餐：缓存失效、脏数据、热点 Key、穿透和雪崩都需要设计。

数据层怎么长大

数据库的演进可以单独看成一条线：从一台主库，到主从复制，再到分片，再到多种存储协作。

数据问题	常见方案	适合场景
读多写少	主从复制、读写分离	商品详情、文章详情、资料页
热点读	Redis / 本地缓存 / CDN	首页、榜单、用户基础信息
单表太大	水平分表	订单、消息、日志、流水
业务边界清晰	垂直分库	用户库、商品库、订单库、支付库
全文检索	Elasticsearch	商品搜索、站内搜索、日志检索
灵活结构	MongoDB / 文档库	内容、配置、埋点、可变属性
海量写入	HBase / Cassandra / 时序库	监控、IoT、行为日志

分库分表不是“数据库优化的高级形态”，而是单库单表确实扛不住后的手段。它能把数据分散出去，也会带来跨库 Join 难、跨分片事务难、分页统计难、扩容迁移难等问题。

一个比较稳妥的经验是：先优化索引、SQL、缓存和读写分离；只有当数据量、写入量或单表维护成本真的压上来，再进入分库分表。架构升级要被证据推动，而不是被焦虑推动。

从单体到服务化

当系统功能越来越多，单体应用会从“简单”慢慢变成“沉重”。所有模块共用一套代码、一套数据库、一条发布流水线，一个小功能也要跟整个系统一起上线。团队变大后，代码冲突、发布排队、故障影响面都会变得很难受。

服务化的第一步是按业务边界拆开：用户服务、商品服务、订单服务、支付服务、库存服务、推荐服务。拆开之后，每个服务可以独立开发、独立部署、独立扩容。

但服务拆开后，新的问题马上出现：

新问题	需要的能力
服务地址动态变化	注册中心与服务发现
服务之间要高效调用	RPC / HTTP API / gRPC
下游故障会拖垮上游	超时、重试、熔断、降级
高峰写入冲击核心链路	消息队列削峰填谷
一个请求跨很多服务	链路追踪、日志聚合、指标监控
对外入口越来越乱	API 网关、认证、限流、路由

消息队列是服务化里非常关键的一块。它把同步调用变成异步事件，让订单创建、库存扣减、积分发放、短信通知、搜索索引更新等动作不必全部堵在一个请求里完成。代价是系统从“立即一致”变成“最终一致”，业务上要能接受中间状态。

微服务不是单体的反面，也不是架构的终点。它适合业务边界稳定、团队规模较大、部署节奏不同、局部扩容需求明显的系统。如果项目还小，团队也小，强行微服务反而会把工程复杂度提前引爆。

云原生解决的是交付问题

当服务数量来到几十、上百个，真正痛苦的往往不只是代码，而是交付和运维：环境不一致、发布步骤多、机器资源浪费、扩容靠人工、故障恢复慢。

Docker 先把应用和依赖打成标准镜像，解决“在我机器上能跑”的问题。Kubernetes 再把镜像调度到集群里，通过声明式配置维持期望状态：副本少了就补，节点挂了就迁，版本升级按策略滚动。

这时架构的关注点从“单个服务怎么写”扩展到“整个平台怎么运行”：

能力	云原生里的对应组件
构建与发布	CI/CD、镜像仓库、GitOps
运行与调度	Docker、containerd、Kubernetes
配置与密钥	ConfigMap、Secret、配置中心
弹性伸缩	HPA、自动扩缩容、弹性云资源
故障恢复	健康检查、自愈、滚动回滚
可观测性	Metrics、Logs、Tracing、告警

云原生并不是“把应用放进容器”这么简单。它更像是一套围绕自动化交付、弹性扩缩容和故障自愈建立起来的平台能力。

常见误区

误区	更合理的理解
一上来就微服务才高级	小系统先单体，等边界和压力清楚后再拆
上了 Redis 就不会慢	缓存命中率、淘汰策略、热点 Key 和回源保护同样重要
分库分表能解决所有数据库问题	它解决容量和吞吐，也会制造查询、事务、迁移复杂度
MQ 能保证绝对一致	MQ 更多是解耦和削峰，常见结果是最终一致
Kubernetes 会自动让系统高可用	K8s 提供平台能力，应用本身仍要处理超时、重试、状态和容量
架构越复杂越厉害	好架构是在当前约束下足够简单、足够可靠、可继续演进

最后可以用一张“什么时候升级”的表来压轴：

你看到的现象	优先考虑
单机 CPU / 内存 / I/O 长期打满	应用与数据库分离，或垂直扩容
应用层 QPS 扛不住	应用集群 + 负载均衡
数据库读压力高	索引优化、读写分离、缓存
热点数据重复查询	多级缓存、CDN
单表过大、写入变慢	分库分表、冷热分离
搜索体验差	Elasticsearch 等搜索引擎
单体发布慢、团队互相阻塞	按业务边界服务化
服务太多、部署混乱	容器化、Kubernetes、CI/CD

总结

互联网架构演进不是一条炫技路线，而是一条不断处理主要矛盾的路线：

先跑起来
  -> 扛住更多请求
  -> 保护数据库
  -> 拆开数据与业务边界
  -> 让服务独立交付
  -> 让平台自动化运行

如果只记一句话：架构升级的本质，是在业务增长带来的新瓶颈面前，用可接受的复杂度换取性能、可用性、可扩展性和交付效率。

真正好的架构师，不是把所有热门技术都塞进系统里，而是知道此刻最应该解决哪个问题，也知道每个方案会带来什么代价。

参考资料

原视频：互联网架构就这？1个故事讲清楚
辅助整理：互联网架构演进精读：从单机到云原生
B 站视频嵌入使用本站已有 bilibili shortcode；本文配图为基于内容重新绘制的本地 SVG。

一文搞懂 SaaS、PaaS、BaaS：那些五花八门的"aaS"到底是什么

Tue, 07 Jul 2026 23:10:08 +0800

一文搞懂 SaaS、PaaS、BaaS：那些五花八门的"aaS"到底是什么

SaaS、PaaS、IaaS、BaaS、FaaS、DaaS、AIaaS…… 满世界都是"aaS"。本文从三层模型讲起，逐个拆解它们的本质、责任划分与适用场景，最后给一张决策树，帮你下次选型不再发懵。

一、先搞懂：为什么会有这么多"aaS"？

想象你 2010 年开了一家创业公司，要做一款 App。那时你需要：

找机房、谈专线、买机柜
采购服务器，装系统、装数据库
配 Nginx、配负载均衡
部署业务代码、配置监控告警
凌晨三点被电话叫起来处理磁盘告警

光这些"非业务"的事就能耗掉一个小团队几个月。于是云厂商出现了，他们说：

“你不用买服务器了，我租给你；你不用装数据库了，我托管；你甚至不用写后端，我帮你写。”

XaaS 的本质就是把"非核心业务"的某一层打包成可按需使用的服务。X 是什么，就把什么服务化：

把软件服务化 → SaaS
把平台服务化 → PaaS
把基础设施服务化 → IaaS
把后端服务化 → BaaS
把函数服务化 → FaaS
……

理解了这个公式，再看满屏的"aaS"就不会眼晕了。下面我们从最经典的三层模型开始。

二、云服务三层模型：IaaS / PaaS / SaaS

这是云计算最经典的分层。从下到上：IaaS → PaaS → SaaS，越往上云厂商承担越多，越往下用户掌控越细。

2.1 IaaS：基础设施即服务

面向运维。云厂商把服务器、网络、存储虚拟化后按需出租，你拿到的是一台台虚拟机（或裸金属），剩下的 OS、中间件、应用全由你装。

典型产品：AWS EC2、阿里云 ECS、腾讯云 CVM、Azure VM、AWS S3、阿里云 OSS
你管：OS、运行时、应用、数据
厂商管：虚拟化、硬件、网络、机房
适合：需要底层控制权的团队，比如要跑自建 K8s、自管数据库、特殊内核模块

# 拿到一台 ECS 后，你还得自己干这些
ssh root@your-ecs
yum install -y nginx mysql
systemctl start nginx
# 凌晨三点被告警叫醒的也是你

2.2 PaaS：平台即服务

面向开发者。云厂商帮你把运行时（Java/Go/Node/Python）、中间件、部署流程都搭好，你只需要把代码扔上去，平台自动构建、部署、扩缩容。

典型产品：Heroku、Google App Engine、Vercel、Netlify、Render、阿里云 EDAS、腾讯云 TSF
你管：代码、数据、应用配置
厂商管：运行时、OS、虚拟化、硬件
适合：中小团队、创业项目，想专注业务不养运维

1
2
3

# Heroku 风格：一行命令上线
git push heroku main
# 不用关心服务器在哪、装了什么 OS

2.3 SaaS：软件即服务

面向最终用户。云厂商直接交付一个可用的软件，你开账号就能用，连代码都不用写。

典型产品：钉钉、飞书、Gmail、Notion、Salesforce、企业微信、Zoom、Shopify
你管：使用、配置、数据
厂商管：应用本身 + 全部底层
适合：协作、办公、CRM、HR 等通用需求，没必要自己造轮子

💡 一个判断技巧：如果你"开账号就能用"，那就是 SaaS；如果"要写代码再部署"，是 PaaS；如果"要先开虚拟机再装东西"，是 IaaS。

三、责任划分矩阵：谁在管哪一层

光看定义容易糊涂，画张矩阵图就清晰了。表格里蓝色是用户负责，灰色是厂商负责。

观察几个关键点：

数据永远归用户：哪怕是 SaaS，业务数据也是你的，云厂商不能动。这是合规底线。
IaaS 的边界在虚拟化层：你管 OS 以上，厂商管 Hypervisor 以下。
PaaS 把 OS 和运行时也接走了：你只面对"代码 + 数据"两件事。
SaaS 把应用层也接走：你只面对"使用 + 数据"。

经典段子：用 On-Prem 时，连空调坏了、机房漏水都是你的事。用 SaaS 之后，你只剩"我的数据归我"这一件事。

四、BaaS：让前端/移动开发者"少写后端"

BaaS（Backend as a Service）面向前端 / 移动开发者。它把"后端通用能力"——认证、数据库、文件存储、推送、云函数——打包成 SDK，前端调用即可，几乎不用写后端代码。

4.1 BaaS 提供的六大件

能力	解决什么	例子
认证 Auth	不用自己写登录注册、Token、OAuth	邮箱密码 / 微信 / Google 一键登录
数据库 DB	不用部署 MySQL/Mongo，直接 SDK 读写	Firestore / Supabase Postgres
存储 Storage	不用搭对象存储，SDK 直传图片视频	Firebase Storage / S3 直传
云函数 Function	写少量服务端逻辑（如发邮件、对账）	Firebase Cloud Functions
推送 Push	不用对接 APNs/FCM	FCM 模板消息
分析 Analytics	不用自己埋点统计	用户行为 / 漏斗 / 留存

4.2 BaaS vs PaaS：差在哪

很多人会把 BaaS 和 PaaS 混淆，关键区别在面向对象和抽象层次：

维度	PaaS	BaaS
面向	通用应用开发者	前端 / 移动开发者
抽象	“你的代码跑在我平台上”	“通用后端我帮你写好了，你调 SDK”
代码	你写完整后端	你几乎不写后端，只写前端
灵活	高（任意后端逻辑）	中（受 SDK 模型约束）

简单说：PaaS 给你"运行环境"，BaaS 给你"现成后端"。Heroku 是 PaaS，Firebase 是 BaaS，Vercel 介于两者之间（前端 PaaS + 边缘函数）。

4.3 BaaS 的甜蜜区与雷区

甜蜜区：

创业 MVP、个人作品：几天就能上线一个有登录、有数据库的 App
内容型/社交型小程序：CRUD 占大头，复杂逻辑少
Hackathon 项目：48 小时交付必备

雷区：

复杂业务逻辑：当你的"云函数"开始堆积上百个、互相调用时，调试和测试会很痛苦
强一致性事务：BaaS 默认的 NoSQL（如 Firestore）事务能力弱于关系型数据库
厂商锁定：SDK 渗透到前端代码每个角落，迁出成本极高
成本曲线：免费额度用完后，按调用次数计费可能比自建贵

实践经验：BaaS 适合"0 到 1"，不适合"100 到 1000"。一旦业务跑起来，往往要逐步把核心模块从 BaaS 迁回自建后端。

五、FaaS：函数即服务与无服务器架构

FaaS（Function as a Service）是"无服务器（Serverless）“的核心形态。你只写一个函数，云厂商负责：何时启动、跑几份、怎么扩缩、怎么计费。

5.1 FaaS 的四个特征

事件驱动：函数不会常驻，由 HTTP 请求、对象存储事件、消息队列、定时器等触发
按需启动：无请求时实例数为 0，不收钱；有请求时拉起实例处理
自动伸缩：QPS 高就加实例，从 0 到 10000 都不用你管
按用量计费：按执行时长 × 内存 × 调用次数，毫秒级计费

// AWS Lambda 风格：一个函数就是一个处理单元
exports.handler = async (event) => {
  const orderId = event.orderId;
  await sendNotification(orderId);
  return { statusCode: 200, body: 'OK' };
};

5.2 冷启动：FaaS 的阿喀琉斯之踵

第一次调用或长时间空闲后，云厂商需要拉镜像、初始化运行时，这段时间叫冷启动：

语言	典型冷启动
Node.js / Python	100–300ms
Java	500ms–3s
Go / Rust	50–200ms
C++（编译镜像）	100–500ms

应对方案：

Provisioned Concurrency（预留并发）：厂商始终保温一批实例，代价是要付"保温费”
精简依赖：Java 的 Spring 启动慢，换 Quarkus / GraalVM 原生镜像可大幅压缩
避免在 handler 外做重活：模块加载阶段的代码每次冷启动都会跑

5.3 FaaS 适合什么

✅ 突发流量：秒杀、抢购、IoT 海量上报
✅ 事件处理：图片上传后自动压缩、订单创建后发通知
✅ 定时任务：每天凌晨跑数据汇总
✅ Webhook 接收：接收 GitHub / Stripe 回调
❌ 长连接 / 流式：WebSocket、视频流不适合
❌ 重状态服务：函数实例是无状态的，状态要放外部 DB
❌ 超低延迟：冷启动无法保证 P99

5.4 BaaS + FaaS = Serverless

业内常说的"Serverless"通常指 BaaS + FaaS 的组合：

用 BaaS 搞定认证、数据库、存储
用 FaaS 写少量自定义逻辑

整个应用没有"常驻服务器"，按用量付费，自动伸缩。这是云原生演进的极致形态。

六、其他常见 XaaS 一览

除了上面五种，还有一堆"aaS"。这里挑常见的列一遍，方便对照：

名称	全称	一句话	代表产品
DaaS	Data as a Service	数据订阅/查询 API	天气 API、Bloomberg、企查查
AIaaS / MaaS	AI / Model as a Service	AI 能力 / 大模型 API 调用	GLM API、OpenAI、通义千问、文心一言
DBaaS	Database as a Service	托管数据库	RDS、MongoDB Atlas、PolarDB
CaaS	Containers as a Service	容器即服务	阿里云 ACK、AWS EKS、Google GKE
STaaS	Storage as a Service	对象存储	OSS、S3、COS、七牛云
NaaS	Network as a Service	网络即服务	CDN、SDN、Cloudflare
SECaaS	Security as a Service	安全即服务	WAF、DDoS 高防、Snyk
DRaaS	Disaster Recovery as a Service	灾备即服务	跨地域备份、容灾切换
WaaS / DaaS-桌面	Workspace / Desktop as a Service	工作空间 / 桌面云	阿里云无影、AWS WorkSpaces
ITaaS	IT as a Service	IT 整体外包	MSP 托管服务
BPaaS	Business Process as a Service	业务流程即服务	财务 SaaS、HR SaaS
iPaaS	Integration as a Service	集成即服务	Zapier、MuleSoft、Workato
VPaaS	Video Platform as a Service	视频即服务	声网、Twilio Video

注意 DaaS 有歧义：可以是 Data as a Service，也可以是 Desktop as a Service（桌面云）。结合上下文判断。

注意 BaaS 也有歧义：Backend as a Service 之外，有时也指 Blockchain as a Service（区块链即服务），如阿里云区块链服务。

七、如何选型：从团队到场景

没有最好的 XaaS，只有最匹配当前阶段的方案。下面这张决策树覆盖了 90% 的选型场景：

7.1 决策五步法

直接用现成软件就行？ → 选 SaaS（钉钉 / Notion / Salesforce）
要自己写代码？ → 进入下一步
前端为主，后端只是 CRUD？ → 选 BaaS（Firebase / Supabase）
是事件驱动 + 突发流量？ → 选 FaaS（Lambda / 函数计算）
有专职运维，需要底层控制权？ → 选 IaaS；否则 → 选 PaaS

7.2 按团队规模看典型组合

团队规模	典型组合	理由
个人 / 1–3 人	BaaS + SaaS	不写后端，专注产品
小团队 / 5–15 人	PaaS + DBaaS + SaaS	不养运维，用 PaaS 部署 + 托管数据库
中型 / 20–100 人	IaaS + CaaS + 部分 PaaS	开始有运维，自己跑 K8s，但用托管 DB
大型 / 100+ 人	混合云 + 多 XaaS	核心自建，非核心用 SaaS，关键能力用 IaaS

7.3 一个真实的组合案例

一个常见的中型 SaaS 创业公司技术栈：

代码托管         GitHub（SaaS）
CI/CD            GitHub Actions（SaaS）
监控告警         Datadog（SaaS / 监控 SECaaS）
日志             阿里云 SLS（PaaS）
应用部署         阿里云 ACK（CaaS / 跑在 IaaS 上）
数据库           PolarDB（DBaaS）
缓存             Redis 云版（DBaaS / PaaS）
对象存储         OSS（STaaS）
CDN              阿里云 CDN（NaaS）
大模型调用       GLM API（AIaaS / MaaS）

可以看到，真实项目几乎从不"只用一种 XaaS"，而是按层次组合：底层 IaaS 提供算力，中层用 DBaaS / CaaS / STaaS 减负，上层用 SaaS 处理通用需求。

八、避坑指南与趋势

8.1 三个常见坑

厂商锁定（Vendor Lock-in）
- BaaS / FaaS 的 SDK 渗透到代码每个角落，迁出成本极高
- 应对：核心模块抽象出适配层（Repository / Service 模式），关键逻辑可平迁
成本随用量爆炸
- FaaS 按调用次数计费，QPS 上去后可能比包年服务器贵
- 应对：监控用量曲线，高频稳定流量用包年实例，低频突发用 FaaS
数据合规边界
- SaaS 中"数据"始终归你，但物理存储在哪国、谁有访问权，要确认
- 应对：金融、医疗等敏感行业选私有化部署或本地化 region

8.2 三个趋势

PaaS 与 FaaS 融合
- Vercel、Netlify 把静态托管 + 边缘函数 + 服务端函数揉在一起，PaaS 与 FaaS 边界越来越模糊
MaaS 崛起
- 大模型 API（GLM、OpenAI）成为新一类"基础设施"，AIaaS 正在成为继 IaaS/PaaS/SaaS 之后的第四层
行业云 BPaaS
- 不只卖技术栈，还卖业务流程：金融云、医疗云、政务云把行业 know-how 也服务化

九、一张表收尾

模型	全称	面向	你管什么	厂商管什么	代表产品
IaaS	Infrastructure as a Service	运维	OS 及以上	虚拟化、硬件、网络	EC2 / ECS / CVM
PaaS	Platform as a Service	开发者	代码、数据	运行时、OS、硬件	Heroku / Vercel / EDAS
SaaS	Software as a Service	最终用户	使用、数据	全部	钉钉 / Notion / Salesforce
BaaS	Backend as a Service	前端/移动	UI、业务逻辑	通用后端能力	Firebase / Supabase
FaaS	Function as a Service	开发者	函数代码	触发、伸缩、计费	Lambda / 函数计算
DBaaS	Database as a Service	开发者	数据、Schema	数据库运维	RDS / MongoDB Atlas
CaaS	Containers as a Service	运维	容器、镜像	K8s 控制、节点	ACK / EKS / GKE
AIaaS/MaaS	AI/Model as a Service	应用集成方	Prompt、调用	模型、推理	GLM API / OpenAI

总结

一句话概括：XaaS = 把"X"服务化，让用户按需使用、按量付费。

IaaS 把硬件服务化，给运维用
PaaS 把运行环境服务化，给开发者用
SaaS 把软件服务化，给最终用户用
BaaS 把通用后端服务化，给前端/移动开发者用
FaaS 把函数服务化，给事件驱动场景用
其余的 DaaS / DBaaS / CaaS / AIaaS …… 都是把对应能力服务化的具体形态

下次再看到陌生的"aaS"，先用公式套一下：“它把什么服务化了？面向谁？我管什么？"，三问之后基本就能定位。

记住：选型不是越上层越好，而是越匹配越好。能用 SaaS 解决的别上 PaaS，能用 PaaS 解决的别上 IaaS；但如果你是金融核心系统，可能 On-Prem 才是唯一答案。技术选型的本质，是在"控制权、省心程度、成本"三者之间找平衡。

数据库全景指南：从 SQLite 到 MongoDB，一文搞懂选型与差异

Tue, 07 Jul 2026 21:04:00 +0800

数据库全景指南：从 SQLite 到 MongoDB，一文搞懂选型与差异

MySQL、PostgreSQL、MongoDB、Redis、Cassandra、Neo4j、Elasticsearch…… 数据库多到让人眼花。本文从分类、原理、模型、选型、组合五个维度，带你看清它们各自的边界与适用场景。

一、为什么会有这么多数据库？

先抛一个真实的尴尬场景：

新人入职第一天，被安排设计一个博客系统。他下意识打开 Navicat，建了一张 articles 表，写到第三天发现：文章正文要存富文本，字数可能上万；评论数据要嵌套在文章里；标签数量不固定；还要做全文搜索。继续用 MySQL 越写越别扭，最后只能上 ES 做搜索、MongoDB 存正文、MySQL 存元数据。

这不是个例。没有一种数据库能赢下所有场景，根本原因是存储需求里同时存在四组矛盾：

结构化 vs 灵活：业务模型固定还是多变
一致性 vs 可用性：要数据绝对正确，还是允许短暂数据不一致换可用性
规模 vs 性能：单机极致性能还是分布式海量吞吐
读写均衡 vs 海量写入：典型 Web 应用还是 IoT 流式写入

围绕这些矛盾，业界演化出了关系型、键值、文档、列族、图、搜索、时序、列存分析等 八大分支。每解决一组矛盾，就诞生一类新数据库。

二、数据库分类全景图

上图把主流数据库按"数据模型 + 适用场景"分成了 8 类。下面我们逐类展开，但在分类之前，必须先理解三个底层概念：ACID、CAP、BASE。它们决定了数据库的"性格"。

三、ACID vs BASE：两种一致性哲学

ACID：关系型数据库的承诺

ACID 是事务的四大保证，是关系型数据库压箱底的能力：

字母	含义	通俗解释
A Atomicity 原子性	事务要么全成功，要么全回滚	转账扣款和加款必须同时发生
C Consistency 一致性	事务前后满足所有约束	主键、外键、CHECK 不能被破坏
I Isolation 隔离性	并发事务互不干扰	MVCC + 锁机制保证
D Durability 持久性	提交后即使宕机也不丢	通过 WAL / redo log 实现

为 ACID 付出的代价：锁竞争、跨节点协调延迟、水平扩展难。这也是为什么单机 MySQL 通常撑到几千 QPS 就开始考虑读写分离。

BASE：分布式系统的妥协

当系统走向分布式，强一致性的代价过高，业界提出 BASE 作为 AP 系统的设计哲学：

BA Basically Available 基本可用：允许响应变慢、允许功能降级
S Soft State 软状态：允许存在中间状态
E Eventually Consistent 最终一致：不保证任意时刻一致，但保证最终收敛

关键认知：ACID 中的 C 是事务一致性（约束不被破坏），CAP 中的 C 是副本一致性（多节点数据相同），两者不是一回事。

四、CAP 定理：分布式系统的三角抉择

CAP 定理由 Eric Brewer 在 2000 年提出，断言：一个分布式系统最多只能同时满足 Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错）三者中的两个。

三个关键认知

① P 不可避免

真实分布式系统必然存在网络分区（交换机抖动、机房断连、节点宕机）。所以工程师实际上只能在 C 和 A 之间做选择：

分区时拒绝写入 → CP，保证数据正确，但牺牲可用性
分区时仍可读写 → AP，保证可用性，但允许数据短暂不一致

② 三种组合的典型代表

组合	牺牲项	典型数据库	典型场景
CA	分区容错	MySQL 单机、PostgreSQL 单机	传统单机业务
CP	可用性	HBase、MongoDB、Redis 集群	强一致优先的金融、配置
AP	一致性	Cassandra、DynamoDB、Eureka	高可用的社交、推荐

③ 同一业务可灵活切换

注册中心是个经典例子：ZooKeeper 是 CP，选举期间不可用；Eureka 是 AP，节点之间不强制同步。Netflix 选 Eureka，因为它能容忍注册信息短暂不一致，但不能容忍服务发现挂掉。

五、关系型数据库：稳如泰山的基石

关系型数据库以 二维表 + SQL + ACID 事务 为核心，是 90% 业务系统的默认选择。

5.1 五大主流 RDBMS 对比

数据库	厂商 / 协议	强项	适用场景
MySQL	开源（GPL/商业双协议）	生态成熟、运维资料最多	Web 应用、电商、CMS
PostgreSQL	开源（BSD）	复杂查询、JSON、PostGIS、扩展性强	复杂业务、地理数据、数据分析
SQLite	开源（公有领域）	嵌入式、零配置、单文件	移动端、嵌入式、原型、测试
Oracle	商业	企业级功能、稳定性、技术支持	银行、电信、政府核心系统
SQL Server	商业（微软）	与 .NET 生态深度集成	企业内部系统、Windows 环境

5.2 选型经验

个人项目 / 小工具：SQLite，单文件零配置
Web 应用首选：MySQL（运维生态好）或 PostgreSQL（功能强、复杂查询爽）
企业核心系统有预算：Oracle 或 SQL Server，看团队技术栈
要不要选 PostgreSQL 而不是 MySQL？ 如果业务里有复杂分析、地理数据、强约束、JSON 字段，PG 更合适；如果只是 CRUD + 简单关联，MySQL 更省心

5.3 关系型的硬伤

水平扩展难：分库分表后跨库 JOIN、事务都成噩梦，需要引入 ShardingSphere、Vitess 之类的中间件
Schema 变更贵：上亿行表加索引可能锁表几小时
高并发写入瓶颈：单机通常几千 QPS，靠缓存兜底

六、NoSQL 的崛起：四大家族

NoSQL（Not Only SQL）的核心动机：通过放松某个约束（一致性 / Schema / 关系），换取扩展性、性能或灵活性。

6.1 SQL vs NoSQL 数据模型对比

左图是关系型的方式：范式化拆表 + 外键关联，查 Alice 的订单要 JOIN 两张表。右图是文档型的方式：聚合存储 + 内嵌文档，Alice 的订单直接嵌在她的文档里，一次读取拿全。

两种模型各有利弊：

维度	关系型（SQL）	文档型（NoSQL）
Schema	严格固定	灵活可变
关联查询	JOIN 强	弱（要靠应用层）
数据冗余	低（范式化）	高（反范式）
事务	强 ACID	弱（多文档 4.0+ 才支持）
扩展性	垂直为主	易水平分片
适合	关系复杂、强一致	模型多变、读多写少

6.2 键值型：Redis

Redis 是最被低估的"瑞士军刀"。它表面上是个缓存，实际上能做：

缓存：最常见，热点数据加速
会话存储：分布式 Session
排行榜：ZSet 天生支持
消息队列：List / Stream
限流器：INCR + EXPIRE
分布式锁：SETNX / Redlock

选型提醒：Redis 是 CP 系统（集群模式下）—— 主节点挂掉会触发故障转移，期间集群不可用。不是所有 Redis 都"高可用"。

6.3 文档型：MongoDB

MongoDB 用 BSON（二进制 JSON）存储，每个文档自包含。它的甜点场景：

内容管理：文章、评论、附件，结构天然嵌套
IoT 设备元数据：不同设备字段不同，灵活 Schema 太香
快速迭代业务：需求变就加字段，不用 ALTER TABLE
日志聚合：MongoDB 的聚合管道 + 副本集很合用

坑点：MongoDB 4.0 才支持多文档事务，复杂事务场景慎用。索引设计不当会让查询慢到怀疑人生。

6.4 列族型：Cassandra / HBase

列族型数据库把"行"打散成"列族"，同一列的数据连续存储，对"按列聚合 + 海量写入"特别友好。

Cassandra：AWS Dynamo 论文的开源实现，无主架构，写入性能极强。Netflix、Instagram、Apple 都在用
HBase：基于 HDFS，强一致，适合离线大数据
ScyllaDB：用 C++ 重写的 Cassandra，性能高一个数量级

典型场景：时序数据、推荐特征存储、消息历史归档。Cassandra 在写入 QPS 上能轻松甩开 MySQL 一个数量级。

6.5 图型：Neo4j

如果业务核心是关系（不是表关联，而是多跳关系遍历），用图数据库比 SQL 递归查询快几个数量级。

// Neo4j 查询：找到 Alice 三度人脉里喜欢 Go 语言的人
MATCH (a:User {name:'Alice'})-[:KNOWS*1..3]-(friend:User)
WHERE friend.language = 'Go'
RETURN friend

典型场景：社交网络（好友推荐）、反欺诈（团伙识别）、知识图谱、IT 资产拓扑。

用 MySQL 写"找三度人脉"要用 4 层自连接，性能爆炸；Neo4j 用邻接表存储，时间复杂度近似 O(1)。

七、专用场景数据库：搜索 / 时序 / 列存

通用数据库做不到极致，专用数据库在特定领域把性能压榨到极限。

7.1 搜索引擎：Elasticsearch

ES 用 倒排索引 实现秒级全文检索，是 ELK（Elasticsearch + Logstash + Kibana）的核心。

商品搜索：分词、同义词、纠错、相关性排序
日志分析：海量日志聚合，按时间维度切片
可观测性：APM、链路追踪数据存储

重要认知：ES 不是数据库替代品。它写入延迟较高（近实时，1 秒刷新），不适合做强一致主存储。通常 MySQL 是真相源，ES 是搜索副本，通过 Canal/Debezium 同步。

7.2 时序数据库：InfluxDB / TimescaleDB

时序数据有显著特征：写多读少、按时间顺序、自动降采样、旧数据可丢弃。专用 TSDB 的写入性能比 MySQL 高 1-2 个数量级。

InfluxDB：Go 写的，单机性能强，TSM 存储引擎
TimescaleDB：PostgreSQL 扩展，能用 SQL，事务保证更好
Prometheus：监控专用，pull 模型
TDengine：国产，物联网场景优化

典型场景：服务器监控、IoT 传感器、金融行情、用户行为埋点。

7.3 列存分析：ClickHouse

OLAP 场景的核心诉求：扫描 TB 级数据，做 GROUP BY 聚合，秒级返回。行存数据库（MySQL）做这种扫描会读大量无关列，列存数据库只读需要的列，性能差几十倍。

-- ClickHouse 典型查询：秒级扫描 10 亿行
SELECT
    toDate(event_time) AS day,
    city,
    count() AS pv,
    uniq(user_id) AS uv
FROM events
WHERE event_time >= today() - 30
GROUP BY day, city
ORDER BY day DESC, pv DESC

对比：同样的查询，MySQL 要几十分钟，ClickHouse 通常 1 秒内。

八、数据库选型决策树

讲了这么多，实战怎么选？下图给出一份决策路径：

三条选型铁律

① 先 SQL，后 NoSQL

绝大多数项目从 MySQL / PostgreSQL 起步就够了。遇到具体瓶颈（缓存、搜索、海量写入、复杂关系）再引入对应专用数据库。一开始就上"全家桶"是过度设计。

② 没有银弹，组合使用

工业界真实系统几乎都是多库组合：核心业务用 MySQL/PG，缓存用 Redis，搜索用 ES，日志用 MongoDB/ES，监控用 InfluxDB，分析用 ClickHouse。让每个数据库只做它最擅长的事。

③ 团队熟悉度优先

再先进的数据库，没人会运维也是灾难。Cassandra 写入性能强，但运维门槛极高，国内很多团队踩坑后还是换回了 MySQL 分库分表。选团队能掌控的，而不是最潮的。

九、真实项目中的数据库组合架构

光说不练假把式。下图是一个典型电商系统的多库协同架构：

数据流拆解

① 写路径：订单服务先写 MySQL（强一致保证），同时发 Kafka 事件，下游消费者异步更新 ES 搜索索引和推荐系统特征库。这是经典的 “先写主库，再异步同步” 模式。

② 读路径：

请求类型	走的数据库	理由
商品详情	Redis 缓存 → MongoDB	缓存挡 95% 流量，回源用文档库装多变 SKU
商品搜索	Elasticsearch	倒排索引秒级响应
好友推荐	Neo4j	多跳关系遍历
个人订单	MySQL	强一致，按用户分库
监控大盘	InfluxDB	时序聚合，秒级出图

③ 监控旁路：所有服务通过 SDK 把指标推送到 InfluxDB，不参与业务主链路，监控挂掉不影响交易。这是旁路系统的设计铁律。

为什么要拆？

如果不拆，全塞进 MySQL 会发生什么？

商品搜索做 LIKE ‘%关键词%’ → 全表扫描，慢到超时
监控指标每秒几十万条写入 → MySQL 单机扛不住
好友推荐用 4 层自连接 → 几秒出不来结果
商品 SKU 字段每类目都不同 → ALTER TABLE 改到吐血

每个专用数据库的存在，都是为了 解决某一类 MySQL 不擅长的问题。

十、核心差异对照表

最后用一张表把主流数据库的关键指标摊开对比：

数据库	类型	一致性	Schema	事务	水平扩展	典型 QPS	适合场景
MySQL	关系	ACID	严格	强	难（需中间件）	几千	Web 主流
PostgreSQL	关系	ACID	严格	强	难	几千	复杂业务
SQLite	关系	ACID	严格	强	不可	单线程	嵌入式
Redis	KV	CP	无	弱	集群分片	10万+	缓存
MongoDB	文档	CP（可调）	灵活	4.0+ 多文档	易分片	几万	内容管理
Cassandra	列族	AP（可调）	灵活	弱	极易	10万+ 写入	海量写入
Neo4j	图	ACID	半结构	强	难	几千	关系网络
Elasticsearch	搜索	近实时	动态映射	弱	易分片	几万	全文搜索
InfluxDB	时序	CP	标签+字段	弱	集群版收费	10万+ 写入	监控指标
ClickHouse	列存	CP	严格	弱	易分片	100万+ 写入	大数据分析

总结

回到最初的问题：SQLite、MySQL、MongoDB 有什么区别？ 它们不是"谁更好"的关系，而是"为不同问题而生"的不同工具。

回顾本文核心要点：

没有银弹：每种数据库都是某组矛盾的产物，关系型解决一致性、NoSQL 解决扩展性、专用库解决极端场景
理论先行：理解 ACID / BASE / CAP，是看懂所有数据库设计意图的钥匙
SQL 不死：关系型依然是 90% 业务系统的默认选择，NoSQL 是补充而非替代
组合才是常态：工业界真实系统几乎都是多库协同，让每个数据库只做它最擅长的事
选型三铁律：先 SQL 后 NoSQL、没有银弹要组合、团队熟悉度优先

下一步行动建议：

审视你当前的项目：是不是把所有数据都塞在 MySQL 里了？哪些场景其实更适合专用数据库？
挑一个不熟的数据库试一试：Redis / MongoDB / ES 任选一个，跑一遍官方 Quick Start
关注 NewSQL：TiDB、CockroachDB、YugabyteDB 这些"既有 ACID 又能水平扩展"的下一代数据库正在崛起

记住：好的架构师不在于会多少种数据库，而在于知道每种数据库的边界在哪。

本文涉及的所有数据库选型都基于公开文档与工程实践，具体落地还需结合团队技术栈、运维能力、预算综合判断。