本文包含一些常見模式，可協助工程師處理數百萬用戶存取的大規模服務。
根據作者的經驗，這並不是一個詳盡的列表，但確實 有效 建議。 那麼，讓我們開始吧。
翻譯有支持 .
入門級
下面列出的措施實施起來相對簡單，但影響很大。 如果您以前沒有嘗試過它們，您會對它們的顯著改進感到驚訝。
基礎設施即代碼
建議的第一部分是實施基礎設施即程式碼。 這意味著您必須採用程式設計方式來部署整個基礎架構。 聽起來很複雜，但我們實際上討論的是以下程式碼：
部署100台虛擬機
- 與Ubuntu
- 每個 2 GB RAM
- 他們將有以下程式碼
- 有了這些參數
您可以追蹤基礎架構的變更並使用版本控制快速還原它們。
我內心的現代主義者說你可以使用 Kubernetes/Docker 來完成上述所有工作，他是對的。
此外，您可以使用 Chef、Puppet 或 Terraform 提供自動化。
持續整合和交付
要建立可擴展的服務，為每個拉取請求建立一個建置和測試管道非常重要。 即使測試非常簡單，它至少會確保您部署的程式碼可以編譯。
每次在此階段，您都回答以下問題： 我的程序集能編譯並通過測試嗎？它有效嗎？ 這看起來似乎是一個很低的標準，但它解決了很多問題。
沒有什麼比看到這些蜱蟲更美麗的了
對於這項技術，您可以評估 Github、CircleCI 或 Jenkins。
負載平衡器
因此，我們希望運行負載平衡器來重定向流量並確保所有節點上的負載相等，或在發生故障時服務繼續：
負載平衡器通常可以很好地分配流量。 最佳實踐是保持平衡，這樣就不會出現單點故障。
通常，負載平衡器是在您使用的雲端中配置的。
請求的 RayID、相關 ID 或 UUID
您是否遇到過應用程式錯誤並顯示以下訊息： 「出了些問題。 保存此 ID 並將其發送給我們的支援團隊”?
唯一識別碼、相關 ID、RayID 或任何變體是允許您在請求的整個生命週期中追蹤請求的唯一識別碼。 這允許您在日誌中追蹤整個請求路徑。
使用者向系統A發出請求，然後A聯絡B，B聯繫C，將其儲存在X中，然後將請求傳回給A
如果您要遠端連接到虛擬機器並嘗試追蹤請求路徑（並手動關聯正在進行的呼叫），您會發瘋。 擁有唯一的識別碼讓生活變得更輕鬆。 這是隨著服務的發展可以節省時間的最簡單的事情之一。
中級
這裡的建議比前面的建議更複雜，但正確的工具可以使任務變得更容易，甚至為中小型公司提供投資回報。
集中記錄
恭喜！ 您已部署 100 個虛擬機器。 第二天，執行長過來抱怨他在測試服務時遇到的錯誤。 它會報告我們上面提到的相應 ID，但是您必須查看 100 台機器的日誌才能找到導致崩潰的機器。 需要在明天的演示之前找到它。
雖然這聽起來像是一次有趣的冒險，但最好確保您能夠在一個地方搜尋所有雜誌。 我使用 ELK 堆疊的內建功能解決了集中日誌的問題：它支援可搜尋的日誌收集。 這確實有助於解決尋找特定期刊的問題。 作為獎勵，您可以創建圖表和其他類似的有趣的東西。
ELK堆疊功能
監控代理
現在您的服務已啟動並運行，您需要確保其順利運行。 最好的方法是運行幾個 代理商，它們並行工作並檢查其是否正常工作以及是否執行了基本操作。
此時您檢查一下 運行構建感覺良好並且工作正常.
對於中小型項目，我推薦使用 Postman 來監控和記錄 API。 但一般來說，您只想確保有辦法知道何時發生中斷並及時收到通知。
根據負載自動縮放
這很簡單。 如果您有虛擬機器服務請求並且其記憶體使用率接近 80%，您可以增加其資源或向叢集添加更多虛擬機器。 自動執行這些操作非常適合負載下的彈性功率變化。 但您應該始終小心您花費的金額並設定合理的限額。
對於大多數雲端服務，您可以將其配置為使用更多伺服器或更強大的伺服器自動擴充。
實驗系統
安全推出更新的一個好方法是能夠為 1% 的用戶測試某些內容一小時。 當然，您已經看到了此類機制的運作。 例如，Facebook 向部分受眾顯示不同的顏色或更改字體大小，以了解用戶如何看待這些變化。 這稱為 A/B 測試。
即使發布一個新功能也可以從實驗開始，然後確定如何發布。 您也可以根據導致服務品質下降的功能「記住」或動態變更配置。
先進水平
這裡有一些很難實施的技巧。 您可能需要更多的資源，因此中小型公司將很難管理這一點。
藍綠部署
這就是我所說的「Erlang」展開方式。 當電話公司出現時，Erlang 得到了廣泛的使用。 軟體交換機開始用於路由電話呼叫。 這些交換器上軟體的主要目的是在系統升級期間不斷線。 Erlang 有一個很好的方法來載入新模組而不會使前一個模組崩潰。
此步驟取決於負載平衡器的存在。 假設您有軟體的版本 N，然後您想要部署版本 N+1。
您 我們可以 只需停止服務並在適合您的用戶的時間推出下一個版本並獲得一些停機時間。 但假設你有 真 嚴格的 SLA 條件。 所以，SLA 99,99% 表示你可以下線了 僅 每年增加 52 分鐘。
如果真想達到這樣的指標，需要同時進行兩次部署：
- 現在的那個（N）；
- 下一個版本（N+1）。
您告訴負載平衡器將一定比例的流量重新導向到新版本 (N+1)，同時主動監視迴歸。
這裡我們有一個運作良好的綠色 N 部署。 我們正在嘗試遷移到此部署的下一個版本
首先，我們發送一個非常小的測試，看看我們的 N+1 部署是否適用於少量流量：
最後，我們有一組自動檢查，我們最終會執行這些檢查，直到部署完成。 如果你 非常非常 小心，您還可以永久保存 N 部署，以便在出現不良回歸時快速回滾：
如果您想達到更高級的水平，請讓藍綠部署中的所有內容自動運行。
異常檢測和自動緩解
鑑於您擁有集中式日誌記錄和良好的日誌收集，您已經可以設定更高的目標。 例如，主動預測故障。 在監視器和日誌中追蹤功能，並建立各種圖表 - 您可以提前預測會出現什麼問題：
一旦偵測到異常，您就開始檢查服務提供的一些線索。 例如，CPU 負載的峰值可能表示硬碟發生故障，而請求的峰值可能表示您需要擴展。 這種統計數據可以讓您主動提供服務。
有了這些見解，您可以在任何維度進行擴展，並主動和被動地改變機器、資料庫、連接和其他資源的特徵。
就是這樣！
如果您正在開發雲端服務，那麼這個優先事項清單將為您避免很多問題。
原文章作者誠摯邀請讀者發表評論並進行修改。 本文作為開源、作者的拉取請求分發 .
關於該主題還可以閱讀什麼：
來源： www.habr.com