云計(jì)算通過資源池化實(shí)現(xiàn)單位資源成本更優(yōu)，使企業(yè)能夠?qū)DC建設(shè)、基礎(chǔ)軟件研發(fā)和運(yùn)維等工作外包給云廠商，從而更專注于業(yè)務(wù)創(chuàng)新。資源池不僅包括服務(wù)器，還包括人才。云廠商集聚了優(yōu)秀工程師，通過云服務(wù)為眾多企業(yè)提供專業(yè)服務(wù)，讓專業(yè)的事交給最專業(yè)的人。

云計(jì)算發(fā)展這么多年，彈性是云計(jì)算從業(yè)者最關(guān)注的技術(shù)能力之一，但是真正落實(shí)到具體的案例上，很少有客戶能把彈性用好，彈性反而成為了一種口號(hào)，一種理想的架構(gòu)，本文嘗試討論為什么現(xiàn)實(shí)和理想差距這么大，以及有哪些低投入高回報(bào)的彈性方案。

云廠商通過包年包月打折來留住客戶，與彈性場(chǎng)景相悖

下表是一份典型的包年包月EC2價(jià)格與按量付費(fèi)價(jià)格對(duì)比，總結(jié)出來的游戲規(guī)則：

包年包月相比按量付費(fèi)大約有50%的成本節(jié)省這也是為什么大多數(shù)企業(yè)選擇包年包月方式來使用EC2資源。從云廠商的角度這么設(shè)計(jì)非常合理，因?yàn)樵茝S商是通過預(yù)測(cè)全網(wǎng)客戶的使用量來確定一個(gè)Region要預(yù)留多少空閑水位，假設(shè)On Demand和Reserved實(shí)例價(jià)格一致，將導(dǎo)致云廠商難以預(yù)測(cè)一個(gè)Region的水位，甚至?xí)霈F(xiàn)白天和晚上有巨大的差異，會(huì)直接影響供應(yīng)鏈的采購(gòu)決策。云廠商是典型的類零售商業(yè)模式，每個(gè)Region的空閑機(jī)器數(shù)量類比為庫(kù)存，庫(kù)存比例越高，會(huì)導(dǎo)致利潤(rùn)率越低。

Spot實(shí)例恰好做到既便宜又是按小時(shí)付費(fèi)這也要求應(yīng)用能處理好Spot實(shí)例被強(qiáng)制回收帶來的影響，對(duì)于無(wú)狀態(tài)應(yīng)用相對(duì)簡(jiǎn)單，Spot實(shí)例在回收之前會(huì)通知應(yīng)用，大部分云廠商會(huì)給到分鐘級(jí)別的回收窗口，應(yīng)用只要做到優(yōu)雅下線，就能做到對(duì)業(yè)務(wù)無(wú)影響。海外專業(yè)基于Spot實(shí)例來管理計(jì)算資源的創(chuàng)業(yè)公司，有大量的產(chǎn)品化功能幫助用戶用好Spot實(shí)例。AutoMQ公司也積累了豐富的Spot實(shí)例使用經(jīng)驗(yàn)。但是對(duì)于有狀態(tài)應(yīng)用，Spot實(shí)例使用起來的門檻變得非常高，實(shí)例被強(qiáng)制回收前，就需要做到將狀態(tài)轉(zhuǎn)移。比如Kafka，Redis，MySQL這類應(yīng)用。針對(duì)這類數(shù)據(jù)型的基礎(chǔ)軟件通常不建議用戶直接部署到Spot實(shí)例上。

這個(gè)游戲規(guī)則既有合理的地方也有值得優(yōu)化的地方，筆者認(rèn)為至少還可以在以下方面做的更好：

Spot回收機(jī)制提供SLA要能鼓勵(lì)更多用戶使用Spot實(shí)例，那么Spot的回收機(jī)制中的消息通知要能提供確定的 SLA，這樣一些關(guān)鍵業(yè)務(wù)就能敢于大規(guī)模使用Spot實(shí)例。

創(chuàng)建新實(shí)例 API 提供 SLASpot 被回收后，應(yīng)用的兜底方案是繼續(xù)開通新的資源（如新的Spot實(shí)例，或新的 On-demand 實(shí)例），這時(shí)開通新實(shí)例的 API 也要能有確定的 SLA，這個(gè) SLA 會(huì)直接影響到應(yīng)用的可用性。

卸載云盤提供 SLADetach EBS 也要能有確定的 SLA，因?yàn)橐坏┌l(fā)生強(qiáng)制回收Spot實(shí)例，要能允許用戶自動(dòng)化處理好應(yīng)用狀態(tài)卸載。

程序員很難做好資源回收這件事情

C/C++ 程序員大量的精力在和內(nèi)存作斗爭(zhēng)，但是仍然不能保證內(nèi)存資源不泄露。原因是資源準(zhǔn)確回收是一件極具挑戰(zhàn)的事情，比如一個(gè)函數(shù)返回一個(gè)指針，那么這個(gè)對(duì)象是誰(shuí)負(fù)責(zé)回收，C/C++ 是沒有約定的，如果再涉及到多線程，則更加噩夢(mèng)。為此 C++ 發(fā)明了智能指針，通過一個(gè)線程安全的引用計(jì)數(shù)來管理對(duì)象。Java 通過內(nèi)置的 GC 機(jī)制，通過運(yùn)行時(shí)來檢測(cè)對(duì)象回收，徹底解決了對(duì)象回收問題，不過也帶來了一定的運(yùn)行時(shí)開銷。最近特別火的 Rust 語(yǔ)言，本質(zhì)上也是類 C++ 的智能指針回收方式，創(chuàng)新性的將內(nèi)存回收檢查機(jī)制做到了編譯階段，從而大幅提升了內(nèi)存回收的效率，避免了 C/C++ 程序員常犯的內(nèi)存問題，筆者認(rèn)為 Rust 將是 C/C++ 的一個(gè)完美替代。

回到云操作系統(tǒng)這個(gè)領(lǐng)域，程序員可以通過一個(gè) API 就能創(chuàng)建一臺(tái) ECS，一個(gè) Kafka 實(shí)例，一個(gè) S3 Object，這個(gè) API 背后帶來的是賬單的變化。創(chuàng)建容易，回收則變得非常困難。創(chuàng)建時(shí)候通常會(huì)指定最大規(guī)格，比如創(chuàng)建一個(gè) Kafka 實(shí)例，先來 20 臺(tái)機(jī)器，因?yàn)槲磥頂U(kuò)容縮容都很困難，不如一次到位。

雖然云計(jì)算提供了彈性，但程序員難以有效地按需管理資源，導(dǎo)致資源回收困難。這促使企業(yè)在云上資源創(chuàng)建時(shí)設(shè)立繁瑣的審批流程，類似于傳統(tǒng) IDC 的資源管理方式。最終導(dǎo)致的結(jié)果即程序員在云上使用資源的方式與 IDC 趨同，即需要通過 CMDB 進(jìn)行資源管理，并依賴人工審批流程來避免資源浪費(fèi)。

我們也看到了一些優(yōu)秀的彈性實(shí)踐案例。例如某大型企業(yè)在使用 EC2 時(shí)，每個(gè) EC2 的 Instance ID 存活周期不超過 1 個(gè)月，一旦超過， 就會(huì)被列為“爺爺輩的 EC2”，要上團(tuán)隊(duì)的黑榜單。這是一個(gè)非常棒的不可變基礎(chǔ)設(shè)施實(shí)踐方法，能有效避免工程師在服務(wù)器上保留狀態(tài)，如配置，數(shù)據(jù)等，從而讓應(yīng)用走向彈性架構(gòu)變得可行。

當(dāng)前云計(jì)算的階段還處在 C/C++ 階段，還沒有出現(xiàn)優(yōu)秀的資源回收解決方案，所以企業(yè)還在大量使用流程審批機(jī)制，實(shí)質(zhì)上導(dǎo)致了企業(yè)無(wú)法發(fā)揮云的最大優(yōu)勢(shì)：彈性。這也是導(dǎo)致企業(yè)云支出較高的主要原因之一。

相信只要有問題，一定會(huì)有更優(yōu)秀的解法，解決云資源回收的類 Java/Rust 方案一定會(huì)在不久的將來問世。

從基礎(chǔ)軟件到應(yīng)用層，還沒有為彈性做好準(zhǔn)備

筆者曾在 2018 年開始為淘寶天貓的數(shù)千個(gè)應(yīng)用設(shè)計(jì)彈性方案，當(dāng)時(shí)淘寶天貓的應(yīng)用已經(jīng)做到了離線和在線混部來提升部署密度，但是在線應(yīng)用仍然為預(yù)留模式，無(wú)法做到按需彈性。根本問題還是應(yīng)用在擴(kuò)縮時(shí)，可能會(huì)產(chǎn)生非預(yù)期的行為，即使運(yùn)行在 Kubernetes 之上，仍然不能徹底解決，如應(yīng)用會(huì)調(diào)用各種中間件的 SDK（數(shù)據(jù)庫(kù)、緩存、MQ、業(yè)務(wù)緩存等），應(yīng)用本身啟動(dòng)也消耗時(shí)間較長(zhǎng)，看似無(wú)狀態(tài)的應(yīng)用，實(shí)則也包含了各種狀態(tài)，如包括單元標(biāo)簽，灰度標(biāo)簽等，讓整個(gè)應(yīng)用需要大量的人工操作，人工觀察才能有效擴(kuò)縮容。

為了讓 Java 應(yīng)用從分鐘級(jí)的冷啟動(dòng)提升到毫秒級(jí)，當(dāng)時(shí)為 Docker 開發(fā)了 Snapshot 能力，這項(xiàng)能力的生產(chǎn)應(yīng)用足足比 AWS 領(lǐng)先了 4 年（AWS 于 2022 年 Re:invent 會(huì)議上發(fā)布了 Lambda SnapStart 特性）。通過 Snapshot 方式啟動(dòng)應(yīng)用可以數(shù)百毫秒就能增加一臺(tái)可以立刻工作的計(jì)算節(jié)點(diǎn)，這項(xiàng)能力讓應(yīng)用不需要改造成 Lambda 函數(shù)方式就能做到像 Lambda 一樣，根據(jù)流量來增減計(jì)算資源，也就是我們看到的 Lambda 提供的 Pay as you go 能力。

應(yīng)用層做彈性已經(jīng)如此復(fù)雜，到了基礎(chǔ)軟件做彈性挑戰(zhàn)更大，如數(shù)據(jù)庫(kù)、緩存、MQ、大數(shù)據(jù)等產(chǎn)品。分布式高可用高可靠的要求決定了這些產(chǎn)品都需要將數(shù)據(jù)存儲(chǔ)多副本。一旦數(shù)據(jù)量大，彈性將變得非常困難，遷移數(shù)據(jù)會(huì)影響業(yè)務(wù)的可用性。為此，要在云環(huán)境解決這個(gè)問題，就要用云原生的方式，我們?cè)谠O(shè)計(jì) AutoMQ（賦能 Kafka 的云原生方案）時(shí)，將彈性作為最高優(yōu)先級(jí)，核心挑戰(zhàn)是要將存儲(chǔ)卸載到云服務(wù)，例如按量付費(fèi)的 S3，而不是自建存儲(chǔ)系統(tǒng)。下圖是 AutoMQ 線上的流量和節(jié)點(diǎn)變化圖，會(huì)看到 AutoMQ 是根據(jù)流量全自動(dòng)增減機(jī)器，如果這些機(jī)器采用Spot實(shí)例，將為企業(yè)節(jié)省大量的成本，真正做到 Pay as you go。

AutoMQ 根據(jù)流量自動(dòng)增減節(jié)點(diǎn)

企業(yè)如何使用好彈性能力來降本增效

Google 在 2018 年推出了 Cloud Run 全托管式計(jì)算平臺(tái)，基于 HTTP 通信的應(yīng)用僅需提供監(jiān)聽端口和容器鏡像給 Cloud run，所有基礎(chǔ)設(shè)施的管理將全自動(dòng)由 Cloud run 來執(zhí)行。這種方式相比 AWS Lambda 方式最大優(yōu)勢(shì)是無(wú)需綁定到單個(gè)云廠商，未來可以更好的遷移到其他計(jì)算平臺(tái)。很快 AWS 和 Azure 跟進(jìn)推出了類似的產(chǎn)品，Azure Container Apps 和 AWS App Runner。

專業(yè)的事情交給專業(yè)的人做，彈性是一個(gè)非常有挑戰(zhàn)的工作，推薦云上的應(yīng)用可以盡可能依賴這些無(wú)代碼綁定托管框架，如 Cloud run，做到應(yīng)用消耗的計(jì)算資源可以按照請(qǐng)求來付費(fèi)。

基礎(chǔ)軟件如數(shù)據(jù)庫(kù)、緩存、大數(shù)據(jù)、MQ 等，很難用一個(gè)統(tǒng)一的托管框架來解決，這類應(yīng)用的演進(jìn)趨勢(shì)是每個(gè)品類都在向彈性架構(gòu)演進(jìn)，如 Amazon Aurora Serverless，Mongodb Serverless，從云廠商到第三方開源軟件商都有共識(shí)要能走到徹底的彈性架構(gòu)。

企業(yè)在選擇類似開源基礎(chǔ)軟件時(shí)，要盡可能選擇具備彈性能力的產(chǎn)品，判斷的標(biāo)準(zhǔn)是是否能運(yùn)行在Spot實(shí)例上，是否能極具性價(jià)比。同時(shí)也要關(guān)注這類產(chǎn)品是否能更好的在多個(gè)云上運(yùn)行，這決定了企業(yè)在未來走向多云架構(gòu)，甚至混合云架構(gòu)時(shí)，是否具備移植性。