前言

彈性伸縮是云計算時代給我們帶來的一項核心技術(shù)紅利，但是 IT 的世界中，沒有一個系統(tǒng)功能可以不假思索的應(yīng)用到所有的場景中。 這篇文章，我們將應(yīng)用企業(yè)級分布式應(yīng)用服務(wù)-EDAS 的客戶在進行系統(tǒng)架構(gòu)設(shè)計時，在彈性場景下遇到的點滴做了一個系統(tǒng)的梳理，總結(jié)為五個條件和六個教訓分享給大家。

五個條件

1、啟動無需手動干預(yù)

是否需要手動干預(yù)是彈性伸縮和手動伸縮的本質(zhì)區(qū)別。在傳統(tǒng)應(yīng)用的運維中，一個進程的啟動往往需要在機器上手動準備一系列的事情，如：環(huán)境搭建，依賴服務(wù)的配置梳理，本地環(huán)境配置調(diào)整等。如果是在云上的應(yīng)用可能還需要手動調(diào)整安全組規(guī)則，依賴服務(wù)的訪問控制等；但這些需要手動執(zhí)行的動作在自動彈性時都會變得不可行。

2、進程本身無狀態(tài)

確切的說，無狀態(tài)主要是指業(yè)務(wù)系統(tǒng)運行時對于數(shù)據(jù)的依賴程度，數(shù)據(jù)是在進程執(zhí)行的過程中產(chǎn)生的，產(chǎn)生的數(shù)據(jù)會對后來的程序行為產(chǎn)生持續(xù)的影響，程序員需要在編碼邏輯的時候，就考慮如果系統(tǒng)在一個新環(huán)境中重新拉起時，這份數(shù)據(jù) 是否對于行為會造成不一致的情況？ 推薦做法是數(shù)據(jù)應(yīng)該最終以存儲系統(tǒng)中為準，讓存儲計算做到真正的分離。

3、啟動的要快，走的要有“尊嚴”

彈性 ， 尤其是云上的彈性，其中一個特點是會進行得很頻繁。 尤其是流量突發(fā)型的業(yè)務(wù)，帶著一定的不確定性。 而啟動后的系統(tǒng)往往處在一個“冷”的狀態(tài)，啟動之后如何快速的“加熱”是彈性有效性的關(guān)鍵。 而在彈性結(jié)束之后，往往伴隨著一次自動的縮容，由于這個過程也是自動的，所以我們需要能從技術(shù)上能做到自動流量摘除的能力，這里的流量不僅僅包括 HTTP/RPC，也包括消息、任務(wù)（后臺線程池）調(diào)度等。

4、磁盤數(shù)據(jù)可丟失

在應(yīng)用啟動過程，我們的應(yīng)用程序可能會使用磁盤配置一些啟動依賴項之外；在進程運行的過程中，我們也會習慣性使用磁盤打印一些日志，或者記錄一些數(shù)據(jù)。而彈性場景是進程快起快沒，沒了之后放在磁盤上的數(shù)據(jù)也都沒了，所以我們要做好磁盤數(shù)據(jù)丟失的準備，可能有人會問日志怎么處理？日志應(yīng)該通過日志收集組件收走，進行統(tǒng)一的聚合、清洗和查閱。這一點在 12 factor apps 中也做了強調(diào)。

5、依賴的服務(wù)充分可用

成規(guī)模的業(yè)務(wù)系統(tǒng)，往往不是一個人在戰(zhàn)斗。 最典型的架構(gòu)中，也會使用到一些緩存、數(shù)據(jù)庫等中心服務(wù)。 一個業(yè)務(wù)彈性擴容上來之后，很容易忽略中心依賴服務(wù)的可用性。 如果依賴服務(wù)出現(xiàn)不可用，對于整個系統(tǒng)可能就是一個雪崩的效應(yīng)。

六個教訓

1、指標值設(shè)置不合理

彈性整體分為三個階段： 指標獲取、規(guī)則計算、執(zhí)行伸縮； 指標獲取一般通過監(jiān)控系統(tǒng)或者 PaaS 平臺自帶的組件獲取。 基礎(chǔ)監(jiān)控指標常見的如： CPU/Mem/Load 等。 短期內(nèi)有一些基礎(chǔ)指標數(shù)值會存在不穩(wěn)定的特點，但是時間拉長，正常來看會處在一個“平穩(wěn)”的狀態(tài)，我們設(shè)置指標的時候，不能以短時間的特征為依據(jù)，參考較長時間的某種水位數(shù)據(jù)才能設(shè)置一個合理值。 且指標不宜過多，同時縮容指標要和擴容指標存在明顯的數(shù)值差。

2、把“延時”當指標

很多時 候我們識別系統(tǒng)可用性的一個很大的判斷，就是看系統(tǒng)屏幕是不是在“轉(zhuǎn)圈圈”，即系統(tǒng)很慢。 常理推斷，很慢就要擴容了。 所以我們有一些客戶直接把系統(tǒng)的平均 RT 當成了擴容指標，但系統(tǒng)的 RT 是多維度的，比如 health check 一般都是很快的，這類 API 出現(xiàn)的頻率稍高一點，一下就拉低了平均值。 也有的客戶會精確到 API 級別，可是 API 也是根據(jù)參數(shù)不同邏輯不一樣的從而造成 RT 不一樣。 總之，根據(jù)延時去做彈性策略是很危險的一種做法。

3、指定單一的擴容規(guī)格

擴 容規(guī)格指 的是資源的規(guī)格，比如在云上的場景中，對于同一種 4c8g 的規(guī)格，我們可以指定內(nèi)存型、計算型、網(wǎng)絡(luò)增強型等。 但是云上是一個大資源池，對于某一種規(guī)格，會存在售罄現(xiàn)象；如果我們只指定了單一的規(guī)格，就會出現(xiàn)資源無法提供而出現(xiàn)擴容失敗的情況。 這里最危險的還不是擴容失敗本身，是出現(xiàn)業(yè)務(wù)故障之后的排查過程會特別漫長。

4、只考慮RPC鏈路中的應(yīng)用策略

針對單 個應(yīng)用往往都很簡單的，難的是整個業(yè)務(wù)場景的梳理。 梳理思路一個簡單的辦法就是按照應(yīng)用調(diào)用的場景進行，從應(yīng)用間調(diào)用的場景來看，一般來說分為三種： 同步（RPC，中間件如  Spring Cloud）、異步（消息，中間件如  RocketMQ）、任務(wù)（分布式調(diào)度，中間件如  SchedulerX）。 我們一般會很快整理出第一種情況，但是很容易忽略掉后面兩種。 而后面兩種出現(xiàn)問題的時候，問題排查診斷又是最為耗時。

5、沒有配套相應(yīng)的可視化策略

彈性伸縮是一個典型的后臺任務(wù)，在治理一個大集群的后臺任務(wù)的時候，最好是有一塊大屏進行直觀的可視化治理。 對于擴容失敗的情形，不能靜默處理。 如果是核心業(yè)務(wù)出現(xiàn)擴容失敗，可能帶來的就是直接的業(yè)務(wù)故障，但是故障真正發(fā)生時，很多時候不會去關(guān)心擴容策略是否生效，如果真是因為擴容造成的故障，也很難排查到這個點。

6、事前沒做正確評估

雖然 云計算給彈性提供了近乎無盡的資源池，但這也只是解放了用戶預(yù)備資源的工作，而微服務(wù)系統(tǒng)本身復雜，單一組件的容量變化會產(chǎn)生全鏈路的影響，既解除一處風險之后系統(tǒng)瓶頸點可能會遷移，有些隱形約束也會隨著容量變化逐步顯現(xiàn)，所以做彈性策略大多數(shù)時候不能靠力大磚飛的思想，需要做好全鏈路的壓測、驗證，演練到適應(yīng)于全局的彈性配置； 我們還是建議事前從高可用的多個維度了解各種技術(shù)手段，形成多套預(yù)案以備使用。

尾聲

云原生場景下彈性能力更為豐富，可供彈性的指標也更具備業(yè)務(wù)定制能力。應(yīng)用 PaaS 平臺（如企業(yè)級分布式應(yīng)用服務(wù) EDAS/ Serverless 應(yīng)用引擎 SAE 等）能結(jié)合云廠商在計算、存儲、網(wǎng)絡(luò)上的技術(shù)基礎(chǔ)能力，能讓使用云的成本更低。但是這里對于業(yè)務(wù)應(yīng)用會提出一點點挑戰(zhàn)（如：無狀態(tài)/配置代碼解耦等等）。從更廣的側(cè)面來看，這是云原生時代應(yīng)用架構(gòu)面臨的挑戰(zhàn)。不過應(yīng)用越來越原生的話，云的技術(shù)紅利也會離我們越來越近。