隨著雲端技術的發展，伺服器無法應用程式架構逐漸成為主流。本文深入探討伺服器無法應用程式實作的核心概念，涵蓋持續交付、GitOps、自動化佈署與釋出、以及技術檔案撰寫等關鍵環節。不同於傳統應用程式，伺服器無法應用程式高度依賴受管服務，因此需要獨特的佈署和維運策略。持續交付管道中的每個變更，無論大小，都應獨立佈署，以便快速追蹤問題並縮短修復時間。文章強調了 GitOps 的重要性，將 Git 倉函式庫視為單一事實來源，並在每次程式碼提交後自動觸發佈署。同時，也建議最佳化開發流程以利於實驗，並將生產環境視為常態，消除對佈署的恐懼。此外，文章也區分了佈署和釋出兩個階段，並介紹了黑暗釋出和功能標誌等釋出策略，以降低風險並提升交付效率。最後，文章強調了技術檔案的重要性，提倡撰寫高品質的檔案，而非追求數量。
實作伺服器無法應用
伺服器無法應用程式的其中一個關鍵差異在於使用受管理的服務。由於有許多受管理的服務、應用程式整合和配額在運作中，您的伺服器無法應用程式絕對是獨一無二的，不能輕易地與參考架構或其他實際應用程式進行比較。您需要佈署並執行您的應用程式，才能瞭解其行為並開始加強它。
持續交付要求每一個對您的應用程式的變更，無論是新的功能、錯誤修復或依賴升級，都必須個別佈署。為了了解這種方法的益處，您可以考慮引入一個錯誤到您的應用程式中，由玄貓捕捉。
在持續交付管道中，將錯誤的起源與特定的提交精確關聯起來將是微不足道的。在需要手動干預或批准且多個變更可以批次佈署到單一佈署的管道中，追蹤問題的根本原因在所有不同的程式碼變更中可能是一項艱鉅的任務。這可能會在您的管道中造成阻塞，因為您的團隊花費時間診斷問題，並且會降低您整合時間敏感性修補程式的能力。
採用持續伺服器無法交付
您可以使用以下一套來幫助您的團隊採用持續伺服器無法交付的做法：
- 實踐 GitOps：盡可能多地將您的應用程式、基礎設施和組態放入您的程式碼函式庫中，並將您的 Git 倉函式庫視為關於目前軟體版本的單一真相來源。始終在程式碼推播到您的主分支時觸發佈署到您的雲環境。
- 最佳化實驗：伺服器無法允許您解耦應用程式中的元件並定期迭代它們。為了確保這個演化平臺始終可用，最佳化您的開發工作流程以進行實驗。您的軟體的完整需求通常不會在前期知道，而且應用程式在生產環境中的行為（例如，受管理的服務、流量）也不會知道。將它釋出並觀察！
- 生產只是個名稱！
在第一天和隨後每一天釋出！
始終在程式碼提交到您的倉函式庫後盡快交付。只有在極端情況下才延遲。移除對佈署到生產環境的恐懼和儀式——使其正常化。
- 從鍵盤直接到生產。 為您的工程師提供從本地機器到遠端雲環境的直接管道。使每個階段的佈署都毫不費力，從原生程式碼變更（例如，透過 CDK 熱交換）到與其他貢獻整合，最終到生產。避免在本地機器上模擬雲，因為這會使您脫離直接到雲的反饋迴圈。
- 自動化一切。 管道中的手動批准表示缺乏對測試、容錯性或可觀察性的信心。手動干預應該完全從管道中移除，並用更好的測試、容錯性和可觀察性取代。
佈署與釋出不同
在實踐持續伺服器無法交付時，程式碼變更的佈署和釋出應該被視為分開的階段。佈署階段涉及將變更交付到您的 AWS 帳戶，透過建立或修改您的基礎設施或業務邏輯。釋出階段涉及將變更交付給您的應用程式使用者，並使該版本的應用程式公開可用。這樣，許多個別變更的增量佈署可能會累積起來形成一個功能釋出。
當面臨關於持續佈署業務關鍵應用程式（例如支付平臺）的疑問時，區分程式碼佈署和功能釋出給使用者可能尤其有用。新增手動批准過程和控制到此類別應用程式的佈署通常被建議，但這實際上違背了維護穩定的初衷，因為它會導致變更佇列。
相反，您可以透過玄貓區分佈署和釋出：
- 黑暗釋出 如果您的使用者不知道新的功能或無法輕易存取它，程式碼變更可以在不提供真實流量的情況下佈署和測試在生產環境中。這可以是您對完全新的和隔離服務的預設選項，因為它允許您在功能準備好使用之前經常釋出變更。
- 功能標誌 功能標誌允許您針對新功能釋出針對使用者群體。例如，您可以在向較大市場滾動之前為較小市場的使用者啟動功能。AWS AppConfig 可以用於管理和切換環境中的功能標誌。
金鶏
金鶏允許您針對新功能釋出針對使用者群體。例如，您可以在向較大市場滾動之前為較小市場的使用者啟動功能。AWS AppConfig 可以用於管理和切換環境中的功能標誌。
圖表翻譯：
graph LR
A[開始] --> B[GitOps]
B --> C[最佳化實驗]
C --> D[從鍵盤直接到生產]
D --> E[自動化一切]
E --> F[佈署與釋出不同]
F --> G[黑暗釋出]
G --> H[功能標誌]
此圖表描述了實作伺服器無法應用程式的步驟，從 GitOps 和最佳化實驗開始，到從鍵盤直接到生產、自動化一切，然後到佈署與釋出不同，最後到黑暗釋出和功能標誌。每一步驟都對應著實作伺服器無法應用程式的一個重要方面，並展示瞭如何將這些概念整合到一個協調的流程中，以達到高效且可靠的交付。
伺服器無法實作的核心概念
在實作伺服器無法時，逐步推出程式碼變更是一種有效的策略，可以避免一次性佈署所有變更。例如，可以先將變更佈署到10%的使用者，然後如果一切正常，五分鐘後再佈署到剩餘的90%的使用者。AWS CodeDeploy可以用於應用Lambda函式的藍綠佈署組態。當使用CodeDeploy時，失敗的佈署也可以自動回復。
交付管道的安全性、速度和可預測性
採用連續交付實踐的最大障礙通常是社會性的，而不是技術性的。團隊中的大多數工程師都曾在環境中工作過，在這些環境中，發布到生產環境是別人的責任，並且以最大程度的謹慎對待。 為了培養接受失敗和將交付轉化為習慣的文化，消除與發布到生產環境相關的儀式和恐懼至關重要。自動化管道的所有方面，從執行到監控，是將交付轉化為安全、快速和可預測的活動的關鍵。
自動化生產
自動化生產是豐田生產系統的12個支柱之一，是一種精益製造系統，經過多年的磨練，可以以最快和最有效的方式建造車輛並盡快交付給客戶。豐田將自動化生產描述為“設計裝置以自動停止並立即檢測和引起注意問題的原則……它還解放了操作員，使他們免於控制機器，可以專注於需要技能和判斷力的任務，而不是不斷監控每臺機器。” 簡單地說，自動化生產規定，如果生產線上出現故障，操作員有權停止生產以解決問題。 自動化生產原則可以應用於軟體交付管道：管道應該是可觀察的，阻礙或降低應用程式交付的問題應觸發警示，這些問題應該優先解決。
持續整合
持續整合是指定期將程式碼變更應用於應用程式原始碼的可發布版本。您可以將持續交付視為軟體交付生命週期的總體目標，而持續整合則是實際合並程式碼變更到已佈署程式碼函式庫的過程。 在版本控制系統中，如Git，持續整合通常涉及透過提取請求合並功能分支或直接提交本地變更到主幹分支（也稱為主幹開發）。如果使用功能分支策略，分支應該是短期的，提取請求應在開啟後不超過一天內審查和合並。
完美管道
最佳交付管道是指從鍵盤到生產環境最直接的路徑，同時為工程師提供對變更有效性和完整性的充分信心。 構建交付管道時，請嘗試優先考慮以下屬性：
- 原子性：給每個服務或堆積疊一個隔離的交付管道。
- 自動化：採用GitOps方法觸發根據程式碼函式庫中不同目錄變更合並到主幹分支的原子交付管道。
- 可觀察性：任何管道問題都應觸發警示到聊天應用程式或票務系統，並且可以診斷。
- 速度：定義管道的最大可接受執行時間，連續監控平均持續時間，並定期最佳化以確保管道始終盡可能高效。
檔案品質而非數量
生成清晰、準確和相關的檔案對於軟體專案或產品的持續成功至關重要，特別是在貢獻者、需求和技術隨著時間推移而發生變化時。有許多對團隊有用的檔案，但我們將關注技術檔案。
伺服器無應用程式實作
在實作伺服器無應用程式時，需要考慮多個層面，包括成本最佳化、安全性、測試和營運。企業團隊必須採取整體方法，結合這些層面，以確保應用程式的成功實作。
檔案品質優於數量
伺服器無應用程式的檔案是非常重要的，但不需要撰寫大量的檔案。相反，應該關注於撰寫高品質的檔案，涵蓋最重要的內容。這些內容包括：
- 貢獻：建立清晰的，描述如何構建、執行、測試和佈署服務。工程師應該能夠在第一天就開始工作。
- 解決方案設計：在實施之前，進行設計階段以確保應用程式的有效性和服務之間的整合。
- 架構圖：架構圖是理解系統架構和資料流的寶貴資源。可以包含關鍵組態細節，例如 SQS 超時或批次大小和 EventBridge 規則模式。
- API 檔案：任何 API，都應該充分檔案，以便於與服務的無縫和強大的整合。人類可讀的檔案可以從標準 schema 規範自動生成，例如 JSON Schema、OpenAPI 和 AsyncAPI。
- 狀態圖：Step Functions 工作流程的步驟和轉換可以視覺化為狀態圖。這些可以作為影像包含在解決方案設計中，並嵌入 README 檔案中使用 Mermaid。
- 事件結構：每個事件都應該檔案，包括事件捕捉的狀態變化描述和事件 payload 中每個欄位的描述，包括欄位的語義和語法。
解決方案設計
解決方案設計是一個至關重要的過程，需要結構化以確保設計出強大、可擴充套件的功能、服務和系統。解決方案設計檔案應該涵蓋需求收集、資料流、架構圖、資料建模、事件設計、威脅建模、可靠性、成本估算和可持續性等方面。
內容解密：
以上內容強調了伺服器無應用程式實作的重要性，包括檔案品質、解決方案設計和總結。透過這些內容，可以瞭解到伺服器無應用程式實作的關鍵層面和最佳實踐。
graph LR
A[伺服器無應用程式實作] --> B[檔案品質]
B --> C[解決方案設計]
C --> D[總結]
D --> E[最佳實踐]
圖表翻譯：
此圖表展示了伺服器無應用程式實作的關鍵層面，包括檔案品質、解決方案設計和總結。透過這個圖表，可以清晰地看到伺服器無應用程式實作的流程和最佳實踐。
伺服器無法應用程式正逐步改變軟體開發和佈署的格局。深入剖析其核心概念，可以發現持續交付、自動化和可觀察性是其成功的關鍵要素。本文探討了從GitOps到功能標誌等一系列最佳實務，也強調了區分佈署和釋出的重要性，以及如何利用黑暗釋出和功能標誌等技術來降低風險。
技術限制深析顯示，採用持續交付的最大挑戰往往並非技術層面，而是團隊文化。克服對生產環境佈署的恐懼，建立安全、快速且可預測的自動化管道至關重要。此外，本文也借鑒了豐田生產系統的「自動化生產」原則，強調了問題快速識別和解決的重要性。實務落地分析指出，檔案品質重於數量，清晰的貢獻、架構圖和API檔案等高品質檔案能有效提升團隊效率。同時，完善的解決方案設計流程，涵蓋需求收集、資料流、威脅建模等環節，是確保應用程式成功實作的根本。
展望未來，隨著伺服器無法技術的持續發展，預計相關工具鏈和最佳實務也將日趨成熟。跨領域技術融合，例如AI驅動的自動化測試和佈署，將進一步提升交付效率。同時，安全性和可觀察性也將持續受到關注，以應對日益複雜的應用程式環境。
玄貓認為，伺服器無法架構代表了雲原生應用程式發展的重要方向。對於追求快速迭代和高效交付的企業而言，積極探索並採用伺服器無法技術將是提升競爭力的關鍵策略。技術團隊應著重於培養持續交付文化，並建立完善的自動化流程，才能充分釋放伺服器無法架構的潛力。
