系統(tǒng)設(shè)計(jì)：生產(chǎn)環(huán)境中Web應(yīng)用程序的體系結(jié)構(gòu)

作者：wayn 2024-03-04 00:05:00

黃金法則是 — 切勿直接在生產(chǎn)環(huán)境中進(jìn)行調(diào)試。相反，開(kāi)發(fā)人員在“測(cè)試”環(huán)境中重新創(chuàng)建問(wèn)題。這可以確保用戶不會(huì)受到調(diào)試過(guò)程的影響。

您使用的每一個(gè)熱門應(yīng)用程序的背后，都有一個(gè)由架構(gòu)、測(cè)試、監(jiān)控和安全措施組成的軟件系統(tǒng)。今天讓我們看一下滿足生產(chǎn)環(huán)境應(yīng)用程序的高級(jí)架構(gòu)由哪些體系組成。

CI/CD 管道

我們的第一個(gè)關(guān)鍵領(lǐng)域是持續(xù)集成和持續(xù)部署——CI/CD 管道。

這確保了我們的代碼從存儲(chǔ)庫(kù)出發(fā)，經(jīng)過(guò)一系列測(cè)試和管道檢查，然后到達(dá)生產(chǎn)服務(wù)器，而無(wú)需任何手動(dòng)干預(yù)。

圖片

它配置了 Jenkins 或 GitHub Actions 等平臺(tái)，用于自動(dòng)化我們的部署流程。

負(fù)載均衡服務(wù)器

一旦我們的應(yīng)用程序投入生產(chǎn)，它就必須處理大量的用戶請(qǐng)求。這是由我們的負(fù)載均衡器和反向代理（例如 Nginx）管理的。

圖片

它們確保用戶請(qǐng)求均勻分布在多個(gè)服務(wù)器上，即使在流量高峰期間也能保持流暢的用戶體驗(yàn)。

數(shù)據(jù)存儲(chǔ)和外部 API

我們的服務(wù)器還需要存儲(chǔ)數(shù)據(jù)。為此，我們還有一個(gè)外部存儲(chǔ)服務(wù)器。它與應(yīng)用服務(wù)器之間通過(guò)網(wǎng)絡(luò)連接。

圖片

我們的服務(wù)器也可能與其他服務(wù)器進(jìn)行 API 通信。我們可以擁有很多這樣的服務(wù)，而不僅僅是一項(xiàng)。

圖片

監(jiān)控、日志和警報(bào)

為了確保一切順利進(jìn)行，我們需要擁有日志記錄和監(jiān)控系統(tǒng)，密切關(guān)注每一個(gè)微交互，存儲(chǔ)日志并分析數(shù)據(jù)。

圖片

將日志存儲(chǔ)在外部服務(wù)器上是標(biāo)準(zhǔn)做法，通常與我們的主生產(chǎn)服務(wù)器隔離開(kāi)來(lái)。

對(duì)于后端，可以使用 PM2 等工具進(jìn)行日志記錄和監(jiān)控。在前端，可以使用像 Sentry 這樣的平臺(tái)來(lái)實(shí)時(shí)捕獲和報(bào)告錯(cuò)誤。

圖片

警報(bào)服務(wù)

當(dāng)事情沒(méi)有按計(jì)劃進(jìn)行時(shí)，意味著我們的日志系統(tǒng)檢測(cè)到失敗的請(qǐng)求或異常？

首先，它通知我們的警報(bào)服務(wù)。之后，將發(fā)送推送通知以讓用戶了解情況。從一般的“出了問(wèn)題”到具體的“付款失敗”，有效的溝通可確保用戶不會(huì)被蒙在鼓里，從而培養(yǎng)信任和可靠性。

圖片

現(xiàn)代實(shí)踐是將這些警報(bào)直接集成到我們常用的平臺(tái)中，例如 Slack、釘釘、飛書(shū)、企業(yè)微信等。

圖片

想象一下一個(gè)專用的 Slack 通道，一旦出現(xiàn)問(wèn)題就會(huì)彈出警報(bào)。這使得開(kāi)發(fā)人員幾乎可以立即采取行動(dòng)，在問(wèn)題升級(jí)之前解決根本原因。

生產(chǎn)中的調(diào)試

問(wèn)題出現(xiàn)了后，開(kāi)發(fā)人員必須調(diào)試解決該問(wèn)題。

日志查找：首先，需要確定問(wèn)題。我們之前談到的那些日志？他們是我們的第一個(gè)調(diào)式選擇。開(kāi)發(fā)人員對(duì)它們進(jìn)行篩選，尋找可能指出問(wèn)題根源的模異常情況。

圖片

在安全環(huán)境中復(fù)制：黃金法則是 — 切勿直接在生產(chǎn)環(huán)境中進(jìn)行調(diào)試。相反，開(kāi)發(fā)人員在“測(cè)試”環(huán)境中重新創(chuàng)建問(wèn)題。這可以確保用戶不會(huì)受到調(diào)試過(guò)程的影響。

圖片