[[410627]]

本文轉(zhuǎn)載自微信公眾號「網(wǎng)事如煙云」，作者李宗標(biāo) 。轉(zhuǎn)載本文請聯(lián)系網(wǎng)事如煙云公眾號。

云原生

一個從買房到開房的故事

云原生(Cloud Native)這個詞火了有不少一段時間了，但是關(guān)于是什么是云原生，仍然是眾說紛壇，莫衷一是。

問題問對了，答案就找到一半。讓我們暫時忘記云原生，“穿越”回古老的面向服務(wù)器編程的時代——在那個時代里，最讓人無奈的軟件架構(gòu)特性是什么?

一、云原生第一個根問題

當(dāng)然，對于這個問題(最讓人無奈的軟件架構(gòu)特性是什么)，不同的人也有不同的答案，但是有一個答案，相信能得到絕大多數(shù)人的贊同，那就是：計算的高效彈性伸縮(彈性計算)。

假設(shè)一個系統(tǒng)，當(dāng)前需要的配置是10臺服務(wù)器，半小時候后，需要15臺服務(wù)器，該怎么辦?

該怎么辦?去打報告申請采購-》采購服務(wù)器-》安裝部署-》上線，這中間哪一步是半小時能夠搞定的?面對這樣的場景，除了躺平，恐怕別無他法。

而比這個場景更讓人崩潰的是，這一番好容易折騰好以后，時光又匆匆流逝了半個月，老板說：我們現(xiàn)在10臺服務(wù)器也夠用了，把剛買的那5臺服務(wù)器給退了吧。

就算“厚顏無恥”地薅京東的羊毛，人家京東也只是規(guī)定可以7天無理由退貨，現(xiàn)在已經(jīng)過去了半個月，又找誰去耍流氓呢?

可以看到，在服務(wù)器時代，計算的高效彈性伸縮，是一個無解的命題，直到云計算的出現(xiàn)。

我的意中人是個蓋世英雄，我知道有一天，他會在一個萬眾矚目的情況下出現(xiàn)，身披金甲圣衣，腳踏七彩祥云來娶我!

——紫霞仙子《大話西游》

云計算，首先是個計算資源池，其次從哲學(xué)上來講，它是問題的轉(zhuǎn)移和轉(zhuǎn)換。

對于云廠商來說，如果它現(xiàn)在有1萬臺服務(wù)器，想擴容到2萬臺，一樣會面臨那一系列的問題：申請采購-》采購-》安裝部署-》上線，一樣會面臨冗長的時間流程。從這一點來說，計算的彈性伸縮問題，并沒有解決，只是從普通用戶轉(zhuǎn)移到了云廠商。

如果僅僅是這樣，云計算恐怕就不會有真正的商用。量變引起質(zhì)變，這世上本沒有路，走的人多了，也便成了路。隨著云計算的用戶增多，不同的用戶之間，會達(dá)到一種“微妙”的動態(tài)平衡：有的人期望增加算力(比如上述場景的增加服務(wù)器)，同時也會有人期望減少算力，這一增一減之間，就是這么微妙地達(dá)到動態(tài)平衡——對于云廠商來說，它可以在現(xiàn)有資源不變的情況下，閃轉(zhuǎn)騰挪，滿足每個用戶的彈性伸縮的需求。(當(dāng)然，如果總資源不夠了，云廠商還是需要購買服務(wù)器去擴容，這是另外一個問題了)

可以看到，從某種意義上講，云計算的本質(zhì)是一個“共享經(jīng)濟(jì)”模式。正是這種“共享”，使得普羅大眾的彈性伸縮的需求，得到了很好的滿足。

“共享經(jīng)濟(jì)”模式這個大基調(diào)確定以后，剩下的就是云計算本身的技術(shù)發(fā)展了。從虛擬機(VM，Virtual Machine)到容器(Container)，而容器的解決方案和生態(tài)，目前來看，乃是 docker/k8s 勝出。

云計算為什么會有這樣的發(fā)展路線呢?這又要從原始的問題入手，如圖1所示。

圖1 從服務(wù)器到 docker/k8s

通過圖1可以看到，從服務(wù)器演進(jìn)到云計算，這幾乎是一種必然，如表1所示。

表1 彈性效率

	服務(wù)器模式	虛機模式	容器模式
彈性擴容效率	日~年	分鐘級	秒級
彈性縮容效率	不具備	分鐘級	秒級

而云計算技術(shù)，從虛機一直發(fā)展到 docker/k8s，其背后的需求邏輯是：彈性效率，部署效率，彈性自動化(以及其他層面的自動化)，如圖2所示。

圖2 彈性需求的馬斯洛模型

通過圖2可以看到，隨著彈性需求的馬斯洛模型的逐步展開，云計算的技術(shù)也是逐步發(fā)展，而 docker/k8s 則在這個發(fā)展的過程中，成為天選之子，最起碼到目前為止，它們是絕代雙驕、珠聯(lián)璧合、俾倪天下。

至于 docker/k8s 為什么會在這場技術(shù)大戰(zhàn)中勝出，以及它們的技術(shù)細(xì)節(jié)又是什么，本文由于主題和篇幅的原因，就不再詳述。我們只須知道，docker/k8s 從根子上是為了滿足人們的彈性計算的需求，然后在彈性需求的馬斯洛模型上勝出即可。

那么，問題來了，docker/k8s 是不是就可以稱為云原生呢?有的人，有的企業(yè)，確實是這么宣稱的，但是還有另一部分人和企業(yè)，表示堅決反對。說句不客氣的話，無論是支持此觀點的還是反對此觀點的，很多時候都不是處于技術(shù)層面考慮，而是處于自身的商業(yè)利益考慮。

亂花漸欲迷人眼，一說到商業(yè)利益，這個事情就說不清楚了。我們還是需要從原始的問題出發(fā)，去尋找云原生的本質(zhì)。

二、云原生的第二個根問題

除了彈性計算，還有什么架構(gòu)特性是讓人最頭疼的呢?幸福的人生千篇一律，不幸的人生各有悲苦。第二讓人頭疼的架構(gòu)特性，其答案也是紛呈各異，但是如果說是 HA(High Availability，高可用性)，應(yīng)該也能得到很多的贊同。

需要說明的是，HA 分為計算的 HA 和存儲的 HA，如圖3所示。

圖3 HA 的分類

基于不同的原則，HA 有不同的分類，比如 Active/Active、Active/Standby(圖3表達(dá)的是就是此種模式)，又比如本地 HA、異地 HA 等等。而按照部件來分類，HA 分為計算 HA 和存儲 HA。

對于計算 HA 來說，docker/k8s 已經(jīng)能夠很好地解決(前提是計算部件要做服務(wù)化/無狀態(tài)改造)，但是，對于存儲 HA 來說，非常不幸，目前沒有非常簡單有效的專有方案。

既然沒有，那么對于存儲類 HA，是不是就該躺平呢?不，云廠商推薦的解決方案是

躺贏

既然沒有簡單有效的方案，云廠商的意思是：你就不用煩心這個問題了，給錢，我來幫你解決，如圖4所示。

圖4 存儲類的 HA 躺贏方案示意

存儲當(dāng)然不僅僅意味著關(guān)系數(shù)據(jù)庫，圖4僅僅是個示意。假設(shè)一個 App 需要操作關(guān)系數(shù)據(jù)庫，關(guān)系數(shù)據(jù)庫里面的數(shù)據(jù)(也就是存儲類)所需要的 HA，對于開發(fā)者來說，就不必關(guān)心，他只需調(diào)用云廠商的關(guān)系數(shù)據(jù)庫服務(wù)(比如華為云的 GaussDB)，那么這背后的數(shù)據(jù)的 HA(包括數(shù)據(jù)庫計算部分的 HA)，都由云廠商來解決，而開發(fā)者只需要做一件事情：說服自己的老板，花錢買云廠商的云數(shù)據(jù)庫。

如果不是關(guān)系數(shù)據(jù)庫，而是其他類型的數(shù)據(jù)庫，或者說與數(shù)據(jù)庫無關(guān)，僅僅是存儲，云廠商都有對應(yīng)的服務(wù)，只要你愿意花錢。

需要補充一點，拋開單純的存儲服務(wù)，當(dāng)前云廠商并不能保證它所提供的相應(yīng)服務(wù)能夠百分百保證所有用戶的需求，這個需要具體問題具體分析。不過總體上是這個思路：

花錢購買云服務(wù)，同時解決 HA 問題!

用戶花錢購買的云服務(wù)，云原生賦予其一個高大上的名字：BaaS(Backend as a Service, 后端即服務(wù))。BaaS 在不同的場景，也有不同的定義，我們不必糾結(jié)。這里不妨理解為云廠商的一個話術(shù)：

設(shè)想一下，作為一個架構(gòu)師，你的解決方案竟然是花錢，你還怎么在老板那里混?這時候，云廠商就要送你一朵小紅花——你這不是花錢，你這是 BaaS!

是不是一下子就很高大上?是不是一下子就很有逼格?花老板的錢，讓老板無話可說!

不過，BaaS 還不是最有逼格的。最有逼格的是 Serverless (無服務(wù)器)方案?？陀^地說，Serverless 是云原生的屬性之一，但是它不是根本，最起碼目前來說，它有那么一點混淆視聽。

三、云原生的極致追求

Serverless，并不是真的沒有服務(wù)器。我們的軟件，部署在云上，而云歸根結(jié)底是由服務(wù)器承載的。如果真的沒有服務(wù)器，那云就不叫云了，那叫空氣!

Serverless 指的是對于開發(fā)者而言，他不需要感知服務(wù)器的存在，一切都交給云。

Serverless 的定義，可以參見一個普遍認(rèn)可的公式：

Serverless = BaaS + FaaS

BaaS，前文介紹過，它當(dāng)然不需要用戶感知服務(wù)器的存在。FaaS(Functions as a Service，函數(shù)即服務(wù))這個話題，本文由于篇幅和主題的原因，也無法展開?？傊?，我們暫時只需要認(rèn)知兩點：

(1)比服務(wù)化的代碼，更加“簡化”;一切的執(zhí)行、彈性都交給云(而且彈性效率是毫秒級的)

(2)但是，它的適用場景是有限的，并不是一個普適的解決方案

客觀地說，Serverless 確實是云原生的一個極致追求，但是正因為 FaaS 并不能稱為一個普適的解決方案，筆者并不贊同把 Serverless 理解為云原生的本質(zhì)(之一)，否則會對云原生的概念產(chǎn)生混淆。

其實，“混淆”云原生概念的，又何止一個 Serverless。眾多公有云廠商，他們有意無意地——不，它們就是有意的——在無限擴大云原生的范圍。嘴里說的都是主義(云原生)，心里想的都是生意!在商言商，這么做，可能也沒有什么錯。

張華在軟件公司當(dāng)碼農(nóng)，花錢買了云服務(wù);李萍在云廠商當(dāng)網(wǎng)工，運維云服務(wù);王總是軟件公司老板，說自己的架構(gòu)是云原生。

我們都有光明的未來!

那么，這些云廠商到底是如何無限擴大云原生的概念呢?這就是一個從買房到開房的故事。

四、從買房到開房的故事

我們回憶一下軟件開發(fā)模式的演進(jìn)，如圖5所示。

圖5 從買房到開房的故事

把服務(wù)器模式類比為買房模式，這比較好理解。云計算模式，其虛擬化技術(shù)包括虛機、容器——這里的容器，指的是單純的容器技術(shù)。在云計算模式下，雖然房子(計算/存儲等資源)不用買了，可以租，但是房子內(nèi)部的其他基本服務(wù)(彈性、HA)，還需要自己搞定(云計算模式也試圖搞定這些基本服務(wù)，但是沒做好)。而云原生模式下，房子內(nèi)部的基本服務(wù)，也無須用戶操心——只管花錢開房，剩下的交給酒店就行了。

人生在世，既有吃喝拉撒睡，還有吃喝嫖賭抽。如果只是一家普通的酒店，那專心致志做好睡的服務(wù)即可(當(dāng)然，還包括拉撒服務(wù))。但是，如果開房的人多了呢，多到足以支撐起其他產(chǎn)業(yè)呢?又或者是期望通過其他產(chǎn)業(yè)吸引更多的人來開房呢?這個時候，我們就分不清這個酒店的主營到底是什么了?是睡服務(wù)、賭服務(wù)，還是莞式服務(wù)?

就像各大廠商所宣稱的云原生，應(yīng)有盡有，無所不能!比如某廠就從服務(wù)的生命周期入手，宣稱各個階段都存在云原生的概念(只要你購買它的服務(wù))，如圖6所示。

圖6 某廠宣稱的云原生階段

其實，圖6雖然涵蓋了各個階段，它還只是涉及了“可信”這一點。但是，就是這一點，也讓人無法反駁。如果是運行期的產(chǎn)品族，它把 AI 等各種服務(wù)都塞進(jìn)去，都說是 BaaS，都說是云原生，也仍然讓人無法反駁，比如圖7所示的阿里云的云原生產(chǎn)品家族。

圖7 阿里云的云原生產(chǎn)品家族

這有問題嗎?這沒有問題!問題是，我們該如何尋找云原生的本質(zhì)!

五、云原生的本質(zhì)

寫到這里，筆者有點不敢下筆了。前面怎么扯犢子都行，現(xiàn)在忽然聊這么嚴(yán)肅而深刻的話題，筆者深感水平有限、力不從心。不過，既然已經(jīng)寫到這里了，就斗膽寫下去吧，班門弄斧，貽笑大方。

有時候?qū)ふ乙粋€解決方案的本質(zhì)(云原生是一種解決方案)，需要從它所解決的本質(zhì)問題入手。

筆者以為，云原生所要解決的本質(zhì)問題就是：

彈性計算 + HA

而其它問題，是兩個本質(zhì)問題的解決路徑上所遇到的問題(隨路問題)——既然遇到了，如果能“捎帶腳”解決，那就順便解決。從完整性角度來說，這擴展了云原生解決方案的范圍，但是這絕不是云原生的本質(zhì)。

比如“服務(wù)發(fā)現(xiàn)”問題，服務(wù)既然要彈性，總得讓請求能正確抵達(dá)服務(wù)實例。那如何抵達(dá)呢?當(dāng)然得先有服務(wù)發(fā)現(xiàn)。

再比如，安全、韌性等等問題，都是云原生本質(zhì)路徑上所遇到的問題，既來之、則安之，云原生都可以一并幫其解決了。但是，我們要深刻地認(rèn)識到，這些都是云原生的次生問題，不是云原生的本質(zhì)問題。

綜上所述，筆者以為，云原生的所要解決的問題，也符合馬斯洛模型，如圖8所示。

圖8 云原生所解決的問題的馬斯洛模型

羅曼羅蘭說，世界上只有一種真正的英雄主義，那就是看清生活的真相之后，依然熱愛生活。

認(rèn)清了云原生的本質(zhì)問題和隨路問題以后，我們并不拒絕云原生為隨路問題所付出的努力。它把那些隨路問題解決了，當(dāng)然是更好，我們沒有必要為了糾結(jié)一個純粹的概念，而拒絕整個春天。

當(dāng)然，問題的解決是雙向的，云原生也是雙向的，它不僅僅指的是云廠商的努力，也包括了軟件開發(fā)商的努力。關(guān)于這一點，阿里云的總結(jié)就比較好，筆者這里直接引用，如圖9所示。

圖9 阿里云的云原生架構(gòu)成熟度模型

圖9中的 ACNA 是 Alibaba Cloud Native Architecting 的縮寫。筆者之所以直接引用這張圖，是因為它：

(1)非常好地涵蓋了云原生的本質(zhì)問題和隨路問題，以及解決這些問題的目標(biāo)

(2)暗含了云廠商與軟件開發(fā)商的共同努力

當(dāng)然，隨路問題是無限的。隨著技術(shù)的發(fā)展，隨著云廠商的發(fā)展，我們會看到云原生的范圍越來越廣，我們甚至?xí)吹?，云原生的本質(zhì)問題，也會擴展。不過，這些都是后話了。

就當(dāng)前的技術(shù)棧而言，你要問筆者云原生最核心、最本質(zhì)是什么，筆者的答案是：

docker/k8s + BaaS

將來，docker/k8s 這個技術(shù)棧也許會被替換，而 BaaS 的外延也會無限擴展，只要“錢能買到錢”——能夠提升開發(fā)效率，降低開發(fā)成本，一切都可以是云原生。

所以，云原生就是 CaaS：Cost as a Service。