我們總結了彈性伸縮的五個條件與六個教訓
前言
Cloud Native
彈性伸縮是雲端計算時代給我們帶來的一項核心技術紅利,但是 IT 的世界中,沒有一個系統功能可以不假思索的應用到所有的場景中。 這篇文章,我們將應用企業級分散式應用服務-EDAS 的客戶在進行系統架構設計時,在彈性場景下遇到的點滴做了一個系統的梳理,總結為五個條件和六個教訓分享給大家。
五個條件
Cloud Native
1、啟動無需手動干預
是否需要手動干預是彈性伸縮和手動伸縮的本質區別。在傳統應用的運維中,一個程序的啟動往往需要在機器上手動準備一系列的事情,如:環境搭建,依賴服務的配置梳理,本地環境配置調整等。如果是在雲上的應用可能還需要手動調整安全組規則,依賴服務的訪問控制等;但這些需要手動執行的動作在自動彈性時都會變得不可行。
2、程序本身無狀態
確切的說,無狀態主要是指業務系統執行時對於資料的依賴程度,資料是在程序執行的過程中產生的,產生的資料會對後來的程式行為產生持續的影響,程式設計師需要在編碼邏輯的時候,就考慮如果系統在一個新環境中重新拉起時,這份資料 是否對於行為會造成不一致的情況? 推薦做法是資料應該最終以儲存系統中為準,讓儲存計算做到真正的分離。
3、啟動的要快,走的要有“尊嚴”
彈性 , 尤其是雲上的彈性,其中一個特點是會進行得很頻繁。 尤其是流量突發型的業務,帶著一定的不確定性。 而啟動後的系統往往處在一個“冷”的狀態,啟動之後如何快速的“加熱”是彈性有效性的關鍵。 而在彈性結束之後,往往伴隨著一次自動的縮容,由於這個過程也是自動的,所以我們需要能從技術上能做到自動流量摘除的能力,這裡的流量不僅僅包括 HTTP/RPC,也包括訊息、任務(後臺執行緒池)排程等。
4、磁碟資料可丟失
在應用啟動過程,我們的應用程式可能會使用磁碟配置一些啟動依賴項之外;在程序執行的過程中,我們也會習慣性使用磁碟列印一些日誌,或者記錄一些資料。而彈性場景是程序快起快沒,沒了之後放在磁碟上的資料也都沒了,所以我們要做好磁碟資料丟失的準備,可能有人會問日誌怎麼處理?日誌應該通過日誌收集元件收走,進行統一的聚合、清洗和查閱。這一點在 12 factor apps 中也做了強調。
5、依賴的服務充分可用
成規模的業務系統,往往不是一個人在戰鬥。 最典型的架構中,也會使用到一些快取、資料庫等中心服務。 一個業務彈性擴容上來之後,很容易忽略中心依賴服務的可用性。 如果依賴服務出現不可用,對於整個系統可能就是一個雪崩的效應。
六個教訓
Cloud Native
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、事前沒做正確評估
雖然 雲端計算給彈性提供了近乎無盡的資源池,但這也只是解放了使用者預備資源的工作,而微服務系統本身複雜,單一元件的容量變化會產生全鏈路的影響,既解除一處風險之後系統瓶頸點可能會遷移,有些隱形約束也會隨著容量變化逐步顯現,所以做彈性策略大多數時候不能靠力大磚飛的思想,需要做好全鏈路的壓測、驗證,演練到適應於全域性的彈性配置; 我們還是建議事前從高可用的多個維度瞭解各種技術手段,形成多套預案以備使用。
尾聲
Cloud Native
雲原生場景下彈效能力更為豐富,可供彈性的指標也更具備業務定製能力。應用 PaaS 平臺(如企業級分散式應用服務 EDAS/ Serverless 應用引擎 SAE 等)能結合雲廠商在計算、儲存、網路上的技術基礎能力,能讓使用雲的成本更低。但是這裡對於業務應用會提出一點點挑戰(如:無狀態/配置程式碼解耦等等)。從更廣的側面來看,這是雲原生時代應用架構面臨的挑戰。不過應用越來越原生的話,雲的技術紅利也會離我們越來越近。
關注阿里云云原生,讓應用架構雲原生化助力更多企業數字化轉型!
- OpenKruise v1.3:新增自定義 Pod Probe 探針能力與大規模叢集效能顯著提升
- Koordinator v0.7: 為任務排程領域注入新活力
- 傳統大型國企雲原生轉型,如何解決彈性、運維和團隊協同等問題
- Dubbo 3 易用性升級之 Dubbo 官網大改版
- 阿里雲容器服務 ACK 產品技術動態(202208)
- RocketMQ Streams在雲安全及 IoT 場景下的大規模最佳實踐
- RocketMQ 5.0:無狀態代理模式的探索與實踐
- Apache RocketMQ 5.0 在Stream場景的儲存增強
- 快手 RocketMQ 高效能實踐
- RocketMQ DLedger架構在小米的大規模實踐
- 定時任務報警通知解決方案詳解
- Dubbo Mesh 總體技術架構方案
- 說說 Spring 定時任務如何大規模企業級運用
- 龍湖千丁基於 [email protected] 的雲原生智慧停車系統架構實踐
- 基於 RocketMQ 的 MQTT 服務架構在小米的實踐
- 開發者測評:相比 Harbor,我選擇 ACR 的三點原因
- 5 分鐘完成 ZooKeeper 資料遷移
- Fluid 助力阿里雲 Serverless 容器極致提速
- 遷移 Nacos 和 ZooKeeper,有了新工具
- Dubbo 3.1.0 正式釋出,資料面原生接入 Service Mesh