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

CI/CD 管道

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

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

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

與服務(wù)器的交互

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

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

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

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

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

監(jiān)控、日志和警報：默默的保護者

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

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

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

警報服務(wù)

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

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

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

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

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

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

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

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

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

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