從4方面解釋，什麼叫雲原生應用？

編者註：本文作者呂建偉，作者重點從4個層面全面介紹了雲原生的起源和發展，幫助讀者學習雲原生概念。

從Function到Service

一、從函數說起

我是1993年學習電腦的。學習的開發語言有三種：彙編、C、DbaseIII。

所以在我學習的時候，我並不了解面向對象的代碼架構設計和代碼編程實現。所以要從字面上來區分函數和函數之間的關係，主要就靠函數命名、放在同一個代碼文件里、放在同一個代碼目錄文件夾里來區分他們之間的關聯性。

在當時函數時代，也沒啥異常保護、異常處理、異常日誌的函數編寫基本原則，所以我們除了命名以外，主要注重的就是函數的輸入數據參數以及格式、輸出數據的參數以及格式。

二、面向對象

我的面向對象是用Object Pascal開始的，但真正大量寫面向對象代碼的時候是使用Delphi，那已經是1996年的事情了。

因為有了類這個東西，所以函數就可以物以類聚了。有的函數屬於私有函數只能這個類裡面才能調用，有的函數屬於公有函數可以供外部調用。

但是我那時候使用類還很初級，往往是一個源代碼文件中就定義一個類。而且類也沒有使用繼承，也就是說我所有的類都是平行的，類和類之間通過Public型的公開函數調用才產生了關係。

三、面向介面

Delphi這個開發語言是優美的，它的定義申明和它的詳細實現是分離的。

業務功能進一步複雜起來了，過去沒什麼太多關係的業務現在關係越來越緊密了，有些類和類之間的調用就太多了。我就想著重寫這塊代碼，把這兩個類進行合併了。但一重寫吧，需要動的東西太多了。

用繼承、用多重繼承的方法來做吧，太麻煩，總要在實現里寫一個空函數（就是沒有代碼但只有函數架子的，以備編譯器能語法通過）。後來認識了介面，就用介面定義了，就不使用空函數了，就定義，不實現，編譯器照樣能通過。

四、面向組件

我是完整經歷過面向組件時期的，並且用面向組件技術編寫過一整代完整的ERP引用套件。從CORBA技術到COM/DCOM/COM 技術都嫻熟學習並使用過。我也是完整經歷單機版本到C/S客戶端伺服器端區域網版本到C/S/S三層架構的。

一開始我用DBaseIII寫應用，UI開發、業務邏輯開發、資料庫開發都是一個開發語言搞定。

後來用Delphi寫C/S應用，就用了SQLServer大型關係資料庫，在資料庫層就寫了不少存儲過程和定時JOB任務。但當時業務邏輯代碼和UI代碼都是運行在客戶端，所以這兩層之間的分離也並不清晰。

然後寫C/S/S三層架構，業務邏輯層獨立出來，而且是物理獨立部署，這樣客戶端代碼和業務邏輯層代碼就必須要徹底分開，不能不清不楚地混雜在一起了。在那個時候，我才開始大量使用精心的介面設計、對象設計。

因為有了獨立的業務邏輯層，那麼這些代碼（介面/類）何時創建對象實例，何時釋放，這些對象實例要運行在哪個進程容器中，就有了要求了。因而就產生了組件容器和組件。組件容器來管理組件的全生命周期（安全、創建、並發訪問控制、休眠、激活喚醒、計數、摧毀釋放內存），組件管理器就來管理組件的註冊、發現等。

所以《COM本質論》的作者Don Box說.NET就是更好的COM，我一下子明白了：對啊，微軟的意思是，以後所有的應用都應該運行在組件容器中，不管是單機應用，還是C/S應用，還是C/S/S應用，每個應用都要運行在組件容器中，由組件容器來屏蔽和管理內存的創建與回收，不要把內存的創建與釋放直接袒露給開發者，否則開發者技術能力水平不一，有的爛的程序員管理不好內存，很容易就會使應用佔滿內存並導致操作系統崩潰。

五、面向WebService

哈哈哈，大家好像都沒聽說過面向WebService，大家好像就聽過面向服務。

Web互聯網興盛起來，HTML（UI元素定義） CSS（UI元素風格定義） JavaScript（UI元素操作）構成了前端技術。人們又從前端里分離出來XML，成為數據容器。可以用HTTP 80埠進行傳輸純文本的XML數據，也可以用UDP、TCP/IP等各種傳輸協議進行傳輸。當然，XML還可以被壓縮以便更小尺寸在互聯網上傳輸（尤其過去互聯網速度很慢），還可以被加密不讓人中間截獲看到。這些就構成了WebService的一個技術族。

我們現在要把區域網版本的C/SS/三層技術架構，升級到Web/S/S三層技術架構，那怎麼辦呢？

所以我們需要在我們的組件基礎上再包裝一層WebService，客戶端的AJAX技術就好調用了。所以當時.NET組件技術、EJB技術、.NET組件容器、EJB組件容器中間件，都紛紛原生內嵌支持WebService技術族，讓從開發到運行到調用，直接就是WebService技術。這就是SOA：面向服務架構。

微服務

一、物極必反

當時是多麼理想啊：一整套J2EE體系，WebService EJB完美組件模型 WebLogic SOA組件容器/ESB組件管理器中間件，包括技術架構師。當年是多麼多麼大的市場啊。

但程序員是實用主義者，怎麼簡單怎麼來。隨著第二波互聯網創業熱崛起（2004年），大幹快上才是王道，沒錢用開源開幹才是王道。

於是，WebService換成了REST、XML換成了JSON、EJB換成了普通的JAVA Class、WebLogic換成了開源的Spring。尤其在2004-2006年，SSH這三駕馬車（Structs前端、Spring中間層、Hibernate數據層）真是橫行世界。

尤其2004-2006，Google崛起如日中天，Google統一開放了自己的Open API，輕的很。這已經是微服務流行的啟動了。但這時候還不能稱作微服務，可以稱作簡化服務（WebSerivce）。

二、亞馬遜的天條

貝索斯從2002年就親自製定了亞馬遜分散式系統架構六條原則：

1、所有團隊的程序模塊都要通過WebService介面將其數據與功能開放出來

2、團隊間程序模塊的信息通信，只能通過這些介面進行。其他形式一概不允許：不能用動態鏈接庫、不能讀取其他團隊資料庫、不能試用共享內存、不能試用別人模塊的後門，唯一允許的通信方式只有調用WebService。

3、所有的Web Service，毫無例外，都必須從骨子裡到表面上都設計成能對外界開放的。也就是說，團隊必須做好規劃與設計，以便未來把介面開放給全世界的程序員，沒有任何例外

4、不這樣做的人會被炒魷魚

5、一個服務由一個小團隊（兩張披薩餵飽）負責，從前端到數據，從需求分銷到上線運維，全權負責

6、逆向工作法：先定義未來，然後發布新聞稿進行客戶探索與交互，再進行實現執行

我看到這六條原則，我也就明白了為啥亞馬遜能做成公有雲計算領頭羊了，我也就明白了在現在Cloud大行其道的時候，亞馬遜還一直堅持使用AWS這個品牌（Amazon Web Service）。

我個人認為，從亞馬遜全職能小團隊、內外一體化原則開放WebSevice開始，服務才真正變小，成為微服務。如果你是個100人的團隊，你是一個按專業職能劃分的團隊，你是一個一年就發布2次的團隊，你是一個區分內部調用和外部調用的團隊，我相信，你是成不了真正的微服務的。你充其量來說，只能說，你是一個用了微服務技術卻沒有實現微服務的團隊。

這很好理解。很多程序員用了一輩子面向對象的開發語言，但從未自己定義過真正的類。這就是中國。

雲時代

一、移動時代來了

90年代我們用C/S，用C/S/S Corba、DCOM/COM ，2000年以後我們用.NET、EJB/WebLogic，後來我們又用REST、JSON、Spring。這都是業務邏輯層技術的演進變化歷史。

在客戶端，倒是互聯網訪問速度越來越快費用越來越低、屏幕越來越大、性能越來越高、內存越來越大，給客戶呈現出來的功能越來越多、UI界面越來越複雜。你這個時候想做微服務，其實蠻難的，你受不了誘惑，總想給它添加更多的功能，反正客戶端性能高、屏幕大，能承載，沒壞處。

但是移動時代從2011年在中國開始了。手機網速慢資費高、性能慢、內存小、屏幕小、沒有鍵盤和滑鼠只能手指頭劃屏幕，所以微信從語音消息而非文字消息崛起了（打字輸入實在不好打啊）。

小屏幕，無鍵盤無滑鼠，不好輸入也不好輸出，那麼功能就必須簡化再簡化。這就倒逼業務邏輯層也不能做的太複雜。因此即使沒有亞馬遜開除人的六大天條轟頂，微服務在移動時代也算真正被大規模流行起來。現在小程序技術依託微信平台（統一客戶、IM、支付），讓開發、部署、發布更加簡化。

因為人人都有了隨時隨地可訪問的智能設備，所以企業比以往任何一個時代都能更容易連接、觸達、交互到最終消費者。所以企業應用開始從企業內部管控建設重心轉移到連接消費者、與消費者交互、消費者直接下單交易的業務重心。一個軟體的應用的使用主體從可以管控炒魷魚的員工，轉移到了給企業進行買單交易的衣食父母。

衣食父母不能得罪啊，這是要影響銷售業績的啊，所以需要抓住黏住、快速改進。所以為了快，而不要跨專業職能部門協作，所以各個研發團隊也都自行改組，從專業職能部門組織形式改造成為亞馬遜式的全職能小團隊，這更加助推了微服務的實質化落地。

所以，移動化限制倒逼、衣食父母倒逼，這是移動時代才讓大規模萬金油程序員學會落地微團隊、微項目、微功能、微服務。

二、雲時代來了

因為企業應用重心已經從可數的企業員工用戶轉移到了大規模外界的消費者用戶，所以高性能並發、海量數據的技術要求立馬上來了。但企業應用開發者一直面對企業內部用戶規模，不是互聯網企業啊，怎麼應對啊，沒經驗啊。

正好，雲時代來了。

提供了分散式對象系統、分散式資料庫、分散式大數據技術平台、分散式消息隊列中間件。當然，Spring升級成了Spring Cloud，成了分散式微服務中間件。噢耶，終於跨過這個技術門檻了。

別高興太早了。因為是分散式的，因為是面對海量最終消費者的，所以部署工作成了複雜的了。不像過去做企業內部管理應用，最多也就十來台伺服器，人手工都能升級得過來，而且企業員工一下班就能開干。現在都是消費者應用了，消費者都是行為習慣各異需要24x7運行，而且這還是交易型應用，你還不敢斷掉，你還不敢一下子全升級了你怕出個交易閃失賠不起錢，所以你還需要灰度發布。

這就需要工具了。

所以DevOps在互聯網時代、雲計算時代才真正流行開。就是因為：海量用戶、在線24x7實時運行、交易型、大規模伺服器、快速迭代開發發布上線，不得不開發運維一體化。過去運維人員的技術要求性不高，現在運維人員也得有開發技術能力了。

為了更快捷地打包、分發、部署、升級、維護，人們發明了Docker和K8S。Docker可以打包為一個鏡像文件、Docker讓微服務的版本環境隔離、Docker讓微服務在開發期和運行期一致，這讓分發、安裝部署、升級、運維變更極為簡化。

雲原生應用

一、微服務不微是因為什麼

微服務不微，是很多人的困惑。

雖然有了全職能微團隊（2張披薩餅）、微UI（移動APP和小程序技術）、微項目（每兩周迭代發布一次），但微服務仍然不微。

雖然有了滿足海量用戶高並發的Spring Cloud分散式微服務中間件、有了滿足分散式部署和運維的DevOps（Jakins/Docker/k8s），但微服務仍然不微。

問題到底出哪裡了？

咱們從開發流程再捋一捋。

軟體公司嘛，軟體代碼是我們的核心資產。所以我們肯定有我們私有的Git源代碼庫，部署在我們公司的IDC機房裡面，而且做層層的安全防護以及代碼備份機制。

我們要開發的時候，需要在我們本地安裝部署需要的各種框架，才能做本地開發、本地調試。但是現在為了應對高並發分散式中間件、海量大數據存儲與計算、人工智慧訓練、物聯網接入，我們需要安裝的依賴的技術框架高達40多種以上。光部署調正常這堆框架已經把我們累的精疲力盡，而且這些框架之間隨便出點參數變更或版本不兼容問題就搞死人。

好，總算調正常這一堆框架，我們開發完具體業務應用，我們就開始應用DevOps工具和Docker，進行打包、分發、部署。這麼多依賴性的框架，你的微服務能微的了嗎？

二、雲原生應用

正確的打開方式是什麼呢？讓我們描繪一下。

第一步：你的代碼放在雲代碼平台而非你公司內部私有部署的Git平台上。這就是微軟要花大價錢併購Git的原因。這是第一步。為什麼要這樣做，你接下來就明白了。反正你現在基於雲計算、大數據、人工智慧、IOT開發具體業務應用的時候，你大量依賴的都是開源平台，就你那點具體業務應用能有多高技術門檻。而且微軟接手後的git，對於企業代碼的安全保護、備份，比你自己的管理員和運維技術高多了。

第二步：使用雲開發平台。這個開發平台可以基於Web瀏覽器，也可以基於本地VS Code IDE，但云開發平台的核心本質是：你根本不需要在本地安裝那麼多依賴框架，你在IDE裡面寫應用，你打開雲上Git平台上面的某個源代碼文件，import進一個包，然後在IDE里直接調用API，這個雲開發平台會自動補全API，你可以保存代碼、你可以編譯代碼、你可以調試代碼、你可以運行代碼，和你本地一樣，但其實是應用運行在雲端，應用也是在雲端進行打包、安裝部署的。

這才是真正的雲開發平台，比如AWS的Cloud9。現在有很多李鬼，把20多年前雅奇MIS的那套玩法又拿了出來，快速可視化設計輸入表單，圖形化進行審批工作流設置，快速可視化設計報表圖表，這個東西在全世界也沒有獨立市場存在過，而且也不是今天我們談到的雲原生應用開發路徑上的東西，或者換句話說，那根本不是給開發人員用的。

第三步：使用雲服務OpenAPI。雲計算廠商把所有的雲服務都開放出來Open API（你想想Amazon的六個天條），你可以在這個雲開發平台上直接調用這個雲計算廠商的所有Open API開放平台裡面的API。這些雲服務會自己負責自己的安裝部署升級、監控、備份、遷移等等。

三、終極：Serverless

最終極的方式是：Serverless。那個時代的IaaS、技術PaaS、應用PaaS、具體業務應用SaaS很豐富，大家都開放Open api，也有Slack、企業微信、釘釘這樣的統一門戶平台，也有小程序UI前端技術，你打開Web IDE，New一個函數，裡面直接調用Open API，你的應用功能就串聯起來了。

你也不用在意什麼打包、安裝部署等細節。當你要運行時，在雲端後台，會自動啟用一整套DevOps/Docker工具集給你打包，會根據自己的雲計算資源給你具體進行安裝與部署，你根本不用管是部署到哪個伺服器上了。隨著你的應用性能，他會去給你自動遷移擴展到更高性能的計算環境中。這一切對於你來說都無感。你每月只需要繳納一筆總費用即可。

不這樣推，開發人員的效率提不上去；不這樣推，軟體公司只使用雲廠商的雲硬體資源，其他軟體中間件都自行開源部署而不使用雲中間件，那樣雲計算廠商也不容易掙大錢啊，畢竟硬體都是剛性成本，只有軟體才是高利潤的，尤其是雲上部署的分散式中間件服務，更是大規模高利潤的。

第一章 Kubernetes介紹和技術背景1

1.1 Kubernetes歷史1

1.2 Kubernetes主要功能3

1.3 Kubernetes的定位5

第二章 Kubernetes架構分析6

2.1 Master功能分析7

2.2 Workers功能分析7

2.3 Kubernetes操作對象7

2.3.1 Kubernetes POD詳解8

2.3.2 Replication Controller詳解9

2.3.3 Kubernetes Services詳解11

2.3.4 Labels和Label Selector詳解14

2.3.5 Kubernetes Namespace解析15

2.4 Kubernetes架構和核心組件16

2.4.1 Kubernetes架構組件17

2.4.2 Master節點解析19

2.4.3 Node節點解析22

第三章 Kubernetes容器運行時 25

3.1 Kubernetes運行時介紹25

3.1.1 運行時CRI-O25

3.1.2運行時CRI-Containerd26

3.2 CRI是什麼26

3.3 CRI總覽是什麼27

3.4 CRI生命周期管理機制27

3.5 CRI容器為中心的介面29

3.6 CRI容器交互特性29

3.7 CRI當前進展和狀態30

第四章 Kubernetes關鍵特性30

第五章 Kubernetes存儲能力32

第六章 Kubernetes網路分析33

6.1 容器間通信技術分析33

6.2 Pod間通信技術分析35

6.2.1 官方網路插件36

6.2.2 第三方CNI插件36

6.2.3 主流CNI插件差異對比37

6.3 Pod到Service通信37

6.4 外網到內網的通信40

6.5 CNI在Kubernetes的應用40

6.5.1 CNI技術介紹40

6.5.2 CNI和CNM對比分析44

6.5.3 CNI規範的插件45

6.6 IP與服務提供方式46

6.7 Kubernetes網路配置方案47

6.7.1 直接路由網路方案47

6.7.2 Flannel疊加網路方案47

6.7.3 Open vSwitch網路方案48

第七章 Kubernetes其他技術介紹49

7.1 Kubernetes調度流程49

7.2 Kubernetes代碼結構51

7.3 Kubernetes部署視圖51

第八章 Kubernetes日常運維技巧52

8.1 Node的隔離和恢復52

8.2 Pod動態擴容和縮放53

8.3 更新資源對象的Label53

8.4 應用的滾動升級53

8.5 Kubernetes故障排查54

8.6 Kubernetes監控54

8.7 Kubernetes總結54

溫馨提示：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！