# Web 框架原理
::: tip 🎯 核心問题
**代碼写好了,怎么讓全世界的人都能访問?** 這就像問:你是想開一家路邊小摊,還是經營一家跨国連鎖餐厅?後端架構的選择,决定了你的"餐厅"能服務多少顧客。
:::
---
## 1. 架構演進的動機
想象一下,你正在規划一次長途旅行。你可以選择骑自行車、開私家車、坐高鐵,或者乘飛機。每種方式都有其適用的場景:自行車適合短距離且想锻炼身體的情况,飛機则適合跨越大陸的長途旅行。
**後端架構的選择也是如此。**
從互聯網诞生到現在,後端架構經歷了多次重大變革。每一次變革都不是為了"追新潮",而是為了解决当時面臨的特定問题:
| 年代 | 核心問题 | 架構演進 |
| ----- | ------------------------ | ------------------- |
| 1990s | 如何把網站跑起來 | 物理服務器 |
| 2000s | 代碼越來越亂怎么維護 | 單體架構 + MVC |
| 2010s | 系统太大怎么擴展和協作 | 微服務 + 容器化 |
| 2020s | 如何降低運維成本和複雜性 | Serverless + 云原生 |
::: tip 📊 從表格中你能看到什么?
讓我们逐行解讀這张表:
**1990s → 2000s**:從"能跑就行"到"需要維護"。網站從静態頁面變成動態應用,代碼量激增,需要更好的組织方式。
**2000s → 2010s**:從"單機"到"分布式"。用户量爆炸式增長,單台服務器扛不住了,需要拆分系统,水平擴展。
**2010s → 2020s**:從"自己運維"到"云服務"。容器和微服務虽然強大,但運維成本太高,Serverless 讓開發者只關注業務邏輯。
**核心启示**:架構演進不是技術選型的游戏,而是**解决實际問题**的過程。每个階段都有其適用的場景,没有"最好的架構",只有"最適合的架構"。
:::
**了解架構演進的意義在于:**
1. **避免重複造輪子**:很多"新"概念其實早在几十年前就有雛形,了解歷史能讓你站在巨人的肩膀上
2. **做出合理的技術選型**:没有最好的架構,只有最適合当前階段的架構
3. **理解技術背後的權衡**:每一次架構演進都是在**開發效率**、**系统性能**、**運維複雜度**之間做取舍
4. **预判技術趨勢**:歷史總是押韵的,理解過去的演進規律有助于把握未來方向
---
## 2. 物理服務器時代 (1990s)
### 2.1 物理服務器概述
在互聯網刚起步時,後端就是一台放在機房裡的**物理服務器**(一台真實的電脑)。
::: tip 💡 通俗解釋
**物理服務器**就像你家裡的台式機,但它:
- 7×24小時不關機
- 放在專門的數據中心(有空調、UPS電源、消防系统)
- 有更快的網絡带宽(企業级光纤)
- 有固定的公網IP地址(全世界都能访問)
這就好比你家 vs 餐厅:你家只是偶尔做飯,餐厅则是專業厨房,全天候營業,設備更專業。
:::
### 2.2 核心特點
- **單機部署**:所有應用運行在一台物理機上
- **手動運維**:需要人工上架、布线、安装系统
- **垂直擴展**:性能不够時只能買更強的機器
::: details 🔧 垂直擴展 vs 水平擴展
**垂直擴展**(Scale Up):升级單台服務器的配置(更多CPU、更大內存、更快硬盘)。
**水平擴展**(Scale Out):增加更多服務器,讓它们一起工作。
**比喻**:
- 垂直擴展:把小餐厅改成大餐厅,装修更豪华,但只有一个厨师
- 水平擴展:開連鎖店,每个店規模不大,但有100家分店
**優缺點**:
- 垂直擴展简單,但有上限(顶级服務器很贵,且有限制)
- 水平擴展理论上无限,但需要解决數據一致性問题
:::
### 2.3 痛點
- **慢**:每次改代碼都要手動上傳,然後重启服務器
- **贵**:擴容只能買更大的機器(垂直擴展)
- **難擴展**:一台機器顶住所有請求,CPU满載時就只能排队
### 2.4 物理服務器時代的優缺點
| 維度 | 評价 |
| ------------ | ------------------------------------------------------------ |
| **優點** | 完全掌控硬件,性能可预測;没有虚擬化開銷;數據物理隔離,安全性高 |
| **缺點** | 采購周期長(數周);前期投入大(CapEx);资源利用率低;擴容困難 |
| **適用場景** | 金融核心系统、政府涉密系统、對數據主權有嚴格要求的場景 |
::: tip 💡 CapEx vs OpEx
**CapEx**(Capital Expenditure):资本性支出,一次性投入大量资金購買硬件。
**OpEx**(Operating Expenditure):運營性支出,按使用量付費(如云服務器)。
**比喻**:
- CapEx:買房,一次性付几百万,之後每月只需交物業費
- OpEx:租房,每月交房租,不用一次性掏大钱
**云時代**的启示:Serverless 和云服務讓更多公司從 CapEx 轉向 OpEx,降低創業門槛。
:::
---
## 3. 單體架構時代 (2000s)
### 3.1 單體架構概述
隨着框架的出現(Rails / Django / Spring),大家把所有功能都塞進一个應用裡。
::: tip 💡 通俗解釋
**單體架構**(Monolith)就像一个超级商場:
- 服装區、食品區、電器區都在同一栋楼裡
- 所有员工在一个管理系统裡工作
- 如果整栋楼停電,所有區域都停止營業
對比微服務就像商業街:每家店独立運營,一家店關門不影響其他店。
:::
### 3.2 核心特點
- **單一代碼庫**:所有功能模塊在同一个项目中
- **共享數據庫**:所有模塊共用同一个數據庫
- **统一部署**:整个應用作為一个整體打包部署
### 3.3 優點
- **開發简單**:一个项目搞定所有功能
- **部署方便**:把一个大包扔到服務器上就行
- **調試容易**:本地启動就能調試所有功能
### 3.4 痛點:雪崩效應
想象一下,如果"切菜"的师傅不小心切到了手(代碼出了Bug),整个後厨都要停下來處理傷口,導致所有客人都吃不上飯。
這就是單體架構最大的風險:**隔離性差**。
::: details 🚨 真實的雪崩案例
某電商公司雙十一大促:
- 订單服務因為某个商品的价格計算錯误,抛出异常
- 异常没有被正确捕獲,導致线程池耗尽
- 所有後續請求(包括商品浏览、搜索、用户登錄)都被阻塞
- 整个網站彻底瘫痪,持續1小時
**如果用微服務**:
- 订單服務挂了,但商品浏览、搜索、用户登錄仍然可用
- 用户至少可以继續浏览商品,損失降到最低
:::
### 3.5 單體架構的優缺點與適用場景
| 維度 | 評价 |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **優點** | 開發简單,无需考虑分布式複雜性;調試方便,本地启動即可調試全功能;部署简單,一个包即可運行;事務管理容易,單機數據庫即可保證ACID |
| **缺點** | 代碼耦合度高,隨着業務增長代碼膨胀;技術栈單一,難以局部升级;擴展困難,只能整體擴容;故障隔離差,一个模塊故障影響全局;团队協作效率低,多人改同一套代碼 |
| **適用場景** | 初創公司MVP验證、小型团队(<10人)、業務相對简單、對交付速度要求高于擴展性的場景 |
| **不適用場景** | 大型团队并行開發、需要频繁發布不同模塊、某些模塊需要独立擴容的場景 |
::: tip 🎯 初學者建议
如果你正在學習後端開發,**強烈建议從單體架構開始**:
1. **先學會走路**:理解HTTP、數據庫、基本的MVC架構
2. **再考虑跑步**:当项目真的遇到擴展性問题,再考虑微服務
3. **避免過度設計**:很多公司的"微服務"其實是"分布式單體",更難維護
**學習路径**:
- 階段1:用 Spring Boot / Django / Rails 写一个完整的單體應用
- 階段2:遇到性能瓶颈時,尝試拆分出1-2个服務
- 階段3:当团队規模>50人,系统真的複雜了,再全面微服務化
:::
### 3.6 單體架構的技術栈
| 語言/框架 | 特點 | 代表企業 |
| -------------------------- | ---------------------------- | --------------------- |
| **Java + Spring** | 企業级開發首選,生態完善 | 阿裡巴巴、京東 |
| **PHP + Laravel/ThinkPHP** | 快速開發,適合中小型项目 | 早期 Facebook、微博 |
| **Python + Django/Flask** | 開發效率高,適合快速原型 | Instagram、Pinterest |
| **Ruby on Rails** | 约定優于配置,初創公司最爱 | GitHub、Twitter(早期) |
| **Node.js + Express** | 前後端统一語言,I/O密集型場景 | Netflix、Uber |
---
## 4. 容器化與微服務 (2010s)
### 4.1 微服務的動機
單體架構的痛點在2010年代集中爆發:
- **代碼太庞大**:一个项目几百万行代碼,新人入职要花一个月才能看懂
- **部署太慢**:構建一次要30分鐘,發布一次要小心翼翼
- **協作太難**:100个開發者改同一个项目,代碼衝突每天發生
- **擴展太贵**:只需要擴展"聊天服務",却要複制整个應用
**微服務的核心思想**:把大應用拆成多个小服務,每个服務:
- 独立開發、独立部署
- 有自己的數據庫
- 通過API通信
::: tip 💡 Docker是什么?
**Docker**就像是"集装箱":
- 每个集装箱裡有独立的货物(代碼 + 依賴庫 + 運行環境)
- 无论運到哪裡(哪台服務器),打開集装箱就能直接開工
- 不用擔心"我這台機器没有Python 3.9"、"那个機器缺少某个庫"
**比喻**:
- 没有 Docker:每次搬家,要把家具、電器、衣服一件件搬上卡車,到了新家再一件件摆好
- 有 Docker:所有東西打包進集装箱,卡車直接運走,到了新家放下就能用
**核心价值**:"一次構建,到處運行"。
:::
### 4.2 技術栈時間线
### 4.3 微服務架構
為了解决單體的問题,我们把大厨房拆成了很多个小厨房(服務):
- 專門负责用户的服務
- 專門负责订單的服務
- 專門负责支付的服務
### 4.4 Kubernetes 編排
当集装箱數量到達成百上千,就需要一个"港口調度系统":
- **Kubernetes (K8s)**:负责把容器安排到合適的機器上(調度、擴缩容、滚動更新)
- **Service Mesh**:负责服務之間的交通規则(熔断、限流、重試、可观測)
::: tip 💡 什么是"編排"?
**編排**(Orchestration)是指自動管理大量容器的系统。
**比喻**:
- 没有 K8s:你手動管理100个容器,哪个挂了要手動重启,哪个流量大了要手動加機器
- 有 K8s:你告诉它"我要這个服務一直有10个實例運行",它會自動完成:
- 哪台服務器资源充足,就把容器調度到那裡
- 容器挂了,自動重启
- 流量大了,自動擴容到20个實例
- 更新代碼時,滚動更新(先停1个舊實例,启動1个新實例,逐个替换)
**關鍵點**:微服務不是"拆開就好",真正的難點在于**治理和運維**。
:::
### 4.5 微服務與容器化的優缺點
| 維度 | 評价 |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **優點** | 服務独立部署,技術栈可异構;故障隔離,單个服務崩溃不影響全局;按需擴展,热點服務單独擴容;团队協作友好,不同团队负责不同服務;代碼庫更小,易于理解和維護 |
| **缺點** | 分布式複雜性高(網絡延遲、分布式事務、服務發現);運維成本高,需要專業的DevOps团队;調試困難,問题可能需要跨多个服務追蹤;數據一致性難以保證;部署和監控基础設施要求複雜 |
| **適用場景** | 大型团队(>50人)、業務複雜需要分模塊独立演進、某些模塊需要独立擴容、需要多語言技術栈、對可用性要求高的系统 |
| **不適用場景** | 小型团队、業務简單、流量小且穩定、没有專業運維团队的情况 |
::: details ⚠️ 微服務的陷阱
**陷阱1:分布式單體**
拆了10个微服務,但它们之間紧密耦合:
- 服務A調用服務B,服務B調用服務C,服務C又調用服務A
- 改一个功能,要同時改5个服務
- 部署時,必须按顺序依次部署,否则系统报錯
**這比單體更糟糕**:你擁有了單體的複雜性,又没有享受到微服務的独立部署好處。
**陷阱2:過度拆分**
把只有100行代碼的功能也拆成一个独立服務:
- 10个服務,每个只有100行代碼
- 服務間通信的開銷(網絡序列化/反序列化)比實际業務邏輯還重
- 運維成本爆炸:要部署、監控、日志收集10个服務
**正确做法**:從功能內聚的角度拆分,一个微服務應該是一个完整的業務能力(如"订單服務",而不是"订單創建服務"、"订單查询服務")。
:::
### 4.6 微服務技術栈
| 類別 | 技術/工具 | 作用 |
| ------------ | ---------------------------------- | -------------------- |
| **容器化** | Docker, containerd | 應用打包與隔離 |
| **編排調度** | Kubernetes, Docker Swarm | 容器管理與自動擴缩容 |
| **服務發現** | Consul, etcd, ZooKeeper | 服務注册與發現 |
| **API網關** | Kong, Zuul, Envoy | 统一入口、路由、限流 |
| **配置中心** | Apollo, Nacos, Spring Cloud Config | 集中配置管理 |
| **監控告警** | Prometheus, Grafana, ELK | 指標監控與日志分析 |
| **鏈路追蹤** | Jaeger, Zipkin, SkyWalking | 分布式請求追蹤 |
| **服務網格** | Istio, Linkerd | 流量治理與安全 |
---
## 5. Serverless 與云原生時代 (2020s+)
### 5.1 Serverless 的動機
微服務虽然好,但維護几十个小厨房還是很累。你需要擔心:
- 厨房够不够大?(服務器擴容)
- 停電了怎么辦?(高可用)
- 容器太多怎么管?(運維成本)
::: tip 💡 Serverless 不是真的"没有服務器"
**Serverless**的意思是"你不需要管理服務器",而不是真的没有服務器。
**比喻**:
- **物理服務器時代**:你買地、盖房、装修、僱厨师、買食材...全部自己來
- **云服務器時代**:你租一个已經装修好的餐厅,但自己僱厨师、管理運營
- **Serverless時代**:你只需要設計菜單,云端有共享厨房,有專業厨师,你下單他们做,按次付費
**核心變化**:
- 以前:買服務器 → 配環境 → 部署代碼 → 監控 → 擴容 → 維護
- 現在:写代碼 → 上傳 → 按使用量付費
**就像外卖**:你不需要厨房,只需要設計菜單,有人帮你做。
:::
### 5.2 Serverless概述
**Serverless = FaaS + BaaS**
**FaaS**(Function as a Service,函數即服務):
- 你只写函數(如"用户注册時發送欢迎郵件")
- 云厂商负责運行這个函數,自動擴缩容
- 典型代表:AWS Lambda、阿裡云函數計算
**BaaS**(Backend as a Service,後端即服務):
- 登錄 → Auth0 / Supabase Auth
- 支付 → Stripe
- 數據庫 → Supabase / Firebase / DynamoDB
- 消息 → Kafka / SQS
::: tip 🎯 Serverless 適用場景
**最佳場景**:
1. **潮汐流量**:外卖軟件,中午流量大,半夜没人。Serverless會自動在中午分配1000台機器,半夜缩减到0台
2. **事件驅動**:"用户上傳图片後,自動压缩图片"
3. **快速验證**:小团队、MVP、黑客松项目
**不適合場景**:
1. **長時間運行的任務**:视频轉碼(可能跑1小時,函數最大執行時間通常只有15分鐘)
2. **需要低延遲的應用**:高频交易(冷启動延遲可能几十毫秒到几秒)
3. **需要精细控制底層**:操作系统內核調優、GPU直接访問
:::
### 5.3 Serverless 與云原生的優缺點
| 維度 | 評价 |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **優點** | 零運維成本,開發者只需關注業務代碼;自動擴缩容,完美應對流量峰值;按需付費,无流量時成本接近零;快速上线,几分鐘即可部署全球;高可用內置,云服務自動處理故障轉移 |
| **缺點** | 冷启動延遲(几百毫秒到數秒);運行時長限制(通常5-15分鐘);調試困難,本地難以完全模擬云環境;供應商鎖定風險;不適合長時間運行或計算密集型任務;成本在高频持續流量下可能反超傳统方案 |
| **適用場景** | 事件驅動處理(图片處理、消息通知);潮汐流量應用(活動頁、促銷);快速原型验證和MVP;低频API或後台任務;无專职運維团队的小团队 |
| **不適用場景** | 需要持續低延遲的應用;長時間計算任務;對冷启動敏感的場景(高频交易);需要精细控制底層基础設施的場景 |
::: details 💰 成本對比:何時Serverless更贵?
**場景1:低频访問**
- 傳统服務器:每月$20(不管有没有人访問)
- Serverless:100万次請求 × $0.0002/次 = $20(僅在有流量時付費)
- **結论**:低频場景,Serverless更省钱
**場景2:高频持續访問**
- 傳统服務器:每月$20
- Serverless:1億次請求 × $0.0002/次 = $20,000
- **結论**:高频持續場景,傳统服務器更省钱
**場景3:潮汐流量**
- 傳统服務器:為了應對峰值,需要$100/月的服務器(平時资源利用率只有10%)
- Serverless:峰值時$20,平時几乎$0
- **結论**:潮汐流量場景,Serverless節省成本
**启示**:不要盲目上Serverless,要根據實际流量特征做成本測算。
:::
### 5.4 Serverless 技術栈與平台
| 類別 | 技術/平台 | 特點 |
| ------------ | ------------------------ | ---------------------------- |
| **FaaS平台** | AWS Lambda | 最早的FaaS服務,生態最成熟 |
| | Azure Functions | 微軟云集成度高,.NET友好 |
| | Google Cloud Functions | 與GCP服務深度集成 |
| | 阿裡云函數計算 | 国內生態完善,冷启動優化好 |
| | 騰讯云云函數 | 與微信生態整合 |
| | Vercel/Netlify Functions | 前端開發者友好,邊缘部署 |
| **BaaS服務** | Firebase | Google的移動端後端方案 |
| | Supabase | PostgreSQL的Firebase開源替代 |
| | AWS Amplify | AWS的移動和Web應用開發平台 |
| **部署工具** | Serverless Framework | 多云部署,社區活躍 |
| | Terraform | 基础設施即代碼 |
| | Pulumi | 用編程語言定義基础設施 |
---
## 6. 各架構階段對比與選型指南
### 6.1 架構演進全景對比
| 維度 | 物理服務器 | 單體架構 | 微服務+容器 | Serverless |
| ---------------- | ---------------------- | ------------------ | ------------------------ | ------------------ |
| **团队規模** | 1-5人 | 5-50人 | 50-500人 | 1-20人 |
| **部署複雜度** | 极高 | 低 | 极高 | 极低 |
| **運維成本** | 高 | 中 | 很高 | 低 |
| **擴展性** | 差 | 垂直擴展有限 | 水平擴展優秀 | 自動擴展 |
| **技術栈灵活性** | 无 | 單一 | 多样化 | 受限 |
| **冷启動** | 无 | 无 | 容器启動時間 | 有延遲 |
| **適用場景** | 遺留系统、特殊合規要求 | 初創公司、業務简單 | 大型互聯網公司、複雜業務 | 快速验證、事件驅動 |
### 6.2 技術選型决策树
```
開始選型
│
├─ 团队有專業運維人员?
│ ├─ 是 → 考虑微服務或物理機
│ └─ 否 → 继續判断
│
├─ 需要快速上线验證想法?
│ ├─ 是 → Serverless 或單體
│ └─ 否 → 继續判断
│
├─ 团队規模 > 50人?
│ ├─ 是 → 考虑微服務
│ └─ 否 → 继續判断
│
├─ 流量有明顯峰谷特征?
│ ├─ 是 → Serverless
│ └─ 否 → 單體架構(推荐初創)
│
└─ 特殊要求(合規、遺留系统)?
└─ 是 → 物理服務器
```
::: tip 🎯 初學者選型建议
**如果你是个開發者或小团队:**
1. **階段0 (學習)**:本地跑單體應用,理解HTTP、數據庫、基本架構
2. **階段1 (MVP)**:部署單體應用到云服務器(如阿裡云ECS、AWS EC2)
3. **階段2 (增長)**:当团队>10人、業務變複雜,考虑拆分出1-2个微服務
4. **階段3 (成熟)**:当团队>50人、流量百万级,全面微服務化
**關鍵原则**:不要一開始就上微服務,那是"過早優化"。讓架構隨業務成長而演進。
:::
### 6.3 不同場景下的推荐架構
#### 場景一:独立開發者/兼职项目
- **推荐架構**:Serverless (Vercel/Netlify) 或 單體應用
- **理由**:几乎零運維成本,按需付費,快速上线
- **示例技術栈**:Next.js + Vercel + Supabase
#### 場景二:初創公司MVP验證
- **推荐架構**:單體架構 + 云服務器
- **理由**:開發速度快,团队可以專注于業務邏輯而非基础設施
- **示例技術栈**:Spring Boot / Django / Rails + RDS + ECS
#### 場景三:成長型公司(10-50人团队)
- **推荐架構**:模塊化單體 或 輕量级微服務
- **理由**:開始面臨代碼耦合問题,但還不需要完整的微服務複雜度
- **示例技術栈**:Spring Cloud / Go Micro + Kubernetes
#### 場景四:大型互聯網公司
- **推荐架構**:微服務 + 服務網格 + 中台架構
- **理由**:团队規模大,業務複雜,需要独立的發布節奏和技術栈
- **示例技術栈**:自研RPC框架 + Istio + 自建PaaS平台
#### 場景五:事件驅動/潮汐流量應用
- **推荐架構**:Serverless + 事件總线
- **理由**:流量波動大,需要极致的成本優化和自動擴缩容
- **示例技術栈**:AWS Lambda + API Gateway + EventBridge
---
## 7. 總結與學習路线
### 7.1 核心要點
後端架構的演進,本质上是在做**加法**和**减法**:
| 時代 | 架構 | 開發者要做的事 | 運維要做的事 |
| :------------- | :----- | :--------------- | :----------------- |
| **物理時代** | 單機 | 写脚本、手動部署 | 維護機房與硬件 |
| **單體時代** | 一整塊 | 写所有業務邏輯 | 維護几台大服務器 |
| **微服務時代** | 拆分 | 關注單一業務 | 維護K8s集群(很累!) |
| **Serverless** | 函數 | 只写核心函數 | 喝茶(云厂商全包了) |
**關鍵洞察**:
- 架構演進不是"新技術取代舊技術",而是**適用場景的變化**
- 没有銀弹,每个架構都有其適用的邊界
- 選择架構要考虑:团队規模、業務複雜度、流量特征、運維能力
### 7.2 學習路线建议
根據你的职業階段,推荐以下學習路径:
#### 階段一:打好基础(0-1年)
**目標**:理解後端核心概念,能独立開發單體應用
- 掌握一門後端語言(Java/Python/Go任選其一)
- 學習HTTP協议和RESTful API設計
- 掌握關系型數據庫(MySQL/PostgreSQL)
- 了解緩存基础(Redis)
- 學習Git和基础Linux命令
- **實踐项目**:用單體架構完成一个CRUD應用(如博客系统、待辦事项)
#### 階段二:擴展能力(1-3年)
**目標**:理解分布式系统,能參與微服務開發
- 深入學習微服務架構和拆分策略
- 掌握Docker和Kubernetes基础
- 學習消息队列(Kafka/RabbitMQ)
- 了解分布式事務和一致性
- 掌握監控和日志(Prometheus/ELK)
- **實踐项目**:将單體應用拆分為3-5个微服務,使用Docker部署
#### 階段三:專業深化(3-5年)
**目標**:能設計大型系统,具備技術選型能力
- 深入理解云原生架構(Service Mesh、Serverless)
- 掌握容量規划和性能調優
- 了解多活架構和灾備設計
- 學習DDD(领域驅動設計)
- 培養技術判断力和架構思維
- **實踐项目**:設計一个支持百万级用户的系统架構,包含高可用、弹性伸缩等方案
### 7.3 持續學習资源推荐
**書籍**:
- 《設計數據密集型應用》(DDIA)- 分布式系统必讀
- 《云原生模式》
- 《微服務設計》
- 《领域驅動設計》
**在线资源**:
- AWS/Azure/阿裡云官方架構文檔
- CNCF(云原生計算基金會)项目文檔
- 各大公司技術博客(Netflix Tech Blog、阿裡技術公众号等)
---
## 8. 名词速查表(Glossary)
| 名词 | 全称 | 解釋 |
| :---------------- | :-------------------------------- | :------------------------------------------------ |
| **Backend** | - | 服務器端系统,负责處理業務邏輯、數據存儲和對外接口 |
| **CGI** | Common Gateway Interface | 早期動態網頁技術,通過脚本處理請求并返回結果 |
| **Monolith** | - | 單體架構,把所有業務邏輯打包在同一个應用中 |
| **Microservices** | - | 微服務架構,把業務拆分成多个独立服務 |
| **Container** | - | 容器化技術,把應用和依賴打包成可移植單元 |
| **K8s** | Kubernetes | 容器編排平台,用于調度、擴缩容和治理容器 |
| **Service Mesh** | - | 服務網格,负责微服務間通信治理、观測與安全 |
| **Serverless** | - | 无服務計算,開發者只写函數,平台自動運行與擴缩容 |
| **BaaS** | Backend as a Service | 即插即用的後端云服務(認證、數據庫、支付等) |
| **CI/CD** | Continuous Integration / Delivery | 持續集成與持續交付,自動化測試與部署流程 |
| **Observability** | - | 可观測性,利用日志/指標/追蹤理解系统運行狀態 |