歡迎光臨
每天分享高質量文章

從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

赞(0)

分享創造快樂