都說隔行如隔山，每個行業多有很多“專業術語”，比如前端中就有：DOM、SPA、Tree Shaking、FCP 等概念。那么同理，后端中也會存在很多的專業術語，比如：負載均衡（Load Balancing）、API 網關（API Gateway）、消息隊列（Message Queue） 等。

那么，在日常的工作中，我們經常需要和后端的同事溝通，特別是很多公司的 每日站會 上。因此，了解一些后端的專業術語，就顯得非常有必要了。

那么，今天咱們就來看看七個后端的專業術語！

1. 限流（Rate Limiting）

限流（Rate Limiting）是指限制某個客戶端（用戶、應用或系統）在一段時間內可以向服務器發送的請求次數。可以理解為給 API 訪問加上了一道“限速門檻”，避免某個用戶或惡意攻擊者短時間內瘋狂請求服務器，導致系統崩潰。

比如，在實際開發中后端經常會做這樣的限制：

一個 API 規定 每個 IP 每分鐘最多只能發送 100 次請求，如果某個用戶超出了這個限制，服務器就會返回 429 Too Many Requests 狀態碼，并拒絕響應。

2. 負載均衡（Load Balancing）

負載均衡（Load Balancing） 表示：將大量用戶請求分發到多個服務器上，確保單個服務器不會因流量過大而崩潰。

比如：

如果所有用戶請求都涌向同一臺服務器，那么服務器很快就會很為請求過大而導致 響應速度變慢，甚至死機（參考下一臺電腦開了好多好多應用，導致卡了）。但如果有一個 負載均衡器（Load Balancer），它可以智能地將請求分配到多臺服務器，讓每臺服務器的壓力均衡，那么就可以保證讓服務器壓力減小，變得“不卡”了

3. API 網關（API Gateway）

API 網關 是：前端訪問后端的“統一入口”，相當于一個“門衛”，它會攔截所有的 API 請求，進行 權限校驗、請求轉發、限流、日志記錄 等功能。

所有的前端請求都必須要先通過API網關，才可以訪問真正的接口。

4. 消息隊列（Message Queue）

這個概念其實前端中也有，本質上還是屬于隊列的概念。其作用是：讓任務異步執行，提高系統的吞吐量。下面是詳細的描述。

消息隊列（Message Queue）指的是：一種異步通信方式，允許系統中的不同組件先存入任務，然后再慢慢處理，避免因為任務過多而導致系統崩潰。

比如：當你在某個電商網站下單后，系統可能會：

• 立即返回“下單成功”：但是此時可能下單并沒有真正成功，只是把當前的下單狀態保存到了 消息隊列 里面。
• 異步處理后續操作：然后再通過異步的方式，慢慢執行后續的操作。這樣可以保證用戶的體驗（速度快）

5. 微服務架構（Microservices）

前端中有微前端，后端也有微服務。它們兩個在概念上有一定的相似性，最核心的目的都是為了 解耦和獨立部署！。但是，在技術特點上還是有一些區別的。

微服務架構，出現的比微前端早。它把一個龐大的系統拆分成多個獨立的服務，每個服務負責一個特定的功能（比如用戶管理、訂單處理、支付系統等）。

6. 代理服務器（Proxy Server）

代理服務器的概念不是后端獨有的！但是很多同學可能不是很了解，所以單獨拿出來說一下。

代理服務器是：一個中間服務器，它可以在客戶端（瀏覽器）和目標服務器（后端 API）之間進行請求轉發。 它的作用類似于一個“中介”，負責接收用戶請求，然后幫用戶向目標服務器請求數據。

比如，我們在 webpack 或者 vite 中的 proxy 就是 代理服務器

7. Webhook

Webhook 是：一種事件驅動的消息推送方式。它允許服務器在某些事件發生時主動通知客戶端，而不是讓客戶端不停地發送請求去輪詢服務器。有點類似于 訂閱-通知。

具體例子：

假設你在 GitHub 上托管了一個項目，并希望在項目代碼有更新時，自動觸發部署到服務器。那么就可以在 GitHub 上設置 Webhook，將其指向你的服務器 API。具體操作方式如下：

• 在 GitHub 配置 Webhook，URL 設為 https://sunday.com/deploy
• 當代碼推送到 GitHub 時，GitHub 會向 https://sunday.com/deploy 發送一個 POST 請求
• 你的服務器收到請求后，執行自動化部署