從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，成了分散式微服務中介軟體。噢耶，終於跨過這個技術門檻了。

 

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

 

這就需要工具了。

 

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

 

為了更快捷地打包、分發、部署、升級、維護，人們發明瞭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和雲端計算技術已經梳理成“Kubernetes技術和實戰總結”電子書，請點選“原文連結”檢視詳情(目錄如下)。

 

第一章 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-O 25

3.1.2執行時CRI-Containerd 26

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 更新資源物件的Label 53

8.4 應用的滾動升級 53

8.5 Kubernetes故障排查 54

8.6 Kubernetes監控 54

8.7 Kubernetes總結 54