開發者學堂課程【雲計算、容器和雲原生基礎課程：為什麼要學習雲原生技術（上）】學習筆記，與課程緊密聯系，讓使用者快速學習知識。
課程位址： https://developer.aliyun.com/learning/course/823
為什麼要學習雲原生技術（上）
------馬永亮
目錄：
一、課程介紹
二、雲原生簡介
一、課程簡介
●由阿裡雲、Linux開源軟體學園和馬哥教育聯合推出
◆“CNCFxAlibaba雲原生技術公開課”的前置課程
◆CKAD/CKA/CKS認證的配套課程
●内容涵蓋
◆手把手實踐Kubernetes雲原生作業系統
◆阿裡雲Kubernetes托管服務ACK。
1、資訊疊代的關鍵曆程
從上個世紀80年代到今天，開發流程、應用架構、打包部署、基礎設施等軟體和資訊系統領域的相關技術，分别進行了各自不同形式的疊代，而且也各有各的裡程碑式的代表技術，像開發流程中的瀑布模型、靈活模型，再到今天。比較火熱的Dev Ops，甚至是get UPS模型，都經曆了三代類似的軟體架構，也從最初的單體架構，到後來的分層架構、分布式架構，再到今天的微服務架構，也是經曆了非常有代表性的幾代打包和部署技術，面向的這個主題環境，從最初的裸伺服器，到後來的虛拟機，再到今天主流的容器化技術，也有三代非常典型的代表性技術。最後對應的基礎設施的維護模型，從最初的資料中心，到後來的托管，再到今天的雲計算，顯然也有三個非常典型的發展的裡程碑，從圖中也可以非常清晰的看到微服務、容器化和雲計算，這是今天的主流模型，這其中不得不提一提的就是分布式技術的應用，随着業務規模的擴張，應用程式從單體走向、分層分布式以縱向或者是橫向切分的。
2、分布式系統面臨的困難
分布式系統是将大的應用，切分成多個小應用，幾乎适用于提升系統容量、加強系統可用性的必然選擇。但是任何解決方案都不是理想化的，一旦分布式系統引入優勢的同時，也必然會帶來一些問題，比如釋出的頻率非常高，而且部署起來部署的頻次也非常高，并且部署起來要解決這種依賴關系。是以部署也較為複雜，而且它的難度級數是增加的，更重要的是，因為網絡通信的引入，那麼響應時間慢就變成了一個非常讓人難以接受和容忍特性，運維的複雜度也被成倍的放大了，接着其整體的系統的出現故障以後測試排錯複雜。但是為此它帶來的好處也包括：因為分布式開發應用，大的單體應用被切分成了多個小的應用。各個應用、每個應用、每個單獨的應用更加容易實作的開發故障的影響範圍呢，通常也局限在單個應用的範圍内，而且通過所謂的這種擴充機制，也能夠将這種故障的影響範圍給它降低，因為這是統一機制所帶來的好處之一。
很顯然，為了把這些問題解決，為此呢，也引入了很多技術手段：比如什麼服務治理、架構管理，自動化運維、資源排程管理、整體架構監控，立體化監控體系，還有流量治理的技術手段來幫忙解決，在引入分布式服務化架構帶來的好處的同時也要去解決他可能要面臨的衆多問題。
3、建立及運作分布式應用的需求
●運作分布式應用的典型需求有如下幾個類别
◆生命周期管理
◆網絡
◆狀态管理
◆綁定(應用內建)
●ESB中間件及其變體是滿足這類分布式需求的前一代主流解決方案
◆提供良好的功能集
◆但是，單體架構以及業務邏輯和平台之間緊密的技術耦合會導緻的技術群組織的中心化。
大體上展示了每一個需求次元可能會涉及到的一些技術細節點，比如對生命周期管理來講，需要關注的包括打包健康狀态檢測、部署更新、擴縮容應用配置等。
而網絡次元則有向服務的發現、測試、釋出重試、逾時熔斷，還有消息隊列安全、可觀測性等，而在綁定方面，則有連接配接器那協定、消息格式等相關的話題。在狀态管理方面，也有多個話題存在，比如工作流、管理、幂等性、緩存等相關的功能，顯然能夠滿足這些需求的解決方案曾經的主流系統是Binding。
3.1ESB分布式應用中間件的限制
變體ESB其實就是衆所周知的企業服務總線，比如像面向消息的中間件，還有一些輕量級的內建架構等，是以從這個角度上來講就是一款中間件，他支援利用面向服務的架構實作異構環境間的這種互操作性，也提供了良好的功能及，但是單體架構以及業務邏輯和平台之間緊密的技術耦合，一定會導緻技術群組織的中心化，是以這是一個與分布式應用本身或者與最初引入分布式系統背道而馳的趨勢。
ESB在滿足分布式系統需求的局限性也同樣在這四個方面各有所表現，比如在生命周期方面，它通常隻支援一個語言的運作時，當然這幾個一般而言，它通常隻是一個語言，這其中最為典型的代表就是Java。這也就限定了軟體該如何打包，哪些庫可以用，能夠提升打更新檔的頻率等。另外一個業務服務必須要使用這些對應的庫，而這些庫與平台的這種緊耦合程度決定了必然要使用相同的語言進行編寫，是以這些對系統擴充而言一定會帶來極大的束縛。
在第二方面，很顯然網絡上集中于一種主要程式設計語言及其相關技術，在網絡方面依然也要受限于此。更重要的是，網絡問題和語義也一定會深深嵌入到業務服務當中，是以這也就使得将來的這種更新、，架構變更，會牽一發而動全身。比如對Java語言來講，很顯然這種解決方案指的就是JMSRGPCR，在狀态方面，與狀态互動的庫和接口并沒有完全抽象出來，也沒有與服務運作時進行完全結束，是以架構程式與架構本身也是緊耦合的。綁定這個方面使用內建中間件的主要驅動因素之一就是能夠使用不同的協定、資料格式、消息交換模式等來連接配接其他系統。很顯然，這些連接配接器必須與應用程式共存，這也就意味着将來這種依賴項必須以業務邏輯一起進行更新和打更新檔。這種綁定導緻的系統擴充，也是極其受限的。面對這樣的問題，發展到今天相應的解決方案大體上就變成了基于容器化容器編排系統、UPS微服務及典型的智力系統服務網格等技術綜合于一體的，被稱為叫做雲原生的解決方案。
4、雲原生的定義
原生的定義其實雲原生的概念，最早是在2013年由Matt Stine于2013年在Pivotal司就職的時候提出的。2015年的時候，當雲原生這個概念剛剛開始流行的時候，Matt Stine在他出版的一本書當中定義了雲原生架構的幾個關鍵特征，這其中最為著名的包括：12要素，應用程式、微服務，自助是靈活基礎設施。還有基于API的協作和反脆弱性；并且在2017年InfoQ的采訪當中，Matt Stine做了一些改變，并且提出了原生的六個特征：括号化，可觀測性、可部署性、可測試性、可替換性和可處理性。後來在其官網上對雲原生的架構進行一個比較規範性的描述，他認為雲原生是具有如下四大特征或者的這樣一種應用：DevOps、持續傳遞、微服務、容器化。他們認為這種原生應用一定會要滿足，或者基于這幾種技術進行建構。2015年成立的雲原生計算基金會CNCF呢定義了雲原生架構，有三個基本特征：容器化封裝、自動化管理以及微服務。
●2018年，CNCF在關于雲原生定義v1.0版本中這樣描述雲原生技術體系
◆雲原生技術有利于各組織在公有雲、私有雲和混合雲等新型動态環境中，建構和運作可彈性擴充的應用
◆雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API
★這些技術能夠建構容錯性好、易于管理和便于觀察的松耦合系統
★結合可靠的自動化手段，雲原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更
●雲原生計算基金會(CNCF)緻力于培育和維護一個廠商中立的開源生态系統，來推廣雲原生技術。
要注意的是，随着雲原生生态和邊界的這種不斷擴大化，雲原生自身的定義肯定會在過去被多個個人、組織或者公司從不同的次元進行了解讀。很顯然在未來也一樣會有人對他進行不同的定義，甚至就包括CNCF很有可能也會改變對于原生的定義。如果說要根據摩爾定律來進行推斷的話，未來對于雲原生定義一定還會不斷的發生變化，但一個顯著的事實是，容器加K8S已經成為一個計算的底座。
5、容器技術(Containers)和容器編排
●容器技術由來已久，dotCloud(後改名為Docker)公司在Docker項目中發明了“容器鏡像”技術之後，創造性地解決了應用打包的難題才煥發出新的生命力，并以“應用容器”的面目風靡于世
●單個容器難以産生價值，容器編排才是根本
◆Kubernetes是雲原生系統的底座
●現代應用容器技術和Kubernetes将打包、部署應用程式的方法演化成了與程式設計語言關的格式。
6、Kubernetes和聲明式API
●Kubernetes的關鍵特性
◆容器編排系統
◆聲明式API
◆“以應用為中心”的現代應用基礎設施
★納管各類基礎支撐類服務，并經由聲明式API向上層應用暴露這些基礎設施的能力
◆PlatformforPlatform類型的系統
★根本目标在于友善基礎設施工程師建構其它的平台系統
★例如ServiceMesh或Serverless等
7、微服務治理
微服務本身可以了解為傳統的分布式服務的進一步細化，細化到每一個服務本身可能進行提供一個單一的功能，并且将其功能、接口通過API向外界提供。是以從這個意義上來講，微服務是一種流行的架構風格，它用于建構彈性化。高度可擴充、可獨立部署且能夠快速疊代的應用程式，那單體應用被切分成了多個小型的應用，每一個應用獨立進行管理，甚至于每個應用都有自己的獨獨占的存儲系統。因而微服務架構就是由一系列的小型自治服務所組成的，每個服務基本上子包含的。目前的雲計算環境系統是一個有着公有雲、私有雲和混合雲等新型的動态環境系統，很顯然，動态化是從計算應用的天然屬性，同時它也是雲原生的天然屬性，而這種動态性為了能夠更好的得以開發、建立、運作，必然要用到微服務的網格，幾乎必然的要用到一種所謂的叫做服務治理體系，服務治理架構，其中微服務架構是支撐該目标的關鍵所在。通常情況下，為了便于使用者開發、建立、維護和運作微服務系統或者微服務應用，通常要依賴于一個對應的服務治理架構或者服務治理工具。這其中比較著名的代表有：Dubbo、 spring cloud以及spring cloud的增強版spring cloud alibaba，還有下一代的微服務治理系統，也就是服務網格。
8、服務網格（ServiceMesh）
●服務網格定義：
服務網格在分布式架構或者是微服務架構系統當中服務到的通信是至關重要的，是以要確定通信通道要保持無故障、安全、高可用和足夠健壯。是以這些需求之處，恰恰就是服務網格作為基礎結構元件所出現的地方，而它的使用方式是通過在每一個應用執行個體的外層附加一個服務代理，來確定受控的服務到服務的同行的。在上圖當中，差不多可以看出來一個端，這其中每一個單元就是一個有淺藍色底色，淺藍色這個種叫業務邏輯，深藍色這個這個方框為叫做Sidecr的應用所共同組成。在服務網絡當中，與單個服務一起部署的代理就可以實作服務之間的通信。這個代理被通稱為被稱為叫做Sidecr，主要負責各個業務單元執行個體之間的這種通信相關的功能，比如負債均衡服務、斷路、逾時、重試一系列各種各樣的進階功能。當然，服務網格并不是一蹴而就出現的，它恰恰就是在曾經說過的最早期的這種，再到後來Dubbo、 spring cloud等一路發展的基礎之上，所衍生出來的新一代的這個通行模型通行概念。
9、Sidecar模式
●ServiceMesh以Sidecar形式，将服務治理從業務邏輯中剝離，并拆解為獨立程序，實作異構系統的統一治理和網絡安全。
10、不可變基礎設施(immutableinfrastructure與一次性元件
●不可變基礎設施是早在2013年由ChadFowler在其一篇部落格中提出的一個很有的預見性的構想
◆其核心思想在于，任何基礎設施的執行個體一旦建立之後即變為隻讀狀态，若需要修改和更新，隻能通過替換為新的執行個體來實作
◆傳統的伺服器(裸金屬或虛拟機)支援配置的多次變更，因而通常會導緻如下問題
★災難發生時，重新建構較為困難(因手動的變更操作所緻)
★存在導緻狀态不一緻的風險毒
●實作
◆容器和容器鏡像
◆雲端虛拟化元件