前言

網際網路的快速發展，帶來了一大批新的名詞，這次名詞的更新換代的速度也是快的驚人，往往一波未平一波又起，使得大家不能墨守成規，必須不斷學習才能趕得上科技和技術的發展潮流。

計算機行業更是如此，可能真的要實踐活到老學到老的古訓了。精通一個技術然後躺著賺錢是不存在的，因為可能幾年後這項技術就被淘汰無人問津了。所以千萬別再說計算機的高薪如何的不合理。計算機行業只能算門檻不低且付出和產出相對成正比的行業。

回到本文的標題，如果問大家這幾個名詞你聽說過嗎？大部分人肯定會說：“Yes，I do!”。但是如果讓你說清楚他們都是什麼以及他們之間的關係，可能不少小夥伴就要撓頭了。這些概念可能很多人都知道一點，但又說不清楚。

本文通過講述中國歷史上的部分制度和組織形式來類比這幾個概念的關係，網上的抽象定義我也就不過多討論了，而是通過形象比喻的方式另闢蹊徑，從其他角度讓大家瞭解下這些概念，能達到基本明瞭不求甚解的目的。如果還是不懂，可以直接找作者，作者負責搞定你的問題或者搞定你~

雲vs雲端計算：中央集權下的資源管理

春秋戰國時期，國家的軍隊和資源都分散在全國各地，大家各自為政，自負盈虧。好處就是管理好自己的一畝三分地就好。但是缺點也很明顯，大家各自為政，自立為王，不聽國家和天子的號令。然後各個諸侯之間也通過鑄造自己的貨幣，流行自己的文字，推廣自己的度量衡等方式人為的設定壁壘。這種情況下，國家的內耗十分嚴重，嚴重影響整個社會的發展。

對映到遠古時代的軟體行業，一個大公司可能有多個機房，這些機房之間的資源都是一臺臺的物理機。這些資源基本上都是隔離的，比如做資料庫的部門需要使用小型機這種高效能裝置，你把行政部門的2C4G的PC給到資料庫部門，他們也用不上，在加上部門之間的資源之爭，更是這種資源隔離情況雪上加霜。公司很難高效的管理這些資源。最後的結果是員工很痛苦，公司高層很苦惱，怎麼破？雲就在這種情況下產生了。

再回到歷史，秦始皇的出現解決了這一切。隨著六國的滅亡，秦國一統天下。緊接著秦始皇就釋出了“車同軌、書同文、幣同制以及統一度量衡”的操作，使得全國的資源統一管理。

再回到雲的問題上，後續公司高層決定將所有的伺服器都集中到一起進行管理，資源在資源池進行管理。各個使用者按照需求進行資源的申請，再也不會出現伺服器用不了的情況，硬體資源的使用率和管理效率空前提高，大家都很開心。

由於當前的使用者獲得的資源不再是實體的物理機，而是虛擬的資源單元，所有的物理機資源都被遮蔽了不會和終端使用者直接互動，就好像在雲端一樣，這也是雲或者雲平臺的由來。而基於雲平臺上的各種計算分析以及分配管理就組成了雲端計算的雛形。

雲端計算vs霧計算vs邊緣計算：將在外，軍令有所不受

中央集權成立後，資源終於可以有效的組織和使用了，下面就來看看效果吧。

有一天，中原王朝的老對手匈奴來騷擾秦朝了。草原民族的鐵騎輕鬆碾壓了秦朝的步兵，就算偶爾獲勝也是殘勝。於是秦朝開始在北方構建長城，形成以長城為基礎的兵營據點群來防止匈奴的入侵。

咋一看好像很不錯的計劃，但是古代沒有電話和無線電，如何傳遞訊息和請示行動計劃呢？這是個大問題。

想象下面這個場景，匈奴如果大舉入侵該如何應對？當前有兩個最直接的方案：

• 在長城地區長期維護大量的常規部隊以應對某天匈奴的大舉進攻：這種方案能及時的應對匈奴的大隊入侵，但是在長城地區維護這麼大規模的常備軍成本將會是天文數字，更不用說邊境地區能不能養得活這麼多軍隊。這種方案顯然不是長久之計。
• 在長城地區只維持適量的常規部隊，大量的部隊在國家的腹地等匈奴來進攻的時候在出動去迎擊敵人：這種的好處就是平時的成本很合理，戰時也能有軍隊支援，價效比很高。但是這裡會有一個問題，如果邊境的常規軍無法堅持到朝廷援軍的到來就被攻破了，或者報信的傳令兵在傳令的途中遇到不測，那麼這場戰爭同樣輸定了。

這也不行那也不行，那怎麼辦呢？

其實方法也很簡單，那就是在朝廷和邊境之間增加一些行政和軍事節點來解決問題。即在第二條方案的基礎上進行改進：軍隊和戰略物資不僅在朝廷和首都有，在朝廷和邊境之間加上州郡來分級管轄和處理邊境上報的事務。每個級別的機構都有對應的許可權和能力參與到整個資源的請求和管理中。

這樣整個的流程就變成這樣：邊境的常備軍將軍被授予假節鉞的權利，可以根據敵人入侵的規模來判斷該如何應對這場戰爭。如果常備軍能解決，則直接解決；如果常備軍解決不了，則向就近的郡縣調動軍隊和資源來參與戰爭；如果還不能解決，則向再上一級的州府調動資源；如果匈奴舉國入侵，州府一級也無法應對了，那麼就將請求傳送到朝廷，使用最高規模的戰爭動員來應對國運之戰。

從上面的例子可以看出，戰爭動員會根據戰爭的規模來決定在哪一級別的組織解決這個問題。畢竟戰爭時期時間成本和運輸成本是最重要的。

試想，如果因為事事都要從朝廷要資源，那麼可能不等資源到位，戰爭就輸了；亦或者從朝廷將軍隊派往邊境，還沒等軍隊到邊境，補給就快用光了，那後續的仗還怎麼打？這件事情如果不理解，可以去問問當年北伐屢敗屢戰的諸葛亮。

上面就是從歷史角度來說明的雲端計算、霧計算和邊緣計算的使用場景。回到當前的資料處理場景，如自動駕駛場景，業務會要求如下的需求：

• 如果出現險情，需要快速的處理，防止車禍的發生。
• 自動駕駛感測器產生的資料量巨大，儘量較少頻寬等資源的消耗，控制成本。

上述的需求決定了不可能所有的計算分析和操作控制都放在雲端的資料中心。因為巨大的資料傳輸量以及可能存在的網路延遲都是上面兩個需求所不能容忍的；而把所有的處理都放在客戶端，客戶端的硬體成本以及整體的可實現性也不允許這樣做。

所以在這種情況下，就需要將部分計算按需求和能力下放到離客戶端較近的地方，通過各級計算節點的特點來將客戶端需要計算和處理的問題分拆到合適的計算節點進行計算，以滿足不同的場景和需求。

所以，當前的常規方案就是分場景解決不同的問題：

• 首先在汽車感測器和雲平臺之間增加一到兩級的計算中心
• 如果發生緊急的事情，比如緊急剎車這種需要緊急處理的事情，車載晶片或者計算機就可以直接處理，已達到快速解決的目的
• 如果想獲取附近的地圖資訊或者就近的線路規劃，可以將資料和計算放在汽車附近的基站，加快資料傳輸以及處理速度
• 針對其他基站無法完成的計算，如行駛模式推薦或者整車狀態分析等資料則需要雲端的資料中心並結合歷史的規則和大資料經驗進行資料彙總和計算分析
• 資料每一層上報都會進行資料的篩選以及聚合彙總，然後處理一部分，繼續上報一部分，大家各司其職，配置完成各種複雜的操作

舉個不恰當的例子，上面的雲端的資料中心對應的就是雲端計算，而附近基站以及車載晶片以及電腦就對應著霧計算以及邊緣計算。這樣類比可能不是很恰當，但是可以幫助大家快速理解他們的概念，理清他們之間的關係。

而在實際技術落地的過程中，霧計算和邊緣計算是有部分重疊的。在很多業務不是很複雜，層級不是很高的場景下，霧計算和邊緣計算其實可以認為是重疊的，都是為了在減少成本降低資料延遲而將計算下放到離客戶端很近的地方。

雲端計算vs雲原生：三公九卿制vs三省六部制

最後來說說雲端計算和雲原生的關係。

虛擬化階段

最早的雲端計算其實就是分配給你你需要的硬體資源，大多數就是各種類似虛擬機器的資源，你在這上面想幹什麼就幹什麼，雲平臺並不關心。

這就好比要打仗了，將軍領命後，朝廷只給了你一群人，一堆鐵器和很多給養。你需要自己練兵，自己打造兵器，自己管理給養。雖然經過一段時間也能訓練好部隊，然後帶兵打仗。但是這樣做的短板很明顯：

• 軍隊的水平完全取決於將軍的實力，效果不可控。真正實踐了兵熊熊一個，將熊熊一窩的古訓
• 打仗的準備週期太長，可能不等你訓練好軍隊，敵人已經把你滅了

回到軟體的世界，翻譯成軟體用語就是：

• 系統搭建效果不可控，完全取決於運維人員的技術水平
• 系統搭建週期較長，多環境部署的話，重複工作量大

容器化階段

這些問題出現後，大家很快都開始尋找其他方式能解決上述的問題。秦朝時候發揚光大的三公九卿制登上了歷史舞臺。首先，權力機關已經按照功能劃分成三公，三個人分管不同的事務。回到上文的例子，此時兵已經按照兵種和規模編排成不同的隊伍，三公之一的太尉會組織相關人員根據經驗針對不同的戰爭規模給予不同的資源搭配。這樣戰爭到來之後太尉根據戰爭情況直接將打包好的資源搭配給到領兵將軍，將軍帶兵直接去打仗就好了。

這樣子一下子就解決了練兵的問題，還會根據不同的情況使用不同的資源搭配直接就解決問題了，真是太爽了，從此媽媽再也不用擔心我打仗的問題了。

但是真的就萬無一失了嗎？慢慢的新的問題又來了：

• 我們在變，敵人也在變，每次來打仗的敵人都和上次的規模組成不一樣，導致我們需要準備很多套方案，慢慢的，維護這些方案就變得難以承受了。
• 針對很多相似的戰爭場景，本來可以通過某些搭配的微調就可以達到目的，但是由於這些方案都是事先定好的。所以需要向朝廷重新申請，而改變了一點，那麼他相關的點也會影響很大，可能需要重新評估這套方案的可行性，耗時費力。

回到軟體的世界，這就是容器的時代，這個時代的佼佼者就是docker，docker容器使得很多資源都被封裝成一個一個容器。在安裝部署期間直接使用容器就可以部署好一個服務，使得安裝部署對運維人員的要求降低了很多。另外基礎容器之間可以通過組合的方式打包成高階的容器用來部署複雜的服務，使得一鍵部署複雜服務變成可能。

這麼看起來docker已經解決了上面的兩個痛點。雖然這樣，但是docker仍然面臨兩個問題：

• 如果複合容器中的一層發生變化，影響同樣很大。docker容器和洋蔥一樣，是一層一層的，如果想要修改中間的一層，那麼需要剝開這一層外面的所有層才能達到目的，這會帶來很多不必要的工作和消耗。
• 如果跨容器配合的話，docker缺乏有效的容器編排機制，雖然docker swarm充當了這個角色，但是很快就被其他競爭者超越，而超越它的就是我們接下來要說的雲原生技術。

雲原生階段

歷史上三公九卿制發展了很多個朝代，雖然不斷優化，但是還是沒能完美的解決問題。直到三省六部制的出現才算徹底的解決了問題。三省六部制是將權利在三公九卿制的基礎上進一步細化，做到精確計算，靈活組合。

比如打仗這件事情不再是一個人或者一個部門說的算，而是由尚書省下的兵部、戶部以及工部協同負責。那麼戰爭準備就會變成下面這樣：

• 帶兵的將軍根據戰爭實際情況提出自己的需求和預期
• 兵部會根據兵員的需求提供不同數量不同兵種的兵員
• 戶部負責根據戰爭週期預期準備這些兵員所需的糧餉補給
• 而工部則會根據不同的兵員兵種提供不同的武器彈藥

從上面來看，大家各司其職，按照標準給出不同的資源，共同彙集成了這次戰爭的準備。由於是職責劃分清楚且標準統一，所以這樣子給出的資源往往是比較合理的，效果也比較好。就算出問題了，也很好追責；追責之後一個部人員更換，由於標準統一，按照標準辦事也不會影響到其他人從而避免影響整個戰爭準備。

回到軟體的世界，讓我們來簡單看一看雲原生的東西：

雲原生都做了什麼

• DevOps：自動化管理，持續整合，開發和運維人員配合快速的部署以及解決問題
• 持續整合：不斷的整合，快速迭代，快速解決問題
• 微服務：保證各個服務獨立部署，獨立管理，任何一個服務都可以單獨升級，單個服務故障也不會影響整體服務的執行
• 容器化：資源的封裝以及整合，遮蔽底層的使用細節，降低運維人員使用門檻和成本

雲原生都用了什麼

• 容器：k8s+docker為主(k8s之前預設的容器載體，1.24版本以後containered已經成為新的標準，可以預見以後K8s的容器選擇會變得多樣化)，docker負責容器封裝，k8s負責容器編排排程。
• 服務網格：service mesh（Istio），配合k8s進行流量以及安全管理，通過Sidecar（邊車）模式可處理服務之間通訊的任何功能，比如負載均衡、服務發現等。
• 微服務：一個大型應用程式按照功能模組拆分成多個獨立自治的微服務，每個微服務僅實現一種功能，具有明確的邊界，通過REST等形式的標準介面進行通訊和資料交換，這是一種松耦合的互動形式
• 不可變基礎設施：一個基礎設施環境被建立以後不接受任何方式的更新和修改。這個基礎設施也可以作為模板來擴充套件更多的基礎設施。帶來的好處就是能提升應用交付效率，能快速、可靠地水平擴充套件且能保證基礎設施的快速更新和回滾
• 宣告式API：相對於過程式設計API，過程式是每一個操作都必須正確完成才能達到最終的目標。而宣告式API則是指定了目標，系統則不斷通過調整向目標靠近，最終達到目標。

總結

從上面的描述我們可以看出來，上面四個概念，其實可以分為兩組：

• 橫向：雲端計算、霧計算以及邊緣計算其實都是雲端計算，只是為了滿足不同的需求以及場景而導致的計算位置不同而已。
• 縱向：雲端計算以及雲原生，雲原生只是在雲端計算的基礎上發展而來，雲原生將雲端計算的優點保留，缺點完善，形成了一個靈活、完整、擴充套件性和可靠性極強的超級雲端計算，而云原生也代表了未來雲端計算的發展方向。

本文到這裡告一段落，本文是想讓大家通過形象的例子達到管中窺豹，略見一斑的目的。

這些概念都很大，隨便一個展開都能寫個幾萬字，我這裡就簡單的從一個角度上說說就得了，大家感興趣可以自己研究下，或者我在後續的文章中再詳細說明下。

雲平臺出現後，曾經有人說“一切皆可上雲”；再後來元宇宙出來後又有人說“一切皆可元宇宙”。元宇宙能不能一切皆可我不確認，但是我還是相信“一切皆可雲原生”的，起碼軟體可以是這樣的！

文章到這裡就結束了，如果想一起入門學習K8S的小夥伴，歡迎點贊轉發加關注，下次學習不迷路！