【從一台 Server 到分散式架構】第 25 篇：小明他們的系統變成這樣——完整架構總覽
小明坐在白板前，準備向新加入的工程師介紹系統架構。
他拿起筆，從最左邊開始畫：
「一開始，我們只有這樣……」
他在白板上畫了一個框：「前端」→「後端」→「資料庫」。
「然後，用戶越來越多，這樣就不夠了……」
接著，他一個元件一個元件加上去，每加一個都說了一個故事。二十分鐘後，白板上密密麻麻，新工程師眼睛都直了。
「等等，」新工程師說，「這些東西是怎麼一步一步長出來的？每個都是為了解決什麼問題？」
這就是這篇要做的事：把整個演進過程梳理一遍，給你一張看得懂的全景圖。
從起點到現在：架構演進的主軸
整個系列，架構演進可以分成幾個大的里程碑：
第一階段：單體起點（第 01-03 篇）
[前端] → [後端 API] → [資料庫]
一前一後一 DB。流量小時，完全夠用。
第二階段：資料庫優化（第 04-06 篇）
[前端] → [後端 API] → [Redis Cache] → [主庫(寫)] + [從庫(讀)]
加了索引、加了快取、做了讀寫分離——在不加機器的前提下，讓系統撐得更久。
第三階段：非同步化（第 07-08 篇）
[後端 API] → [Message Queue] → [Background Workers]
耗時的工作（發信、產生 PDF、推送通知）丟進佇列，非同步處理。
第四階段：水平擴充（第 03、09-10 篇）
[Load Balancer] → [後端 API × N 台]
↑ Session 放 Redis，無狀態設計
多台後端、無狀態設計，CAP 理論成為選型依據。
第五階段：微服務化（第 11-12 篇）
[API Gateway] → [訂單服務] [支付服務] [通知服務] [用戶服務]……
單體拆成多服務，各自部署、各自擴展。
第六階段：高流量防護（第 13-15 篇）
Rate Limiter → 限流 / 降級 / 熔斷
DB Sharding → 水平分片
多讀庫 → 讀流量分散
第七階段：多樣化儲存 + 即時能力（第 16-17 篇）
PostgreSQL（關聯）+ Elasticsearch（搜尋）+ InfluxDB（時序）
WebSocket Server + Redis Pub/Sub（即時推送）
第八階段：可觀測性 + 容器化（第 18-22 篇）
Prometheus + Grafana（監控）
結構化 Log + Jaeger（追蹤）
Docker（容器化）+ Kubernetes（編排）
etcd（分散式協調）
第九階段：AI 能力（第 23-24 篇）
LLM API + RAG + pgvector（AI 助理）
SSE 串流 + 推理佇列（AI 架構）
完整架構圖
每個元件，解決了哪個問題
| 元件 | 引入篇章 | 解決的問題 |
|---|---|---|
| Load Balancer | 第 03 篇 | 流量分散到多台後端 |
| Redis Cache | 第 05 篇 | 降低 DB 讀取壓力，加快熱門資料存取 |
| 讀寫分離 | 第 06 篇 | 讀多寫少場景下的 DB 擴展 |
| Message Queue | 第 08 篇 | 非同步處理，削峰填谷 |
| 無狀態設計 | 第 09 篇 | 多台後端可以不依賴本機狀態 |
| Rate Limiter | 第 13 篇 | 防止流量突增壓垮系統 |
| DB Sharding | 第 15 篇 | 單一 DB 容量不夠時水平分片 |
| Elasticsearch | 第 16 篇 | 全文搜尋，關聯式 DB 做不好 |
| WebSocket + Pub/Sub | 第 17 篇 | 即時推送通知 |
| 分散式鎖 / etcd | 第 18 篇 | 多台機器協調，避免重複執行 |
| Prometheus + Grafana | 第 19 篇 | 監控指標、視覺化、告警 |
| 結構化 Log + Jaeger | 第 20 篇 | Log 分析、跨服務追蹤 |
| Docker | 第 21 篇 | 環境一致性、部署標準化 |
| Kubernetes | 第 22 篇 | 容器排程、自癒、自動擴縮 |
| LLM + RAG + pgvector | 第 23 篇 | AI 根據私有知識庫回答問題 |
| SSE 串流 + 推理佇列 | 第 24 篇 | AI 回應體驗、GPU 資源管理 |
但大部分系統不需要所有這些
看到這張完整架構圖，可能會覺得：「好複雜，我們要全部都做嗎？」
不需要。
每個元件的引入，都是因為系統發展到某個規模，某個地方出現了真實的痛點。
重要的不是架構有多完整，而是每個元件你知道它解決什麼問題、什麼時候應該引入。
如果你的系統只有幾百個同時在線用戶，一前一後一 DB 加個 Redis 快取，可能完全夠用。你不需要 K8s，不需要 Kafka，不需要 Sharding。
引入複雜度，是要付出代價的：學習成本、維運成本、除錯複雜度。
小明在這個過程中學到最重要的一件事：
好的系統設計，是用當下夠用的最簡單架構，同時知道當哪個地方開始痛了，要往哪個方向走。
小結與預告
這篇不是新概念，而是一次完整的回顧——把 25 篇的演進壓縮成一張全景圖和一張對照表。
接下來的幾篇，我們要用同一套思維，去看幾個知名的系統是怎麼設計的：
- 第 26 篇：YouTube——大規模影片儲存與 CDN
- 第 27 篇：Uber——即時位置與派車佇列
- 第 28 篇：Twitter/社群動態——讀多寫多與時序設計
- 第 29 篇：ChatGPT 類系統——串流、佇列與模型服務
同樣的思維框架，不同的場景，看不同的取捨。