彈性伸縮是雲計算時代給我們帶來的一項核心技術紅利，但是 IT 的世界中，沒有一個系統功能可以不假思索的應用到所有的場景中。這篇文章，我們將應用企業級分散式應用服務-EDAS 的客戶在進行系統架構設計時，在彈性場景下遇到的點滴做了一個系統的梳理，總結為五個條件和六個教訓分享給大家。 ...
前言
彈性伸縮是雲計算時代給我們帶來的一項核心技術紅利，但是 IT 的世界中，沒有一個系統功能可以不假思索的應用到所有的場景中。這篇文章，我們將應用企業級分散式應用服務-EDAS 的客戶在進行系統架構設計時，在彈性場景下遇到的點滴做了一個系統的梳理，總結為五個條件和六個教訓分享給大家。
五個條件
1.啟動無需手動干預
是否需要手動干預是彈性伸縮和手動伸縮的本質區別。在傳統應用的運維中，一個進程的啟動往往需要在機器上手動準備一系列的事情，如：環境搭建，依賴服務的配置梳理，本地環境配置調整等。如果是在雲上的應用可能還需要手動調整安全組規則，依賴服務的訪問控制等；但這些需要手動執行的動作在自動彈性時都會變得不可行。
2.進程本身無狀態
確切的說，無狀態主要是指業務系統運行時對於數據的依賴程度，數據是在進程執行的過程中產生的，產生的數據會對後來的程式行為產生持續的影響，程式員需要在編碼邏輯的時候，就考慮如果系統在一個新環境中重新拉起時，這份數據是否對於行為會造成不一致的情況？推薦做法是數據應該最終以存儲系統中為準，讓存儲計算做到真正的分離。
3.啟動的要快，走的要有“尊嚴”
彈性，尤其是雲上的彈性，其中一個特點是會進行得很頻繁。尤其是流量突髮型的業務，帶著一定的不確定性。而啟動後的系統往往處在一個“冷”的狀態，啟動之後如何快速的“加熱”是彈性有效性的關鍵。而在彈性結束之後，往往伴隨著一次自動的縮容，由於這個過程也是自動的，所以我們需要能從技術上能做到自動流量摘除的能力，這裡的流量不僅僅包括 HTTP/RPC，也包括消息、任務（後臺線程池）調度等。
4.磁碟數據可丟失
在應用啟動過程，我們的應用程式可能會使用磁碟配置一些啟動依賴項之外；在進程運行的過程中，我們也會習慣性使用磁碟列印一些日誌，或者記錄一些數據。而彈性場景是進程快起快沒，沒了之後放在磁碟上的數據也都沒了，所以我們要做好磁碟數據丟失的準備，可能有人會問日誌怎麼處理？日誌應該通過日誌收集組件收走，進行統一的聚合、清洗和查閱。這一點在 12 factor apps 中也做了強調。
5.依賴的服務充分可用
成規模的業務系統，往往不是一個人在戰鬥。最典型的架構中，也會使用到一些緩存、資料庫等中心服務。一個業務彈性擴容上來之後，很容易忽略中心依賴服務的可用性。如果依賴服務出現不可用，對於整個系統可能就是一個雪崩的效應。
六個教訓
1.指標值設置不合理
彈性整體分為三個階段：指標獲取、規則計算、執行伸縮；指標獲取一般通過監控系統或者 PaaS 平臺自帶的組件獲取。基礎監控指標常見的如：CPU/Mem/Load 等。短期內有一些基礎指標數值會存在不穩定的特點，但是時間拉長，正常來看會處在一個“平穩”的狀態，我們設置指標的時候，不能以短時間的特征為依據，參考較長時間的某種水位數據才能設置一個合理值。且指標不宜過多，同時縮容指標要和擴容指標存在明顯的數值差。
2.把“延時”當指標
很多時候我們識別系統可用性的一個很大的判斷，就是看系統屏幕是不是在“轉圈圈”，即系統很慢。常理推斷，很慢就要擴容了。所以我們有一些客戶直接把系統的平均 RT 當成了擴容指標，但系統的 RT 是多維度的，比如 health check 一般都是很快的，這類 API 出現的頻率稍高一點，一下就拉低了平均值。也有的客戶會精確到 API 級別，可是 API 也是根據參數不同邏輯不一樣的從而造成 RT 不一樣。總之，根據延時去做彈性策略是很危險的一種做法。
3.指定單一的擴容規格
擴容規格指的是資源的規格，比如在雲上的場景中，對於同一種 4c8g 的規格，我們可以指定記憶體型、計算型、網路增強型等。但是雲上是一個大資源池，對於某一種規格，會存在售罄現象；如果我們只指定了單一的規格，就會出現資源無法提供而出現擴容失敗的情況。這裡最危險的還不是擴容失敗本身，是出現業務故障之後的排查過程會特別漫長。
4.只考慮RPC鏈路中的應用策略
針對單個應用往往都很簡單的，難的是整個業務場景的梳理。梳理思路一個簡單的辦法就是按照應用調用的場景進行，從應用間調用的場景來看，一般來說分為三種：同步（RPC，中間件如 Spring Cloud）、非同步（消息，中間件如 RocketMQ）、任務（分散式調度，中間件如 SchedulerX）。我們一般會很快整理出第一種情況，但是很容易忽略掉後面兩種。而後面兩種出現問題的時候，問題排查診斷又是最為耗時。
5.沒有配套相應的可視化策略
彈性伸縮是一個典型的後臺任務，在治理一個大集群的後臺任務的時候，最好是有一塊大屏進行直觀的可視化治理。對於擴容失敗的情形，不能靜默處理。如果是核心業務出現擴容失敗，可能帶來的就是直接的業務故障，但是故障真正發生時，很多時候不會去關心擴容策略是否生效，如果真是因為擴容造成的故障，也很難排查到這個點。
6.事前沒做正確評估
雖然雲計算給彈性提供了近乎無盡的資源池，但這也只是解放了用戶預備資源的工作，而微服務系統本身複雜，單一組件的容量變化會產生全鏈路的影響，既解除一處風險之後系統瓶頸點可能會遷移，有些隱形約束也會隨著容量變化逐步顯現，所以做彈性策略大多數時候不能靠力大磚飛的思想，需要做好全鏈路的壓測、驗證，演練到適應於全局的彈性配置；我們還是建議事前從高可用的多個維度瞭解各種技術手段，形成多套預案以備使用。
尾聲
雲原生場景下彈性能力更為豐富，可供彈性的指標也更具備業務定製能力。應用 PaaS 平臺（如企業級分散式應用服務 EDAS/ Serverless 應用引擎 SAE 等）能結合雲廠商在計算、存儲、網路上的技術基礎能力，能讓使用雲的成本更低。但是這裡對於業務應用會提出一點點挑戰（如：無狀態/配置代碼解耦等等）。從更廣的側面來看，這是雲原生時代應用架構面臨的挑戰。不過應用越來越原生的話，雲的技術紅利也會離我們越來越近。
作 者 | 孤弋
本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Summary_Five-Conditions-and-Six-Lessons-for-Elastic-Scaling.html
