<code>"IT有得聊”是機械工業出版社旗下IT專業資訊和服務平臺，致力於幫助讀者在廣義的IT領域裡，掌握更專業、實用的知識與技能，快速提升職場競爭力。 點擊藍色微信名可快速關注我們！/<code>
隨著數字經濟的發展和企業數字化轉型的深入，企業業務部門需要越來越快的應用開發，傳統的開發模式和運維模式節奏緩慢，這兩者之間的矛盾越來越突出。為了解決這種矛盾，雲原生概念於2013年首次提出，雲原生計算基金會在2015年成立。2018年雲原生生態不斷壯大，主流雲計算供應商紛紛加入該基金會。業界更是稱2019年為雲原生技術的商業化元年。雲原生架構為傳統雲計算領域的人才和傳統信息系統開發者帶來了新挑戰，對企業IT更是極大的挑戰。
那麼今天來看一看，雲原生究竟是什麼？它為何而生？
雲計算的演化
在雲原生概念之前，可能大家已經熟知虛擬化技術、雲計算方法。虛擬化是將不存在的事物或現象虛擬成存在的事物或現象的方法，在計算機領域則是指軟硬件資源的虛擬化。硬件資源的虛擬化包括計算資源虛擬化、存儲資源虛擬化和網絡資源虛擬化。利用虛擬化技術，可以抽象物理資源為統一的邏輯表示，例如通過VMware的虛擬化技術，所有虛擬服務器都擁有統一的設備型號。利用虛擬化技術，也可以使得虛擬資源不受物理資源的限制，例如一臺物理服務器可以虛擬成多臺服務器，多臺物理服務器也可以虛擬成一臺服務器，從而整合硬件資源，提高資源利用率。虛擬化技術目前做得較好的公司有VMware、Citrix、Microsoft、RedHat和Oracle等公司。虛擬化技術的發展如圖1所示。從1998年VMware引入x86虛擬化技術用於普通PC的虛擬，到2001年發佈ESX實現服務器的虛擬，之後Citrix發佈了Xen；Microsoft發佈了VirtualPC和Hyper-V；RedHat藉助Linux的優勢發佈了KVM；而Oracle則收購了VirtualBox。各大廠商都有了自己的虛擬化技術。
圖1 虛擬化技術的發展
儘管虛擬化技術可以有效地簡化數據中心管理，降低數據中心的運營成本，但是並不能取消為了使用IT系統而進行的數據中心構建、硬件採購、軟件安裝和系統維護等環節，企業仍需要配備較多IT運維人員去從事物理資源的相關準備工作、軟件系統的部署工作。此時人們更希望出現一種能夠對計算、存儲和網絡等資源的按需自動分配、按使用量付費的服務，這就催生了雲計算模式。雲計算藉助虛擬化技術的伸縮性和靈活性，進一步提高了資源利用率，簡化了資源和服務的管理與維護，減少了數據中心的運營成本。根據雲計算服務提供的內容，業界把雲計算分成三層：基礎架構即服務（IaaS）、平臺即服務（PaaS）和軟件即服務（SaaS）。根據雲計算服務提供的來源和服務對象，雲計算分為公有云和私有云。雲計算的發展如圖2所示。2006年Amazon（亞馬遜）開始提供S3存儲和EC2虛擬服務器的雲服務；2009年Heroku提供了第一款PaaS雲服務。2011年誕生了開源的IaaS實現——OpenStack，同年Pivotal開源了PaaS的實現——Cloud Foundry。2014年則誕生了第一款商用函數即服務（FaaS），更加推動了雲服務的深度應用。
圖2 雲計算的發展
在虛擬化計算和雲計算服務蓬勃發展的階段，人們也意識到了虛擬化技術的弊端。虛擬化技術虛擬出來的是一個完整操作系統，它的底層包括宿主機操作系統和虛擬化層，勢必導致虛擬機的性能低於物理機的性能。此外，完整的操作系統所佔用的存儲空間較大，而且啟動一個虛擬機，等同於啟動一個完整操作系統。但是往往在虛擬服務器中可能僅僅是為了運行某一個軟件而已。為此
，LXC（Linux Container）技術和Docker技術開始出現。
它摒棄了啟動完整系統的弊端，在現有操作系統上對任務進行隔離，並實現資源按需分配。它允許多個容器共享一個操作系統內核，容器內存儲的僅僅是與某個應用緊密相關的資源，其空間佔用往往只有幾十到幾百MB。單獨容器化如同虛擬PC一樣會面臨高可用性不足、管理低級等問題。容器技術和編排技術的發展如圖3所示，2014年Google開源了Kubernetes（簡稱K8S），它是一種容器編排工具。容器編排工具將容器生命週期管理能力擴展到部署在大量機器集群上的複雜的多容器工作負載，並且為開發人員和基礎設施團隊提供了一個抽象層來處理大規模的容器化部署。眾多公司加入到了容器編排技術大戰中，但是到了2017年，MESOS和Docker相繼宣佈支持Kubernetes，徹底奠定了Kubernetes在容器編排工具中的地位。
2018年，Kubernetes從雲原生計算基金會中畢業。
圖3 容器技術和編排技術的發展
隨著虛擬化技術、雲計算服務以及容器化技術的發展，越來越多的開發者和IT設施運維人員開始團隊協作，改變過往獨立運作的傳統，開始對現有基礎架構、運維人員的作用、開發團隊的文化以及軟件開發模式進行思考和研究，逐漸形成了雲原生的概念。
什麼是雲原生
雲原生（CloudNative）概念是由Pivotal的Matt Stine在2013年首次提出的。這個概念得到了社區的不斷完善，內容越來越豐富，已經包括了DevOps（Development和Operations的組合）、持續交付（Continuous Delivery，CD）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）和十二要素（The Twelve-Factor App）等幾大主題。這個概念不但包括根據業務能力對企業（高校）進行文化、組織架構的重組與建設，也包括方法論和原則，以及具體的操作工具。採用基於雲原生的技術和管理方法，可以更好地從雲中誕生業務，也可以把業務遷移到不同的雲中，從而享受雲的高效與持續服務的能力。
2015年雲原生計算基金會（CNCF）成立，對雲原生定義進行了修改，認為雲原生需要包含應用容器化、面向微服務架構以及支持容器編排調度等方面的內容。2018年，隨著雲原生生態的壯大，主流雲計算供應商都加入了該基金會，隨之雲原生定義又發生了變化。
雲原生技術增強了公司和機構在現代動態的環境中構建和運行可彈性擴展的應用，這些環境主要是公有云、私有云和混合雲的環境。容器、服務網格、微服務、敏捷基礎結構和聲明性API都是這些方法的例證。這些技術能夠構建可彈性擴展的、可管理的、可觀察的松耦合系統。結合自動化手段，雲原生技術可以使得開發者以最低的成本對系統進行頻繁並可預測的重大變更。雲三層模型與雲原生架構的對比如圖4所示，原先的IaaS層升級為敏捷基礎設施，而PaaS和SaaS層則合併為微服務架構。敏捷基礎設施和微服務都屬於技術範疇的架構，在整個雲原生架構中，也少不了自動化的持續交付和DevOps等管理措施。
圖4 雲原生架構
在傳統的應用系統開發過程中，軟件開發商喜歡聚焦在業務系統，專注於系統如何開發、如何閉源成一個獨立的整體系統。但是隨著開源軟件的盛行，全球合作背景下的分工細化，再加之GitHub的影響力越來越大，一個軟件開發商很難在短時間內處理所有問題。軟件開發商應該充分利用第三方開源或不開源的組件，自己僅僅實現必要的代碼，再借助敏捷基礎架構進行靈活多變的必要集成，從而節省大量人力、物力和時間，更加聚焦業務開發，同時又能利用整體協作快速部署業務。雲原生的意義就在於此，按照雲原生的理念進行頂層架構設計、實施、部署，即可實現快速迭代，投入生產使用。
雲原生主要包括兩部分內容：雲原生基礎架構和雲原生應用。
雲原生基礎架構
雲原生基礎架構是隱藏在抽象背後的由軟件管理並由API進行控制的基礎架構，它的目標是運行應用系統。這也就興起了一種新的管理模式——通過這些特性以可擴展、高效的方式進行基礎設施管理。有用的抽象是具有重要意義的，它可以讓開發者專注於自己的業務而無須瞭解底層、實現底層，更可以避免重複實現底層。
由軟件來管理基礎架構是與雲的一個關鍵區別。軟件控制的基礎架構使得基礎架構能夠擴展，也就實現了資源彈性處理、資源置備和資源可維護。這種軟件管理基礎架構的模式不僅影響了基礎架構的管理和運行，也影響了在其上運行的應用系統，從系統架構到系統開發、部署、運維都有了重大變化。
雲原生基礎架構不僅僅是在公有云上運行基礎架構，也不是在容器中運行應用程序，所以公有云和容器化不是雲原生基礎架構的代名詞。但是雲原生基礎架構可以藉助容器化技術和公有云技術去實現。公有云僅僅是IaaS層的實現，一般的公有云還是要藉助人力去申請、分配。而云原生基礎架構則是用程序代碼自動去申請。容器僅僅是應用程序的一種打包方式，這並不意味著這些應用程序具備自治功能。即使應用程序是通過持續集成和持續交付等DevOps流水線自動構建和部署的，也並不一定就是雲原生基礎架構。
Kubernetes也不能簡單地稱為雲原生基礎架構。Kubernetes的容器編排技術為雲原生基礎架構提供了必要的平臺支撐功能。是否是雲原生基礎架構的關鍵在於是否使用自動化處理的方式。例如在Kubernetes中手工分配物理卷，就不能稱為雲原生基礎架構，因為物理卷是手工分配的。而如果使用動態卷，依靠卷聲明來分配容量，進而分配使用該卷的容器，則滿足了雲原生基礎架構的要求。
雲原生應用對基礎架構的基本要求有：
● 運行時間和隔離。
● 資源分配和調度。
● 環境隔離。
● 服務發現。
● 狀態管理。
● 監測和日誌記錄。
● 度量聚合。
● 調試和追蹤。
雲應用程序肯定會依賴一個或多個服務來提供業務價值。提供一種讓服務在每個環境的基礎上找到彼此的方法是基礎架構的責任。有些應用的服務發現需要調用API來實現，而有些應用則通過DNS或者網絡代理透明地發現。具體的實現方式不重要，重要的是使用服務發現服務。雲原生應用程序和基礎架構協作以發現其相關依賴服務。例如Prometheus抓取監控信息的動作主要在配置文件中描述，但是如果Prometheus監控的目標是動態的，則需要部署人員每次去修改Prometheus配置文件，這是非常麻煩的，而且人工操作易出錯。為此，Prometheus實現了一種服務發現方式，主動感知系統監控目標的變化，自動添加、刪除和更新服務。以下是一個Kubernetes上的服務允許Prometheus自動發現的代碼，其中的prometheus.io/scrape: "true"就是為了讓Prometheus感知到該服務。該服務暴露了HTTP協議訪問，端口為8080，端點為/metrics。
<code>apiVersion: v1kind: Servicemetadata: name: ... annotations: prometheus.io/scrape: 'true' prometheus.io/scheme: http prometheus.io/path: /metrics prometheus.io/port: "8080"/<code>
雲原生應用
雲原生應用程序的關鍵在於提供彈性、敏捷性、可操作性和可觀察性。彈性的概念隱含了允許應用程序失敗而不是試圖阻止程序失敗的意思。敏捷性允許應用快速部署和快速迭代，這就需要引入DevOps文化。可操作性是指從應用程序內部控制應用程序的生命週期，而不是依賴外部進程和監視器。可觀察性是指應用程序需要提供信息以反映應用程序的狀態。目前實現雲原生應用程序所需特性的常用方法有：
● 微服務。
● 健康狀況報告。
● 自動測量數據。
● 彈性。
● 聲明模式而不是響應模式。
微服務
傳統應用程序是以單個實體為目標進行管理和部署的，這也是國內軟件行業常用的開發方式，簡稱為單體應用程序。單體應用程序的好處是顯而易見的，但是它無法解決面向大量互聯網用戶提供服務的併發量問題，且使得開發過程變得臃腫，開發進程變得緩慢，維護也越來越困難。
解決這些問題最好的方法之一就是分解單體應用為眾多小的服務模塊。如圖5所示，這些服務模塊相互獨立，使得開發人員可以獨立維護這些小系統，而且開發和維護過程也變得敏捷。分解成微服務後，各服務的編寫語言也可以自行確定，只需要遵守總體的API優先和通信要求即可。
圖5 微服務架構
微服務更像是UNIX哲學的實踐和改造。UNIX哲學是“程序應該只關注一個目標，並儘可能把它做好。讓程序能夠互相協同工作。”例如Unix命令行上的統計文件數量，通過下面的命令管道就可以把列表和統計兩個命令串聯起來使用。
<code>[root@k8smgmt ~]# ls | wc -l39/<code>
微服務也是如此，服務更專注於其用途，也就是隻應做一件事，並把這件事做好。
但是微服務不能等同於雲原生架構，微服務只是雲原生文化的一種實現。
健康狀況報告
為了能夠由軟件控制一切，應用程序必須提供可供管理軟件監測的度量指標。而一個應用程序的度量指標只有創建應用程序的作者最清楚，因此在應用程序中內置度量指標是最好的設計方式。這要求各應用程序提供必要的端點，供管理軟件訪問以判斷應用程序狀態。例如Kubernetes、ETCD都通過HTTP提供了大量的度量指標。
此外，應用程序應該提供更加豐富且必要的狀態報告。在雲原生架構下，一切皆是代碼，一切皆可由軟件控制。為了可以控制，各應用程序必須提供度量接口讓管理軟件獲知應用程序運行狀態以做出必要的反應，例如應用程序崩潰時，管理程序可做出殺掉當前應用程序實例然後啟動新實例的操作。應用程序的健康狀況只是能夠自動執行應用程序聲明週期的一部分，管理程序還需要知道應用程序是否正在工作。
自動測量數據
自動測量數據是做出決定所必需的信息，這些數據與健康狀況報告的數據是有重疊的，但是它們服務的用途不一樣。健康報告是告知管理程序所轄應用程序的生命週期狀態，而自動測量數據是告知應用程序的業務度量指標。
度量的指標一般稱為服務級別指標（Service Level Indicator，SLI）或關鍵績效指標（KeyPerformance Indicator，KPI）。這些指標是特定於應用程序的數據，讓管理程序監測應用程序的性能在服務級別目標（Service Level Objectives，SLO）內。自動測量數據可以解決以下問題：
● 應用程序每分鐘收到的請求數。
● 是否有任何錯誤。
● 應用程序延遲多久。
● 業務處理需要多長時間。
監測數據經常被抓取或推送到時間序列數據庫（如Prometheus或InfluxDB），然後再由度量指標模型進行處理分析，以便後續提醒或者大屏展示。
有一點需要注意的是，自動測量數據應該用於提醒場景而不是健康監測。在一個動態可自我修復的環境中，管理程序幾乎不關心單個應用程序的生命週期，而更多關心應用程序的SLO，因為若是一個程序崩潰，管理程序可以動態重啟應用程序實例以恢復正常運行狀態。
舉一個例子，在Kubernetes中運行以下命令可以看到coredns重啟過兩次和3次，但是管理程序不關心這個行為，只關心它是否在正常運轉，因為管理程序的SLO就是要正常運轉。
<code>[root@k8smgmt ~]# kubectlget pods -n kube-systemNAME READY STATUS RESTARTS AGEcoredns-8686dcc4fd-6h7gs 1/1 Running 2 16dcoredns-8686dcc4fd-bs7dd 1/1 Running 3 16detcd-k8smgmt.shmtu.edu.cn 1/1 Running 1 16d/<code>
彈性處理故障
由於雲原生應用程序在雲環境中運行，因此它們與基礎架構和支持應用程序的交互方式與傳統應用程序不同。在雲本機應用程序中，與任何內容進行通信的方式都是通過網絡。很多時候，網絡通信是通過RESTful HTTP調用完成的，但也可以通過其他接口實現，例如遠程過程調用（RPC）。
傳統應用程序可以通過消息隊列、共享存儲上的文件或觸發shell命令的本地腳本來自動執行任務。事件發生後，通信方法根據本地服務器上的信息做出反應。例如，如果用戶點擊提交，則運行本地服務器上的提交腳本。
在傳統應用程序中，通信的介質可能是文件或者消息隊列，但是這些方式都是嘗試構建避免失敗的方式，它們在雲原生架構下存在一些問題。例如應用程序把結果寫入到文件，寫完後應用程序崩潰了。此時會出現了一種情況：應用程序崩潰之前，計算結果已經寫入文件中。按照雲原生理念，此時應用程序將重啟，再次執行計算過程，計算結果再次寫到文件中。因此，開發人員應該停止使用反應式通信，開始使用聲明式通信，從而提高應用程序的健壯性，並且減少應用程序的依賴。
聲明式通信
由於雲原生應用程序在雲環境中運行，因此它們與基礎架構和支持應用程序的交互方式與傳統應用程序不同。在雲本機應用程序中，與任何內容進行通信的方式都是通過網絡。很多時候，網絡通信是通過RESTful HTTP調用完成的，但也可以通過其他接口實現，例如遠程過程調用（RPC）。
傳統應用程序可以通過消息隊列、共享存儲上的文件或觸發shell命令的本地腳本來自動執行任務。事件發生後，通信方法根據本地服務器上的信息做出反應。例如，如果用戶點擊提交，則運行本地服務器上的提交腳本。
在傳統應用程序中，通信的介質可能是文件或者消息隊列，但是這些方式都是嘗試構建避免失敗的方式，它們在雲原生架構下存在一些問題。例如應用程序把結果寫入到文件，寫完後應用程序崩潰了。此時會出現了一種情況：應用程序崩潰之前，計算結果已經寫入文件中。按照雲原生理念，此時應用程序將重啟，再次執行計算過程，計算結果再次寫到文件中。因此，開發人員應該停止使用反應式通信，開始使用聲明式通信，從而提高應用程序的健壯性，並且減少應用程序的依賴。
-End-
相關著作推薦：
關鍵字: 原生 服務 Kubernetes
