在你使用的每個(gè)完美應(yīng)用程序背后，都有一整套的架構(gòu)、測試、監(jiān)控和安全措施。今天，讓我們來看看一個(gè)生產(chǎn)就緒應(yīng)用程序的非常高層次的架構(gòu)。

CI/CD 管道

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

這確保我們的代碼從存儲庫經(jīng)過一系列測試和管道檢查，無需任何手動干預(yù)就進(jìn)入生產(chǎn)服務(wù)器。

它配置了像 Jenkins 或 GitHub Actions 這樣的平臺，用于自動化我們的部署流程。

與服務(wù)器的交互

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

它們確保用戶請求均勻分布在多個(gè)服務(wù)器上，即使在流量激增期間也能保持平穩(wěn)的用戶體驗(yàn)。

骨干：數(shù)據(jù)存儲和外部 API

我們的服務(wù)器還需要存儲數(shù)據(jù)。為此，我們還有一個(gè)不運(yùn)行在相同生產(chǎn)服務(wù)器上的外部存儲服務(wù)器。相反，它通過網(wǎng)絡(luò)連接。

我們的服務(wù)器可能還與其他服務(wù)器通信。而且我們可以有多個(gè)這樣的服務(wù)，不僅僅是一個(gè)。

監(jiān)控、日志和警報(bào)：默默的保護(hù)者

為了確保一切運(yùn)行順利，我們有日志記錄和監(jiān)控系統(tǒng)，對每個(gè)微觀交互保持敏銳的關(guān)注，存儲日志并分析數(shù)據(jù)。

將日志存儲在外部服務(wù)上是一種標(biāo)準(zhǔn)做法，通常不在我們的主要生產(chǎn)服務(wù)器上。

對于后端，像 PM2 這樣的工具可以用于日志記錄和監(jiān)控。對于前端，像 Sentry 這樣的平臺可以用于實(shí)時(shí)捕獲和報(bào)告錯(cuò)誤。

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

當(dāng)事情不按計(jì)劃進(jìn)行時(shí)，也就是我們的日志系統(tǒng)檢測到失敗的請求或異常時(shí)？

首先，它通知我們的警報(bào)服務(wù)。之后，推送通知被發(fā)送，以保持用戶的知情。從一般的“出現(xiàn)問題了”到具體的“支付失敗”，有效的溝通確保用戶不會被置于黑暗中，培養(yǎng)了信任和可靠性。

現(xiàn)代做法是將這些警報(bào)直接集成到我們常用的平臺中，如 Slack。

想象一下一個(gè)專門的 Slack 頻道，警報(bào)在問題出現(xiàn)的瞬間彈出。這使開發(fā)人員幾乎可以立即采取行動，在問題升級之前解決根本原因。

在生產(chǎn)環(huán)境中調(diào)試

之后，開發(fā)人員必須調(diào)試問題。

日志查看：首先，需要識別問題。我們之前提到的那些日志？它們是我們首選的工具。開發(fā)人員通過它們篩選，尋找可能指向問題源的模式或異常。

在安全環(huán)境中復(fù)制：黃金法則是——永遠(yuǎn)不要直接在生產(chǎn)環(huán)境中調(diào)試。相反，開發(fā)人員在‘staging’或‘test’環(huán)境中重新創(chuàng)建問題。這確保用戶不會受到調(diào)試過程的影響。

開發(fā)人員使用工具來查看運(yùn)行中的應(yīng)用程序并開始調(diào)試。

熱修復(fù)：一旦錯(cuò)誤修復(fù)，就會推出‘hotfix’。這是一個(gè)快速的、臨時(shí)的修復(fù)，旨在讓事情再次運(yùn)行起來。這就像在更永久的解決方案可以實(shí)施之前的一個(gè)補(bǔ)丁。