云原生：一個(gè)從買房到開房的故事

作者：李宗標(biāo) 2021-07-12 05:01:11

云計(jì)算云原生

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

[[410627]]

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

云原生

一個(gè)從買房到開房的故事

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

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

一、云原生第一個(gè)根問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表1 彈性效率

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

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

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

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

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

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

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

二、云原生的第二個(gè)根問題

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

需要說明的是，HA 分為計(jì)算的 HA 和存儲(chǔ)的 HA，如圖3所示。

圖3 HA 的分類

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

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

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

躺贏

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

圖4 存儲(chǔ)類的 HA 躺贏方案示意

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

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

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

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

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

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

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

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

三、云原生的極致追求

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

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

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

Serverless = BaaS + FaaS

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

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

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

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

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

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

我們都有光明的未來!

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

四、從買房到開房的故事

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

圖5 從買房到開房的故事

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

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

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

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

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