開發者學堂課程【雲計算、容器和雲原生基礎課程：為什麼要學習雲原生技術（下）】學習筆記，與課程緊密聯系，讓使用者快速學習知識。
課程位址： https://developer.aliyun.com/learning/course/823
為什麼要學習雲原生技術（下）
------馬永亮
目錄：
一、雲原生架構參考示例
二、CNCF的雲原生項目
三、雲原生平台DIY
四、雲原生未來架構趨勢
五、雲原生人才培養計劃課程簡介
1、雲原生架構參考示例
雲原生的架構模型，通過對CNCF所了解的雲原生技術特性的描述，可以大體上描繪出來一個雲原生的參考架構：
●基礎設施層
◆主機、存儲、網絡管理
●預配層(Provisioning)
◆主機建立、作業系統安裝、存儲配置設定等
●運作時層
◆CRI、CNICS
●容器編排及管理
●雲原生應用程式定義與開發
2、雲原生系統的功能特征
●動态化是雲原生應用的天然屬性，微服務架構是支撐該目标的關鍵所在
◆各微服務提供的API應該內建為複合的API，通過“API網關”對外提供統一的通路接口
★API網關對于安全、監控計費等也是必不可少的
◆元件微服務治理
★Istio、OpenPaaS、Linkerd等
◆Serverless
★Knative等
◆各微服務以視窗鏡像進行傳遞
◆雲原生編排平台
★排程、運作、健康狀态檢測、監控
★彈性擴縮容
◆靈活部署:重建、灰階、藍綠、金絲雀、A/B測試、影子(Shadow)部署
動态是雲原生應用和雲原生基礎設施的天然屬性，是以微服務架構是支撐該目标的關鍵所在。每一個服務本身都通過API向外提供其功能，很顯然不希望用戶端的真正的系統外的部分，分别獨立的急需要通信的或需要擷取資料的每一個微服務進行通信。是以各個微服務提供的API應該聚合成為複合的API，通過API網關對外提供一個統一的通路接口。
是以再去建構雲系統的時候還有一個關鍵性的元件叫做API網關，微服治理也就必不可少了。像email open，Open smash，主要是open smash，還有linked等，都是著名的微服治理，尤其是服務網格時代的微服治理的工具。也就是service的平台在service運作時的PPT。除此之外，編排平台去排程運作應用程式對其做出簡單的平等則是Google net的功能和任務對應的微服務治理通常還能夠支援相對應服務的回頭釋出的獵豹經濟部署、A/B測試等等相關功能，是以原生系統大概就具有了剛才摸索或者一個對應的原系統。
根據這種架構模型拼接的話，拼接出來這些對應的各個解決方案，大體上就能實作具有類似特征的或類似描述特征的元素。于是采用雲原生技術的組織或者公司所建構的雲原生系統，大概從一個粗略的角度描述的話。有這樣幾個層級，首先底層基礎設施很可能是私有雲、公有雲或者是混合雲，而後在雲環境的基礎之上，應該添加和部署一個對應的容器編排平台，就是copper。如果需要到無服務計算的話，還需要額外提供一個SaaS的平台，就是sunlight接着在該平台之上，就可以提供類似于叫做容器及服務的這麼一個接口，叫CS接口。再接着向上，應該去提部署和提供一個微服務，運作平台，那就是服務網格系統，去運作自己的各種各樣的以微服務形式存在的業務單元，這些單元甚至包括底層平台自身都應該納入監控系統來，如果沒有監控，幾乎就沒辦法管理。是以立體化監控系統、包括日志、名額監控、還有對應的分布式鍊路跟蹤系統等所組成，這是現代銀行系統幾乎所必然要具備的幾個監控元件。還有API網關剛收購API網關要實作API。
統一的流量管理，尤其是接入外部系統時的流量管理，它包括API治理、流量控制等相關功能。很顯然，對這麼多的微服務應用，必要時應該展現到它，叫做認證對應的通路國有服務技術，還有它能夠支援的項目對應服務，一般往新部署A/B層是線上上層的，其實就是開發認證，是以雲聯上新改成具有高效摸索，而一個對應的雲聯系統，如果要做金融高層架構模型系統拼接的話。
3、雲原生架構體系的參考執行個體
在公有雲、私有雲之上，釋出管道應該有一個Kubernetes墊片，然後在此基礎之上，提供一個微服務的基礎，通常它是一個service mash，在這個service max的基礎之上，應該從開發架構，提供各種各樣的中介，確定各個微服務之間的正常的發現等出發。要提供的監控系統，確定每一個服務都要納入到監控體系中來，現在各種各樣的網絡管理功能，為了確定高效的去傳遞每一個微服務應用，還應該遵循這個所謂的甚至是get UPS這樣的模型來實作應用的啊。事實上在新功能上，當然接入外部的通路流量時，應該有一個服務的統一接入接口。
4、雲原生的技術範疇
總的來說雲原生的技術範疇，大體可以歸類為六個方面，第一個是雲應用與定義與開發流程，第二個是雲原生底層技術，第三個雲應用編排與管理，第四個雲原生工具集，第五個監控與可觀測線。
而這個就是我們的service，這其中包含了比如應用的定義，還有鏡像制作，CSD。伯希和流式資料，還有資料庫底層運作和容器運作時，是存儲技術，雲原生存儲技術，接着原生的編排與管理，這裡主要是cool max和surface max就是Excel等相關元件的功能工具及這裡大家應該容易了解這個描述監控系統就是個例，調監控系統，這就是雲原生體系應該具有的技術範疇。
5、如何建構雲原生
有鑒于此，隻要遵循前面的範式，把對應系統組合起來，基本上就能夠建構出一個雲原生的基礎平台了。在這個雲生的這個平台當中，它的每一層各有各的作用，比如總結一下我們微服務架構，就是解決單體架構導緻。
5.1如何設計和使用雲原生架構
應用雲原生構架是有應用複雜性問題的，但是它拆分成微服務以後，這個複雜性就留給了外部的治理系統，而并不是真正的減少了這個服務的複雜，或者降低了服務的複雜性。另外，服務治理架構和立體化監控方案能夠解決服務間協同基調異常的情況，問題那些，那很顯然立體化監控方案，在這個監控時代依然是需要的，雖然這個圖當中畫的是傳統的應用中有了第二層。但事實上，監控系統對雲原生體系來講更是重中之重的元件，那個借助于應用應用技術，容器技術解決應用建構、分發和部署等相關的問題。
容器在某種程度上原生環境中扮演着不可變基礎設施的角色，K8S用于編排、排程和彈性，Service用于解決微服務架構的侵入式和流量治理等功能。Switch運作于K8S之上，還可以提供更好的容器底層環境支援。借助于ras雲和容器技術，可以進一步解決不可變基礎設施的相關問題，這就是如何是和使用雲原生架構。
1、在CNCF主導下的為主流的、現在的雲原生生态當中的相關項目有很多，這其中可能最為重要的就包括了前面所提到的如果想真正的完整的建構出一個雲原生的技術平台所需的元件或直接或間接使用的雲原生的相關項目是遠遠不止這麼幾個的。
2、Maturity levels
上面的這幅圖其實就是由CNCF主導原生态技術或者項目全景圖可以看CNCF網站。想要擷取這個原生态圖，那麼這個對應的生态實景當中組合的項目大體可以被編排為：事關應用開發、事關編排與管理、事關運作時、與平台的監控與分析的service，以及CSD等相關這幾個大類。這每一項都可以點開放大進行詳細觀看。除此之外，這種平台的那個項目更多的是對應的托管服務，或者是安裝服務等相關。
3、畢業的項目
以上是已經畢業的項目，比較典型的代表：第一個就是著名的containerd。事實上的S支援的最為标準的底層的容器運作環境，被稱作CoroDNS，預設所對接的一個容器運作時環境，CoroDNS他是個原生的DNS服務，是對英語S之上的各類服務的總線，用于幫助CoroDNS完成服務的注冊服務，發現名稱解析等功能，因為這是Excel的資料平面。Excel的資料平面是個KV存儲一個KV存儲系統，它身上也是K8S SAPS SERVER會将k server提a server的所有資料存儲的真正或者存儲的真正位置，進而appstore隻是一個無狀态的HTTP服務或者應用伺服器，所有資料都委托給高一緻性的分布式的鍵值存儲系統。這個fluentd的這個著名的運費系統跟立體化監控有關，這是容器系統資料庫或者鏡像，系統資料庫兒在容器中當中是一個非常關鍵。還有這是應用大包組建接着立體化監控系統的分布式追蹤組K8S,顧名思義這是開放政策引擎，事實上是在K8S之上，應該至少說可以被用作cortex之上，這是基于屬性的防控系統中一個開放的教育開源的開放的政策引擎，能夠幫助使用者去制定安全政策的。Promietheus監控系統，這是名額監控，這是分布式鍊路追蹤，這是日志采集系統好基于CNCF等存儲系統的原生的存儲系統，分布式存儲系統half這個更新架構，然後Vitess再造。這是國人所研發的一款分布式的分布式KV存儲系統，它也是TDB的機子。基礎設施Vitess應該是個Mexico的啊，原生的這個水準擴充架構，為這事已經畢業的幾個重點項目，那麼florence的日志系統要用到，特别是名額監控用到，那麼容器系統資料庫私有的通常也要用到，Erhelm則是用我們在CT上簡單部署就簡單管理應用的一個非常重要的元件。是以在将來要學習和使用雲原生技術，這裡已經畢業的項目幾乎絕大多數人都用到。
4、孵化中的項目
幾乎很多孵化中的項目，已經有不少公司在在采用了。比較關鍵的組建：比如像CONTOUR，即便不能把它稱為叫API Gatewag的解決方案，但它實際上也是K8S上一個非常重要的元件，叫做in gress control的實作。cortex叫做容器網絡接口的規範。CNI全稱叫Container Network Interface（容器網絡接口），其目标是為容器建立基于插件的通用網絡解決方案。CNI的說明在規範中定義了。CRI-O這是一個類似于container d的容器運作時CRI的解決方案。dragonfly這是阿裡所維護的一個容器鏡像服務，它的功能有點容器系統資料庫，叫鏡像系統資料庫服務可能更好一點。
flagger是一個k8s operator,可以基于多種ingress 實作金絲雀更新，以進行流量轉移,并使用Prometheus名額進行流量分析。canary分析器可以通過webhooks進行擴充，以運作系統內建/驗收測試，負載測試或任何其他自定義驗證。
Flagger實作了一個控制環路，該環路逐漸将流量轉移到金絲雀，同時測量關鍵性能名額，例如HTTP請求成功率，請求平均持續時間和Pod運作狀況。 基于對KPI的分析，金絲雀會被提升或中止。
5：沙箱中的項目
●項目很多，列舉幾個由阿裡雲貢獻的代表産品
◆OAM/KubeVela-開放架構模型及其在K8s上的完整實作OAM/KubeVela
◆OpenYurt--業界首個“非侵入式”式的邊緣雲原生項目OpenYurt
◆OpenKruise--雲原生應用自動化引擎
◆Fluid-雲原生環境下的資料密集型應用的高效支撐平台
1、如果想自己動手DIY一個雲原生平台的話，大體上要用到的元件或者列出來一部分。如果要附加監控體系還要分别在每一個方向當中各自選擇一個元件。
2、基于Kibernetes的Paas示例架構
這些公有雲服務商一定會體貼的把現在技術趨勢下所需要用到的各種需求，幫我們提供一個一整套的需求。
例：阿裡雲雲原生平台産品
阿裡雲雲原生平台分别提供了各自的結局方案，比如阿裡雲雲原生DevOps工具鍊是曾經榮獲信通院研發營運解決方案分級能力的最高認證。目前有一百萬的企業開發者、十萬➕以上的企業使用者，在使用該服務。
阿裡雲容器的服務産品，這裡有阿裡雲托管的Kibernetes服務，有阿裡雲托管的服務叫ACK。阿裡雲對應的還提供了ASK服務也就是serverless，除此之外還提供了服務網格，也就是阿裡雲服務網格解決方案。
四、雲原生未來的架構趨勢
1、未來的架構趨勢
●通過把所有傳統中間件（例如ESB）的功能移到其他運作時元件，未來的雲原生模型實作了如圖的整個功能環，不久之後，人們在服務中唯一要做的就是編寫業務邏輯
對于雲原生未來的體系當中的這些功能當中生命周期管理交給了底層的容器編排平台Kibernetes，對應的網絡管理，服務治理交給服務網格系統，對于綁定和網絡管理的另外一部分（無伺服器計算）可以交給Knative，而對于狀态管理、穩定等需求，可以交給dapr或者cloud state等元件，這樣一來再去開發任何雲原生運用程式時，完全可以将經曆隻集中在Business logic之上。但是現在很多公司所使用的雲原生（K8S）環境本身隻提供了K8S和建構在Kibernetes之上的基礎設施，比如：消息隊列、資料庫等。
2、未來的架構趨勢
●因而可以把不同領域進行創新的各種雲原生項目進行疊加
◆Kibernetes：基于現代應用容器技術在多語言應用程式的生命周期管理
◆服務網站：在Kibernetes之上實作了進階網絡功能
◆Knative：專注于Serverless型的工作負載，同時滿足了服務編排和事件驅動的綁定需求
◆Dapr:建立在Kibernetes Knative和服務風格的思想之上，深入應用程式運作時以解決有狀态工作負載：綁定和內建的需求，進而充當現代化分布式中間件；
五、雲原生人才培養計劃系列課程簡介
第一階段Kubernetes課程大綱
●最容器技術基礎
●Kubernetes系統核心概念及工作模型
●使用kubeadm部署叢集微
●API資源模型及Pod基礎
●Pod使用進階:資源需求、資源限制、多容器Pod
●存儲卷
●使用ConfigMap和Secret配置Pod應用●服務發現與Service資源
●應用編排之ReplicaSet和Deployment
●應用編排之DaemonSet、Job和CronJob
●應用編排之StatefulSet
●綜合應用案例