在你使用的每個完美應用程式背後，都有一整套的架構、測試、監控和安全措施。今天，讓我們來看看一個生產就緒應用程式的非常高層次的架構。

CI/CD 管道

我們的第一個關鍵領域是持續整合和持續部署——CI/CD 管道。

這確保我們的程式碼從儲存庫經過一系列測試和管道檢查，無需任何手動干預就進入生產伺服器。

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

與伺服器的互動

一旦我們的應用程式投入生產，它就必須處理大量使用者請求。這由我們的負載均衡器和反向代理（如 Nginx）管理。

它們確保使用者請求均勻分佈在多個伺服器上，即使在流量激增期間也能保持平穩的使用者體驗。

骨幹：資料儲存和外部 API

我們的伺服器還需要儲存資料。為此，我們還有一個不執行在相同生產伺服器上的外部儲存伺服器。相反，它透過網路連線。

我們的伺服器可能還與其他伺服器通訊。而且我們可以有多個這樣的服務，不僅僅是一個。

監控、日誌和警報：默默的保護者

為了確保一切執行順利，我們有日誌記錄和監控系統，對每個微觀互動保持敏銳的關注，儲存日誌並分析資料。

將日誌儲存在外部服務上是一種標準做法，通常不在我們的主要生產伺服器上。

對於後端，像 PM2 這樣的工具可以用於日誌記錄和監控。對於前端，像 Sentry 這樣的平臺可以用於實時捕獲和報告錯誤。

警報服務

當事情不按計劃進行時，也就是我們的日誌系統檢測到失敗的請求或異常時？

首先，它通知我們的警報服務。之後，推送通知被髮送，以保持使用者的知情。從一般的“出現問題了”到具體的“支付失敗”，有效的溝通確保使用者不會被置於黑暗中，培養了信任和可靠性。

現代做法是將這些警報直接整合到我們常用的平臺中，如 Slack。

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

在生產環境中除錯

之後，開發人員必須除錯問題。

日誌檢視：首先，需要識別問題。我們之前提到的那些日誌？它們是我們首選的工具。開發人員透過它們篩選，尋找可能指向問題源的模式或異常。

在安全環境中複製：黃金法則是——永遠不要直接在生產環境中除錯。相反，開發人員在‘staging’或‘test’環境中重新建立問題。這確保使用者不會受到除錯過程的影響。

開發人員使用工具來檢視執行中的應用程式並開始除錯。

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

• 系統設計概念系列文章

計算機的層次化架構

每個開發者都應該知道的7個原則

6個系統設計的基本概念

資料庫：系統設計的核心

• 圖解系列

系統設計中的快取技術：完整指南

關聯式資料庫的全景圖 

Redis 全景解析

當然架構設計、全景圖解系列還有很多,快來關注一起學習吧~