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