都說(shuō)隔行如隔山，每個(gè)行業(yè)多有很多“專(zhuān)業(yè)術(shù)語(yǔ)”，比如前端中就有：DOM、SPA、Tree Shaking、FCP 等概念。那么同理，后端中也會(huì)存在很多的專(zhuān)業(yè)術(shù)語(yǔ)，比如：負(fù)載均衡（Load Balancing）、API 網(wǎng)關(guān)（API Gateway）、消息隊(duì)列（Message Queue） 等。

那么，在日常的工作中，我們經(jīng)常需要和后端的同事溝通，特別是很多公司的 每日站會(huì) 上。因此，了解一些后端的專(zhuān)業(yè)術(shù)語(yǔ)，就顯得非常有必要了。

那么，今天咱們就來(lái)看看 7 個(gè)后端的專(zhuān)業(yè)術(shù)語(yǔ)！

1. 限流（Rate Limiting）

限流（Rate Limiting）是指限制某個(gè)客戶(hù)端（用戶(hù)、應(yīng)用或系統(tǒng)）在一段時(shí)間內(nèi)可以向服務(wù)器發(fā)送的請(qǐng)求次數(shù)。可以理解為給 API 訪(fǎng)問(wèn)加上了一道“限速門(mén)檻”，避免某個(gè)用戶(hù)或惡意攻擊者短時(shí)間內(nèi)瘋狂請(qǐng)求服務(wù)器，導(dǎo)致系統(tǒng)崩潰。

比如，在實(shí)際開(kāi)發(fā)中后端經(jīng)常會(huì)做這樣的限制：

一個(gè) API 規(guī)定 每個(gè) IP 每分鐘最多只能發(fā)送 100 次請(qǐng)求，如果某個(gè)用戶(hù)超出了這個(gè)限制，服務(wù)器就會(huì)返回 429 Too Many Requests 狀態(tài)碼，并拒絕響應(yīng)。

2. 負(fù)載均衡（Load Balancing）

負(fù)載均衡（Load Balancing） 表示：將大量用戶(hù)請(qǐng)求分發(fā)到多個(gè)服務(wù)器上，確保單個(gè)服務(wù)器不會(huì)因流量過(guò)大而崩潰。

比如：

如果所有用戶(hù)請(qǐng)求都涌向同一臺(tái)服務(wù)器，那么服務(wù)器很快就會(huì)很為請(qǐng)求過(guò)大而導(dǎo)致 響應(yīng)速度變慢，甚至死機(jī)（參考下一臺(tái)電腦開(kāi)了好多好多應(yīng)用，導(dǎo)致卡了）。但如果有一個(gè) 負(fù)載均衡器（Load Balancer），它可以智能地將請(qǐng)求分配到多臺(tái)服務(wù)器，讓每臺(tái)服務(wù)器的壓力均衡，那么就可以保證讓服務(wù)器壓力減小，變得“不卡”了

3. API 網(wǎng)關(guān)（API Gateway）

API 網(wǎng)關(guān) 是：前端訪(fǎng)問(wèn)后端的“統(tǒng)一入口”，相當(dāng)于一個(gè)“門(mén)衛(wèi)”，它會(huì)攔截所有的 API 請(qǐng)求，進(jìn)行 權(quán)限校驗(yàn)、請(qǐng)求轉(zhuǎn)發(fā)、限流、日志記錄 等功能。

所有的前端請(qǐng)求都必須要先通過(guò)API網(wǎng)關(guān)，才可以訪(fǎng)問(wèn)真正的接口。

4. 消息隊(duì)列（Message Queue）

這個(gè)概念其實(shí)前端中也有，本質(zhì)上還是屬于隊(duì)列的概念。其作用是：讓任務(wù)異步執(zhí)行，提高系統(tǒng)的吞吐量。下面是詳細(xì)的描述。

消息隊(duì)列（Message Queue）指的是：一種異步通信方式，允許系統(tǒng)中的不同組件先存入任務(wù)，然后再慢慢處理，避免因?yàn)槿蝿?wù)過(guò)多而導(dǎo)致系統(tǒng)崩潰。

比如：當(dāng)你在某個(gè)電商網(wǎng)站下單后，系統(tǒng)可能會(huì)：

1. 立即返回“下單成功”：但是此時(shí)可能下單并沒(méi)有真正成功，只是把當(dāng)前的下單狀態(tài)保存到了 消息隊(duì)列 里面。
2. 異步處理后續(xù)操作：然后再通過(guò)異步的方式，慢慢執(zhí)行后續(xù)的操作。這樣可以保證用戶(hù)的體驗(yàn)（速度快）

5. 微服務(wù)架構(gòu)（Microservices）

前端中有微前端，后端也有微服務(wù)。它們兩個(gè)在概念上有一定的相似性，最核心的目的都是為了 解耦和獨(dú)立部署！。但是，在技術(shù)特點(diǎn)上還是有一些區(qū)別的。

微服務(wù)架構(gòu)，出現(xiàn)的比微前端早。它把一個(gè)龐大的系統(tǒng)拆分成多個(gè)獨(dú)立的服務(wù)，每個(gè)服務(wù)負(fù)責(zé)一個(gè)特定的功能（比如用戶(hù)管理、訂單處理、支付系統(tǒng)等）。

6. 代理服務(wù)器（Proxy Server）

代理服務(wù)器的概念不是后端獨(dú)有的！但是很多同學(xué)可能不是很了解，所以單獨(dú)拿出來(lái)說(shuō)一下。

代理服務(wù)器是：一個(gè)中間服務(wù)器，它可以在客戶(hù)端（瀏覽器）和目標(biāo)服務(wù)器（后端 API）之間進(jìn)行請(qǐng)求轉(zhuǎn)發(fā)。 它的作用類(lèi)似于一個(gè)“中介”，負(fù)責(zé)接收用戶(hù)請(qǐng)求，然后幫用戶(hù)向目標(biāo)服務(wù)器請(qǐng)求數(shù)據(jù)。

比如，我們?cè)?nbsp;webpack 或者 vite 中的 proxy 就是 代理服務(wù)器

7. Webhook

Webhook 是：一種事件驅(qū)動(dòng)的消息推送方式。它允許服務(wù)器在某些事件發(fā)生時(shí)主動(dòng)通知客戶(hù)端，而不是讓客戶(hù)端不停地發(fā)送請(qǐng)求去輪詢(xún)服務(wù)器。有點(diǎn)類(lèi)似于 訂閱-通知。

具體例子：

假設(shè)你在 GitHub 上托管了一個(gè)項(xiàng)目，并希望在項(xiàng)目代碼有更新時(shí)，自動(dòng)觸發(fā)部署到服務(wù)器。那么就可以在 GitHub 上設(shè)置 Webhook，將其指向你的服務(wù)器 API。具體操作方式如下：

• 在 GitHub 配置 Webhook，URL 設(shè)為 https://sunday.com/deploy
• 當(dāng)代碼推送到 GitHub 時(shí)，GitHub 會(huì)向 https://sunday.com/deploy 發(fā)送一個(gè) POST 請(qǐng)求
• 你的服務(wù)器收到請(qǐng)求后，執(zhí)行自動(dòng)化部署