《云原生入門級開發者認證》學習筆記之云原生架構總覽(一)【與云原生的故事】

寫在前面

報了考試，所以學習，這里整理筆記記憶

學習的原因：

雖然考了CKA,了解了一些K8s相關的知識

但是對云原生一直都很模糊

希望對云原生有一個基本的認識

通過學習實現云原生相關入門

傍晚時分，你坐在屋檐下，看著天慢慢地黑下去，心里寂寞而凄涼，感到自己的生命被剝奪了。當時我是個年輕人，但我害怕這樣生活下去，衰老下去。在我看來，這是比死亡更可怕的事。--------王小波

一 云原生架構總覽

云原生技術的發展

2001年，VMware發布了第一個針對x86服務器的虛擬化產品ESX和GSX，即ESX-i的前身。

2006年10月，以色列的創業公司Qumranet在完成了虛擬化Hypervisor基本功能、動態遷移以及主要的性能優化之后，正式對外宣布了KVM的誕生。2009年4月，VMware推出業界首款云操作系統VMware vSphere。

2006年，AWS推出首批云產品Simple Storage Service (S3)和Elastic Compute Cloud(EC2)，使企業可以利用AWS的基礎設施構建自己的應用程序。

2010年7月，Rackspace Hosting和NASA聯合推出了一項名為OpenStack的開源云軟件計劃。

2011年，Pivotal推出了開源版PaaS Cloud Foundry，作為Heroku PaaS的開源替代品，并于2014年底推出了Cloud Foundry Foundation。

2008年，LXC（Linux Container）容器發布，這是一種內核虛擬化技術，可以提供輕量級的虛擬化，以便隔離進程和資源。LXC是Docker最初使用的具體內核功能實現。

2013年，Docker發布，組合LXC，Union File System和cgroups等Linux技術創建容器化標準，docker風靡一時，container逐步替代VM，云計算進入容器時代。

2015年7月，Google聯合Linux基金會成立了CNCF組織，kubernetes成為CNCF管理的首個開源項目。

2018年3月，Kubernetes從CNCF畢業，成為CNCF 第一個畢業項目。

云原生的定義

云原生定義-Pivotal早期觀點

Pivotal公司的Matt Stine于2013年首次提出云原生的概念,并推出了Pivotal CloudFoundry和Spring系列開發框架,是云原生的探路者。

2015年,云原生剛推廣時,Matt Stine在《遷移到云原生架構》一書中定義了符合云原生架構的幾個特征

符合12因素應用(12 Factors Application)

面向微服務架構(Microservices)

自服務敏捷集成設施(Self Service Agile Infrastructure)

基于API的協作(API-Based Collaboration)

抗脆弱性(Antifragility)

云原生定義-Pivotal當前論述

Pivotal官方網站對云原生最新論述如下:

云原生是一種構建和運行應用程序的方法,它利用了云計算交付模型的優勢;

云原生關注如何創建和部署應用程序,而不是在何處(云計算);

雖然現在公有云影響了幾乎每個行業的基礎設施投資思想,但類似云的交付模式并不僅限于公有云環境,它適用于公有云和私有云;

云原生結合了DevOps、持續交付、微服務和容器的概念;

當公司以云原生方式構建和運營應用程序時,它們可以更快地將新想法推向市場并更快地響應客戶需求;

2019年，Pivotal被vmware收購，成為其子公司。

云原生定義-CNCF早期觀點

云原生計算基金會(以下簡稱CNCF)是一個開源軟件基金會,成立于2015年7月,隸屬于Linux基金會。致力于云原生(Cloud Native)技術的普及和可持續發展。。CNCF是GitHub上許多增長最快的項目的提供者的中立家園，其中包括Kubernetes，Prometheus和Envoy等

起初,CNCF對云原生的定義包含以下三個方面:

應用容器化(Software stack to be Containerized)

面向微服務架構(Microservices Oriented)

應用支持容器的編排調度(Dynamically Orchestrated)

到2018年,隨著社區對云原生理念的廣泛認可和云原生生態的不斷擴大,還有CNCF項目和會員的大量增加,起初的定義已經不再適用。

云原生定義-CNCF當前定義.(2018年更新后的定義論述如下:)

云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中,構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。

可變服務器基礎架構:服務器會不斷更新和修改。使用此類基礎架構的工程師和管理員可以通過SSH連接到他們的服務器,手動升級或降級軟件包,逐個服務器地調整配置文件,以及將新代碼直接部署到現有服務器上。換句話說,這些服務器是可變的;它們可以在創建后進行更改。由可變服務器組成的基礎設施本身可稱為可變傳統或(貶低)手工藝。

不可變基礎架構:其中服務器在部署后永遠不會被修改。如果需要以任何方式更新,修復或修改某些內容,則會根據具有相應更改的公共映像構建新服務器以替換舊服務器。經過驗證后,它們就會投入使用,而舊的則會退役.

不可變基礎架構的好處:基礎架構中更高的一致性和可靠性,以及更簡單,更可預測的部署過程。它可以緩解或完全防止可變基礎架構中常見的問題,例如配置漂移和雪花服務器。但是,有效地使用它通常包括全面的部署自動化,云計算環境中的快速服務器配置,以及處理狀態或短暫數據(如日志)的解決方案

總得來說有以下幾大核心理念:

利用容器和服務網格等技術,解耦軟件開發,提高了業務開發部署的靈活性和易維護性

以Kubernetes為核心的多層次、豐富的開源軟件棧,被各大廠商支持,用戶選擇多,避免廠商綁定

以Kubernetes為核心的松耦合平臺架構,易擴展,避免侵入式定制Kubernetes已被公認是platform for platform

中心式編排,對應用和微服務進行統一的動態管理和調度,提高工作效率和資源利用率

底層:主要是在運行容器化服務之前,需要為容器準備標準化的基礎環境,比如用于自動化部署和配置容器運行平臺和環境,代表性工具和廠商包括Ansible、Chef 、Puppe ,OpenStack等。容器鏡像庫。憑據管理主要用于在整個容器平臺中進行秘鑰管

Runtime(運行時):容器的整個運行環境,是云原生底層技術中最核心的部分它包括了運行時、存儲、網絡三大塊,Runtime提供容器的運行環境(Docker)。存儲要解決容數據器持久化的問題。網絡也是非常核心且非常復雜多變的一塊內容,常見方案有Calico、Flannel ,open Switch等。

編排調度層,主要負責容器平臺的編排和調度,包括服務的發現和治理,遠程調用服務代理,微服務治理等組件。

最上層 就是跟應用定義與開發相關的內容,主要是一些技術或工具來支撐。

橫向上 云原生還包括眾多的經過認證的平臺供應商。應用運維層,包含了大量用于對平臺進行監控(Prometheus-Nagios -Grafana 、Zabbix等) 、日志(Fluentd ,ElasticSearch ,Logstash) 、以及追蹤(Jaeger)的工具。最后還有一塊是關于無服務器架構serverless的內容

容器可以將應用本身及其依賴打包,使得應用可以實現“一次封裝,到處運行”。容器也可以理解成一種沙盒技術,沙盒在計算機安全領域中是一種安全機制,為運行中的程序提供的隔離環境。

容器核心價值可移植性:

環境標準化,應用隨處運行敏捷:

創建速度快,秒級資源彈性提高生產力:

消除跨服務依賴性和沖突

主流的容器技術,如Docker,它是通過內核虛擬化技術(namespace以及cgroups等)來提供容器的資源隔離與安全保障。由于Docker通過操作系統層的虛擬化實現隔離,所以Docker容器在運行時,不需要類似虛擬機額外的操作系統開銷,提高資源利用率。同時,Docker能夠幫助你快速地測試、快速地編碼、快速地交付,并且縮短從編碼到運行應用的周期,從而使得企業實現業務敏捷。

針對期望狀態結果給出聲明,而不是過程

對于我們使用Kubernetes API對象的方式,一般會編寫對應API對象的YAML文件交給Kubernetes (而不是使用一些命令來直接操作API) 。

所謂“聲明式”,指的就是我只需要提交一個定義好的API對象來“聲明”(這個YAML文件其實就是一種“聲明”)表示所期望的最終狀態是什么樣子就可以了。而如果提交的是一個個命令,去指導怎么一步一步達到期望狀態,這就是“命令式”了。可以說,聲明式API是Kubernetes項目編排能力“賴以生存”的核心所在。

非侵入式接管應用服務通信

細粒度流量治理:灰度發布、故障注入、可觀測性支持

平臺團隊聚焦框架層的開發和調優

業務團隊聚焦業務本身的開發

Service Mesh-詞最早由開發 Linkerd 的Buoyant公司提出,并于2016年9月29日第一次公開使用了這一術語

服務網格通過非侵入式的方式接管應用的服務通信。對于每個業務單元/模塊來說他們甚至不需要對網絡通信、負載均衡等有任何的感知,。

服務網格提供細粒度流量治理,包括灰度發布、故障注入、可觀測性支持等能力,挺高了業務應用的易維護性。

對于企業開發者來說,服務網格可以很好地幫助他們剝離業務代碼和分布式框架。

在CNCF的定義中,微服務也是作為一種代表性的技術,而實際上,微服務更側重于描述軟件架構,這種軟件架構相比單體架構,更加能夠發揮云原生相關的技術優勢

微服務是一種用于構建應用的架構方案,它是松散耦合的分布式架構框架,因此一個團隊的更改不會破壞整個應用。使用微服務的好處是,開發團隊能夠快速構建應用的新組件,以滿足不斷變化的業務需求。

微服務架構有別于更為傳統的單體式方案,可將應用拆分成多個核心功能。每個功能都被稱為一項服務,可以單獨構建和部署,這意味著各項服務在工作(和出現故障)時不會相互影響。比如你在線購物時,使用搜索欄來找產品,這個搜索功能就是一項服務,同時你也看到了相關產品推薦,這些推薦也是來自于另外一項服務,還有購物車等,都是一項一項的服務

DevOps=開發(Development) +運維(Operations) ,是打通開發與運維之間的壁壘,促進開發、運營和質量保障(QA)等部門之間的溝通協作,以便對產品進行小規模、快速選代式地開發和部署,快速響應客戶的需求變化。它強調的是開發運維一體化,加強團隊間的溝通和快速反饋,達到快速交付產品和提高交付質量的目的。

云原生應用

云原生應用程序是專為云模型構建的。這些應用程序由小型專用功能團隊快速構建和部署到一個平臺,可提供輕松的橫向擴展和硬件解耦-為組織提供跨云環境的更高靈活性,彈性和可移植性。”-Pivotal

云原生應用是獨立的小規模松散耦合服務的集合,旨在提供備受認可的業務價值,例如快速融合用戶反饋以實現持續改進。簡而言之,通過云原生應用開發,可以加速構建新應用,優化現有應用并將這些應用全部組合在一起。其目標是以企業需要的速度滿足應用用戶的需求。” -RedHat

基于云原生的相關技術,設計運行在云上的,充分發揮云優勢的應用。

一般采用容器的打包、分發、部署的形式,應用內(間)采用微服務的架構,充分利用云提供的組件服務,采用DevOps的組織架構和方法,通過CI/CD工具鏈,實現產品和服務的持續交付。

Heroku于2012年提出12因素,告訴開發者如何利用云平臺提供的便利來開發更具可靠性和擴展性、更加易于維護的云原生應用。

第一基準代碼。一份代碼庫對應多份部署,所有部署的基準代碼相同,但每份部署可以使用不同的版本

第二,依賴。顯式聲明依賴關系,通過依賴清單確切的聲明所有依賴項,這一做法會統一應用到生產和開發環境。

第三,配置。在環境中存儲配置,推薦將應用的配置存儲于環境變量中,環境變量可以非常方便地在不同的部署間做修改,卻不動一行代碼。與配置文件不同,不小心把它們遷入代碼庫的概率微乎其微,與一些傳統的解決配置問題的機制,比如Java的屬性配置文件相比,環境變量、語言和統計無關。

第四,后端服務。把后端服務當作附加資源,每個不同的后端服務是一份資源,例如個mysql數據庫是一個資源,兩個mysql數據庫被當做兩個不同的資源,云原生應用將這些數據庫都視作附加資源,這些資源和他們附屬的部署保持松耦合。

第五,構建發布運行云原生應用,需嚴格區分構建、發布、運行這三個步驟。舉例來說,直接修改處于運行狀態的代碼是非常不可取的做法,因為這些修改很難再同步回構建步驟

第六,進程。以一個或多個無狀態進程運行應用,在運行環境中,應用程序通常是以個或多個進程運行的

第七,端口綁定。通過端口綁定來提供服務。

第八,并發。通過進程模型進行擴展,在12-factor應用中,進程是一等公民。12Factor應用的進程主要借鑒于unix守護進程模型。開發人員可以運用這個模型去設計應用架構,將不同的工作分配給不同的進程類型。例如,HTTP請求可以交給web進程來處理,而常駐的后臺工作則交由worker進程負責

第九,易處理。快速啟動和優雅終止和最大化健壯性,這有利于快速彈性的伸縮應用迅速部署變化的代碼或配置文件的部署應用。

第十,開發環境與線上環境等價,盡可能的保持開發預發布線上環境相同。

十一,日志。把日志當做事件流,日志應該是事件流的匯總,將所有運行中的進程和后端服務的輸出流,按照時間順序收集起來。

十二,管理進程。后臺管理任務當做一次性進程運行,一次性管理進程應該和正常的常駐進程使用同樣的環境,這些管理進程和任何其他的進程一樣,使用相同的代碼和配置,基于某個發布版本運行,后臺管理代碼應該隨其他應用程序代碼一起發布,從而避免同步問題

云原生架構原則及常用模式

彈性:微服務采用無狀態設計,支持按需使用、自動水平伸縮;實例快速啟動,并在不影響業務的前提下優雅中止。這一點可以充分利用云的彈性的特征,利用云環境提供的鏡像、監控、資源動態編排和調度服務。設計應用程序時,不綁定特定基礎資源使其能夠自由伸展,根據需要增刪實例。

分布式:更多強調解耦。應用側,則是業務邏輯和數據解耦、業務邏輯和會話解耦,數據分布式,每個服務擁有自己的數據庫,服務不能直接訪問其他服務的數據庫,只能通過服務接口訪問其他服務的數據。

高可用,高可用的概念范疇比較廣,云原生應用的設計特征,Design For Failure,即“為失敗而設計”,這里主要強調基于不可靠的基礎設施資源來設計高可用系統,并且在應用實例失效的情況下,系統能快速發現并恢復。高可用的設計的主要原則有可觀測、可灰度、可回滾等。實現的方式有很多種,比如,通過k8s實現POD狀態的監測和維護,通過灰度發布、藍綠部署等手段來保證升級、回滾時系統的高可用。

自動化:業務/服務的顆粒度更小,交付部署更頻繁,迫切需要系統能夠自動化部署同時要增強對服務以及所部署的軟硬件環境的全方位監控、評估能力。

自服務:自服務強調服務可被其他應用或開發者自助發現,自助按需獲取,自助使用并計量,自助服務管理。自服務的前提是高度自治,同時,從易用性的角度,暴露友好的交互方式(Web界面、命令行、SDK…) ,使能應用開發者簡單、高效地使用其提供的功能

單體架構的局限性

單體架構的問題不在于不可拆分上,在于無法隔離和自治。應用規模越大,局限性越明顯

微服務架構就是其中一種實現方式。它實現了服務徹底拆分,各服務可以獨立打包、獨立部署和獨立升級,對開發者而言,擺脫開發語言的束縛。每個微服務負責的業務比較清晰,利于后期擴展和維護。微服務之間可以采用REST和RPC協議進行通信。同時,微服務架構可以和其他云原生技術完美結合,充分發揮云的優勢。

微服務獨立性和敏捷性更好,架構持續演進更容易,更適合云原生應用

Serverless (無服務器架構) 指的是由開發者實現的服務端邏輯運行在無狀態的計算容器中,它由事件觸發,完全被第三方管理,Serverless是在傳統容器技術和服務網格上發展起來,更側重讓使用者只關注自己的業務邏輯即可。

Serverless方案業務價值更輕量化:

用戶專注于業務創新和代碼開發,代碼運行環境由云平臺提供,無需管理基礎設施資源。

更快彈性:根據請求的并發數量自動調度資源運行函數,毫秒級彈性伸縮,高效應對業務峰值。

更低成本:根據函數調用次數、運行時長和節點轉換次數計費,函數不運行時不產生費用,更加節省成

適用場景:

短時運行處理:閑時報表處理、定時日志分析、小程序后端

事件驅動處理:實時圖片處理、實時數據流處理、loT規則/事件處理

顯著波峰波谷:視頻轉碼、視頻直播、熱點事件推送

微服務向Serverless演進,并長期共存

華為云云原生解決方案

華為云長期投入云原生技術與產業,是全球云原生領域領導者

云原生基礎設施:在云原生基礎設施方面,華為云基于擎天架構實現了基于應用SLA來靈活調度算力,根據應用IO的不同,動態分配網絡帶寬,根據應用粒度大小,自動分配不同的存儲。云原生應用與基礎設施不再割裂,而是相互可感知,從而為業務提供更高性價比、資源高效的容器服務。

KubeEdge是華為捐獻給CNCF的第一個開源項目,也是全球首個基于Kubernetes擴展的,提供云邊協同能力的開放式邊緣計算平臺。KuberEdge就是依托Kubernetes的容器編排和調度能力,實現云邊協同、計算下沉、海量設備接入等。

KubeEdge的邊緣相當于把Node節點拉遠,并進行一些優化從而實現邊緣自治; Kubernetes master運行在云端,用戶可以直接通過kubectl命令行在云端管理邊緣節點、設備和應用,使用習慣與Kubernetes原生的完全一致,無需重新適應。邊緣端部署輕量級進程,并支持邊緣節點的離線運行

云原生未來發展趨勢

Kubernetes 的編排對象持擴展

以容器為基礎編排對象逐漸延展至虛擬機、函數等,理論上所有可編程、有API、可抽象成資源的對象,都在成為Kubernetes的編排對象。

應用側圍繞Kubernetes生態加速演

以Kubernetes為核心的云原生技術棧將推廣到更多的應用場景。在大數據領域,Spark和Kubernetes的集成已經非常普遍;機器學習方面,用Kubernetes去編排機器學習的工作流以取得業界的廣泛共識。

Istio、Consul ,Linkerd是Service Mesh領域最受歡迎的三大解決方案。

Mesh化是傳統應用轉型云原生的關鍵路徑

服務治理與業務邏輯解耦：將服務通信及相關管控功能從業務程序中分離并下層到基礎設施層,使其和業務系統完全解耦,使開發人員更加專注于業務本

異構系統的統一治理：通過服務網格技術將主體的服務治理能力下沉到基礎設施,可方便地實現多語言、多協議的統一流量管控、監控等需求。

傳統應用架構中業務和功能耦合度較高,無法充分發揮云的效能,傳統應用中用于治理服務的中間件服務通常與應用強綁定部署,治理能力被植入每個應用,重復造輪子現象嚴重。

Mesh化加速業務邏輯與非業務邏輯的解耦。將非業務功能從客戶端SDK中分離出來放入獨立進程,利用Pod中容器共享資源的特性,實現用戶無感知的治理接管。服務治理的Mesh化為傳統應用輕量化改造提供了前提,也為云平臺沉淀通用服務治理能力,加速中間件下沉為基礎設施提供了可能。

Serverless將進一步釋放云計算的能力,將安全、可靠、可伸縮等需求交由基礎設施實現,使用戶僅需關注業務邏輯而無需關注具體部署和運行,極大地提高應用開發效率。同時這個方式促進了社會分工協作,云廠商可以進一步通過規模化、集約化實現計算成本大幅優化。

【與云原生的故事】有獎征文火熱進行中：https://bbs.huaweicloud.com/blogs/345260

云原生 云端實踐

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。