在你使用的每個(gè)完美應(yīng)用程序背后，都有一整套的架構(gòu)、測(cè)試、監(jiān)控和安全措施。今天，讓我們來看看一個(gè)生產(chǎn)就緒應(yīng)用程序的非常高層次的架構(gòu)。
CI/CD 管道
我們的第一個(gè)關(guān)鍵領(lǐng)域是持續(xù)集成和持續(xù)部署——CI/CD 管道。
這確保我們的代碼從存儲(chǔ)庫經(jīng)過一系列測(cè)試和管道檢查，無需任何手動(dòng)干預(yù)就進(jìn)入生產(chǎn)服務(wù)器。
它配置了像 Jenkins 或 Github Actions 這樣的平臺(tái)，用于自動(dòng)化我們的部署流程。
與服務(wù)器的交互
一旦我們的應(yīng)用程序投入生產(chǎn)，它就必須處理大量用戶請(qǐng)求。這由我們的負(fù)載均衡器和反向代理（如 Nginx）管理。
它們確保用戶請(qǐng)求均勻分布在多個(gè)服務(wù)器上，即使在流量激增期間也能保持平穩(wěn)的用戶體驗(yàn)。
骨干：數(shù)據(jù)存儲(chǔ)和外部 API
我們的服務(wù)器還需要存儲(chǔ)數(shù)據(jù)。為此，我們還有一個(gè)不運(yùn)行在相同生產(chǎn)服務(wù)器上的外部存儲(chǔ)服務(wù)器。相反，它通過網(wǎng)絡(luò)連接。
我們的服務(wù)器可能還與其他服務(wù)器通信。而且我們可以有多個(gè)這樣的服務(wù)，不僅僅是一個(gè)。
監(jiān)控、日志和警報(bào)：默默的保護(hù)者
為了確保一切運(yùn)行順利，我們有日志記錄和監(jiān)控系統(tǒng)，對(duì)每個(gè)微觀交互保持敏銳的關(guān)注，存儲(chǔ)日志并分析數(shù)據(jù)。
將日志存儲(chǔ)在外部服務(wù)上是一種標(biāo)準(zhǔn)做法，通常不在我們的主要生產(chǎn)服務(wù)器上。
對(duì)于后端，像 PM2 這樣的工具可以用于日志記錄和監(jiān)控。對(duì)于前端，像 Sentry 這樣的平臺(tái)可以用于實(shí)時(shí)捕獲和報(bào)告錯(cuò)誤。
警報(bào)服務(wù)
當(dāng)事情不按計(jì)劃進(jìn)行時(shí)，也就是我們的日志系統(tǒng)檢測(cè)到失敗的請(qǐng)求或異常時(shí)？
首先，它通知我們的警報(bào)服務(wù)。之后，推送通知被發(fā)送，以保持用戶的知情。從一般的“出現(xiàn)問題了”到具體的“支付失敗”，有效的溝通確保用戶不會(huì)被置于黑暗中，培養(yǎng)了信任和可靠性。
現(xiàn)代做法是將這些警報(bào)直接集成到我們常用的平臺(tái)中，如 Slack。
想象一下一個(gè)專門的 Slack 頻道，警報(bào)在問題出現(xiàn)的瞬間彈出。這使開發(fā)人員幾乎可以立即采取行動(dòng)，在問題升級(jí)之前解決根本原因。
在生產(chǎn)環(huán)境中調(diào)試
之后，開發(fā)人員必須調(diào)試問題。
日志查看：首先，需要識(shí)別問題。我們之前提到的那些日志？它們是我們首選的工具。開發(fā)人員通過它們篩選，尋找可能指向問題源的模式或異常。
在安全環(huán)境中復(fù)制：黃金法則是——永遠(yuǎn)不要直接在生產(chǎn)環(huán)境中調(diào)試。相反，開發(fā)人員在‘staging’或‘test’環(huán)境中重新創(chuàng)建問題。這確保用戶不會(huì)受到調(diào)試過程的影響。
開發(fā)人員使用工具來查看運(yùn)行中的應(yīng)用程序并開始調(diào)試。
熱修復(fù)：一旦錯(cuò)誤修復(fù)，就會(huì)推出‘hotfix’。這是一個(gè)快速的、臨時(shí)的修復(fù)，旨在讓事情再次運(yùn)行起來。這就像在更永久的解決方案可以實(shí)施之前的一個(gè)補(bǔ)丁。
