自從成功躲過(guò)“大數(shù)據(jù)”、“數(shù)據(jù)孤島”等概念坑后，女朋友仿佛并沒(méi)有真正的臣服，甚至有些變本加厲!這次竟然用“云原生”刁難我，并冠以“搞不懂它，承包一個(gè)月的家務(wù)”、“必要時(shí)頭懸梁錐刺股”、“或者背誦《般若波羅蜜多心經(jīng)》”等苛刻條件。

太過(guò)分了!“觀自在菩薩，行深般若波羅蜜多時(shí)，照見(jiàn)五蘊(yùn)皆空，度一切苦厄......”磕磕絆絆讀過(guò)《心經(jīng)》之后，我還是乖乖地選擇了女朋友挖的坑——讓女朋友徹底理解云原生。畢竟，逃避解決不了任何問(wèn)題，反而會(huì)制造更多焦慮。

于是，我開(kāi)始苦思冥想、懸梁刺股，開(kāi)始研究“怎么才能把云原生說(shuō)的更直白、更透徹”。白駒過(guò)隙、斗轉(zhuǎn)星移，這一天我真正掌握了內(nèi)功心法，進(jìn)行了一場(chǎng)家庭版脫口秀——《白話云原生》。

故事是從這里開(kāi)始的。2013年Cloud Native之父MattStine，拍了拍腦門，把在Pivotal的架構(gòu)、咨詢經(jīng)驗(yàn)進(jìn)行系統(tǒng)總結(jié)，提出Cloud Native這個(gè)詞匯。這個(gè)英文單詞翻譯過(guò)來(lái)，就是云原生(Cloud是云;Native是原生)。遺憾的是Cloud Native提出來(lái)的時(shí)候，并沒(méi)有明確的釋義，僅僅知道它是個(gè)包括DevOps(開(kāi)發(fā)運(yùn)維)、持續(xù)交付、微服務(wù)等在內(nèi)的思想集合。?

這就尷尬了。沒(méi)有明確定義，意味著“仁者見(jiàn)仁，智者見(jiàn)智”，每個(gè)云計(jì)算企業(yè)都可以自行定義，這也代表著云原生并沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。不過(guò)，為了能讓女朋友了解云原生，我還是使勁了渾身解數(shù)，竭盡全力地去胡謅。

Cloud Native可以拆解成Cloud(云/云環(huán)境/云計(jì)算)、Native(本地的/當(dāng)?shù)氐?原生的/土著的)?？梢园l(fā)散一下思維，Cloud Native在翻譯的時(shí)候并沒(méi)有翻譯成云土著、云當(dāng)?shù)?、云本地這些特別別扭的名字，叫了一個(gè)特別優(yōu)雅響亮的名字——云原生。

為了更好地理解云原生，我得借用《晏子使楚》里的“橘生淮南則為橘，生于淮北則為枳”，它的意思是，淮南的橘樹(shù)，移植到淮河以北就變?yōu)殍讟?shù)。因此，對(duì)于橘樹(shù)來(lái)講，淮南是它的原生地，淮北是它的遷徙地。按照這個(gè)原理來(lái)推算，云原生就是為云壞境而生，就是云壞境當(dāng)?shù)氐能浖軜?gòu)，其在設(shè)計(jì)之初便考慮了云環(huán)境。與此同時(shí)，那些設(shè)計(jì)之初沒(méi)有考慮云環(huán)境的本地部署的軟件架構(gòu)需要進(jìn)行遷移，這就叫云遷移。

時(shí)光荏苒、白駒過(guò)隙、斗轉(zhuǎn)星移。當(dāng)年提出的“云原生”在云計(jì)算時(shí)代的價(jià)值愈發(fā)得到彰顯，原來(lái)依靠云遷移的路線，并不能百分之百考慮到云原生環(huán)境，畢竟“橘生淮南則為橘，生于淮北則為枳”，難免水土不服。直到2015年的某一天，Google牽頭成立了云原生計(jì)算基金會(huì)，簡(jiǎn)稱CNCF。這下不妙了，CNCF都成立了，云原生的定義還沒(méi)明確，這難免有些說(shuō)不過(guò)去。從這天開(kāi)始，CNCF日夜苦思冥想：云環(huán)境和本地得有區(qū)別吧;軟件架構(gòu)在本地部署和云上部署也得有區(qū)別吧;云原生到底有哪些技術(shù)更有利于云的發(fā)展。于是，CNCF用容器化、微服務(wù)、編排調(diào)度定義了云原生。

別急，容器化、微服務(wù)等專業(yè)詞匯將在下文統(tǒng)一講述。

再一次時(shí)光荏苒、白駒過(guò)隙、斗轉(zhuǎn)星移。各類的云計(jì)算廠商發(fā)現(xiàn)，CNCF對(duì)云原生的定義，并沒(méi)有那么強(qiáng)烈的說(shuō)服力。每個(gè)廠商依舊在玩自己的云原生，都在用實(shí)際行動(dòng)做自己的云原生。這可怎么辦？既然沒(méi)有統(tǒng)一的定義，那我們就默認(rèn)統(tǒng)一一下云原生的四大核心要素(微服務(wù)技術(shù)、DevOps、持續(xù)交付、容器化)吧!滿足四大核心要素，你做的就是云原生!

說(shuō)了這么多，我也想用最簡(jiǎn)單的話語(yǔ)概括云原生，這里請(qǐng)?jiān)试S我借用華為對(duì)云原生下的定義：采用開(kāi)源堆棧(K8S+Docker)進(jìn)行容器化，基于微服務(wù)架構(gòu)提高靈活性和可維護(hù)性，借助敏捷方法、DevOps支持持續(xù)迭代和運(yùn)維自動(dòng)化，利用云平臺(tái)設(shè)施實(shí)現(xiàn)彈性伸縮、動(dòng)態(tài)調(diào)度、優(yōu)化資源利用率。?

“Wait，微服務(wù)、DevOps、持續(xù)交付、容器化是什么？”女朋友投來(lái)疑惑的眼神，面龐透過(guò)絲絲焦慮，緊接著問(wèn)：“為什么滿足上述四要素就基本上是云原生了？”

我......

好吧，幫人幫到底，送佛送到西。

微服務(wù)技術(shù)

微服務(wù)就是一個(gè)獨(dú)立發(fā)布的應(yīng)用服務(wù)，可以作為獨(dú)立組件升級(jí)、灰度或復(fù)用等，每個(gè)服務(wù)可以由專門的組織來(lái)單獨(dú)完成，依賴方只要定好輸入和輸出口即可完全開(kāi)發(fā)，甚至整個(gè)團(tuán)隊(duì)的組織架構(gòu)更精簡(jiǎn)，溝通成本低、效率高。

好吧，這么敷衍的回答，讓誰(shuí)看，誰(shuí)又能看得懂？噗嗤，我還是秉承負(fù)責(zé)到底的君子之風(fēng)，用購(gòu)物網(wǎng)站的技術(shù)架構(gòu)進(jìn)化為例來(lái)講述微服務(wù)!

第一階段。早年間，小紅在某寶開(kāi)了個(gè)網(wǎng)店，這個(gè)網(wǎng)店的功能超級(jí)簡(jiǎn)單。網(wǎng)店端主要有注冊(cè)登錄功能、商品展示、下單;管理后臺(tái)有用戶管理、商品管理、訂單管理功能。為了管理后臺(tái)的安全性考慮，網(wǎng)店端沒(méi)有和管理后臺(tái)做在一起?？傮w架構(gòu)如下圖。

經(jīng)過(guò)簡(jiǎn)單的部署之后，小紅找了家云服務(wù)廠商進(jìn)行數(shù)據(jù)托管，使用起來(lái)非常方便。

第二階段。隨著移動(dòng)購(gòu)物的興起，小程序、移動(dòng)APP、wap端流量逐漸起來(lái)，營(yíng)銷促銷手段逐漸豐富起來(lái)，小紅知道，之前的網(wǎng)站部署并不能滿足現(xiàn)在的需求了。時(shí)間緊迫，小紅并沒(méi)有規(guī)劃整個(gè)系統(tǒng)架構(gòu)，拍了拍腦袋，決定把促銷管理和數(shù)據(jù)分析都放在管理后臺(tái)里，小程序端和移動(dòng)端另外搭建，架構(gòu)如下。

這個(gè)架構(gòu)有很多不合理的地方，網(wǎng)頁(yè)端、微信端、移動(dòng)端重復(fù)代碼，數(shù)據(jù)通過(guò)數(shù)據(jù)庫(kù)共享，調(diào)用數(shù)據(jù)容易出錯(cuò);網(wǎng)站搭建越來(lái)越臃腫。時(shí)間越長(zhǎng)越限制越限制網(wǎng)店的發(fā)展，這個(gè)時(shí)候，小紅決定必須做出改變。

于是小紅徹底改變了邏輯思維，決定以各項(xiàng)服務(wù)為主導(dǎo)來(lái)建設(shè)網(wǎng)店，比如以用戶服務(wù)、商品服務(wù)、訂單服務(wù)、促銷服務(wù)、數(shù)據(jù)分析服務(wù)為主導(dǎo)，形成各種各樣的微服務(wù)，微信、移動(dòng)端、網(wǎng)站享用同一個(gè)代碼，將網(wǎng)站進(jìn)行了簡(jiǎn)化。架構(gòu)如下：

可是，這個(gè)架構(gòu)還是有弊端，共用數(shù)據(jù)庫(kù)造成從數(shù)據(jù)庫(kù)提取另一個(gè)服務(wù)的數(shù)據(jù)現(xiàn)象，牽一發(fā)動(dòng)全身，還是不夠方便。

于是，簡(jiǎn)化、簡(jiǎn)化、再簡(jiǎn)化，將服務(wù)與各自數(shù)據(jù)結(jié)合的框架，比如用戶服務(wù)數(shù)據(jù)倉(cāng)庫(kù)、商品服務(wù)數(shù)據(jù)倉(cāng)庫(kù)、訂單服務(wù)數(shù)據(jù)倉(cāng)庫(kù)等，這些服務(wù)、數(shù)據(jù)都可以調(diào)用，分工明確，至于弊端在這里不多講。

以上的這些用戶服務(wù)之類的，就是微服務(wù)了。

它們之間其實(shí)是獨(dú)立部署、原子的、自治的業(yè)務(wù)組件，彼此之間通過(guò)消息中間件進(jìn)行交互。

DevOps

DevOps是研發(fā)運(yùn)維一體化，通過(guò)自動(dòng)化流程使得軟件過(guò)程更加快捷和可靠。它不是一個(gè)產(chǎn)品，而是一種新的團(tuán)隊(duì)工作方式、新的技術(shù)理念。

還是那個(gè)說(shuō)法，這么說(shuō)太簡(jiǎn)單了吧，還有些敷衍。好吧，我好好掰扯掰扯。

一般情況下，一個(gè)軟件最終交付經(jīng)歷以下階段：市場(chǎng)規(guī)劃、產(chǎn)品規(guī)劃、編碼設(shè)計(jì)、編譯構(gòu)成、部署測(cè)試、發(fā)布上線、后期維護(hù)等。早期在人員少得情況下，為了能夠及時(shí)交付，軟件走一遍流程基本上交付了。這是早期的瀑布式開(kāi)發(fā)。

之后，隨著人員的擴(kuò)張，這時(shí)團(tuán)隊(duì)里有了產(chǎn)品經(jīng)理、開(kāi)發(fā)人員、測(cè)試人員、運(yùn)維人員的劃分。這些人員負(fù)責(zé)研發(fā)、測(cè)試、上線發(fā)布、運(yùn)維等，整個(gè)過(guò)程不斷開(kāi)發(fā)、測(cè)試、再開(kāi)發(fā)、再測(cè)試，驗(yàn)證無(wú)誤之后部署上線。這就是敏捷開(kāi)發(fā)。

時(shí)間長(zhǎng)了之后，敏捷開(kāi)發(fā)也有弊端，總是在自己開(kāi)發(fā)、測(cè)試，延長(zhǎng)了產(chǎn)品開(kāi)發(fā)周期。為了規(guī)避這個(gè)弊端，DevOps來(lái)了，它將整體的開(kāi)發(fā)需求變成小的需求點(diǎn)，每完成一個(gè)小需求點(diǎn)就上線部署，快速驗(yàn)證，捕捉用戶。

Wait，我還是用“酒店更新菜品”為例，簡(jiǎn)單說(shuō)說(shuō)吧!

瀑布式開(kāi)發(fā)：我們要更新菜品，我們市場(chǎng)調(diào)研、設(shè)計(jì)菜品、品嘗菜品、上線菜品。好了，我們更新完了。

敏捷開(kāi)發(fā)：我們要更新菜品，我們市場(chǎng)調(diào)研、設(shè)計(jì)菜品、品嘗菜品，這個(gè)菜不太好吃，再設(shè)計(jì)菜品、品嘗菜品，咦另一個(gè)菜不好吃，再再設(shè)計(jì)菜品、品嘗菜品，直到?jīng)]有問(wèn)題，上線菜品。

DevOps：我們要更新菜品，我們市場(chǎng)調(diào)研、設(shè)計(jì)一道菜、品嘗菜品、上線這道菜，然后我們?cè)O(shè)計(jì)另一道菜、品嘗菜品、上線這道菜。把每道菜當(dāng)成小需求點(diǎn)，最終完成大需求點(diǎn)。

持續(xù)交付

持續(xù)交付就是一直在交付，敏捷開(kāi)發(fā)和DevOps要求隨時(shí)都有一個(gè)合適的版本部署在生產(chǎn)環(huán)節(jié)上，頻繁發(fā)布、快速部署、快速驗(yàn)證，所以必須要持續(xù)交付。

以前的交付太慢了，現(xiàn)在云原生要求持續(xù)交付，那么如何頻繁發(fā)布、快速部署、快速驗(yàn)證？這里提出了兩個(gè)方法論：灰度發(fā)布、藍(lán)綠發(fā)布?；叶劝l(fā)布很好理解，就是在新需求開(kāi)發(fā)完成之后，讓一部分用戶繼續(xù)使用老版本，一部分使用新版本，如果用戶對(duì)新版本沒(méi)意見(jiàn)，再遷移到新版本來(lái)。

藍(lán)綠發(fā)布實(shí)際上將應(yīng)用從邏輯上分為A、B兩組，版本升級(jí)時(shí)，將A版本從負(fù)載均衡器里刪除，進(jìn)行新版本部署，同時(shí)B組提供服務(wù)。當(dāng)A組升級(jí)完畢之后，按照同樣的邏輯升級(jí)B組。

我們簡(jiǎn)單理解一下藍(lán)綠發(fā)布，某家小飯店想讓僅有的兩名廚師進(jìn)修，同時(shí)不想影響飯店生意，于是飯店想了一個(gè)方法，先讓廚師A進(jìn)修，廚師B在飯店炒菜，廚師A進(jìn)修完畢，廚師B進(jìn)修，按照這個(gè)方法，飯店生意沒(méi)有影響，飯店的廚藝還得到提升。

容器化

容器技術(shù)的定義就是一個(gè)單獨(dú)的應(yīng)用程序進(jìn)程、運(yùn)行資源的高度隔離。

第一階段。最早的時(shí)候，應(yīng)用全部運(yùn)行在電腦等物理機(jī)上，這就導(dǎo)致資源分配不均勻，出現(xiàn)個(gè)別應(yīng)用占用內(nèi)存、計(jì)算資源過(guò)大的情況，其他應(yīng)用難以運(yùn)轉(zhuǎn)。

第二階段。中期的時(shí)候，虛擬機(jī)出現(xiàn)了。虛擬機(jī)是在我們操作系統(tǒng)上虛擬出來(lái)的電腦，在虛擬機(jī)上可以安裝、運(yùn)行各種各樣的軟件，一臺(tái)物理機(jī)可以運(yùn)行多個(gè)虛擬機(jī)，提高了資源利用率，不過(guò)虛擬機(jī)還是在占用物理機(jī)CPU、內(nèi)存、硬盤等硬件資源，整體顯得笨拙。

第三階段。云計(jì)算時(shí)代，要求快速開(kāi)發(fā)迭代、持續(xù)交付等，虛擬機(jī)這種不能保證應(yīng)用環(huán)境都一致，因此，容器化被提上議程，也就是通過(guò)虛擬的軟件資源，把網(wǎng)絡(luò)、存儲(chǔ)分成虛擬容器，應(yīng)用在這些容器中運(yùn)行。

可以說(shuō)微服務(wù)、DevOps、持續(xù)交付、容器化是云原生四大核心要素了，滿足這些，才能成為云原生，就如同云原生的陽(yáng)光、水、空氣一樣。

“我只問(wèn)你微服務(wù)、DevOps、持續(xù)交付、容器化，你有必要說(shuō)這么多嗎?”

好吧......

沒(méi)想到頭懸梁錐刺股之后，依舊逃不脫“承包一個(gè)月家務(wù)”的厄運(yùn)。