雲原生的應用特性及關鍵技術

雲原生並不是一個新的概念，但因其在數字化轉型中發揮著越來越重要的作用，又被推上了“風口浪尖”。

雲原生是英文Cloud Native的直譯。這意味著雲原生應用是從雲上生長出來，而不是佈置在雲上，更非依賴於資料中心。如果將雲原生理解為基於雲環境、專門為雲特性而設計，未免偏頗。用英文表示是“IN CLOUD”，而不是“ON CLOUD”。儘管上雲是第一步，雲原生也只是雲計算的一部分，但它已顯示出最能發揮雲計算平臺的彈性與分散式佈置的優勢，並將雲計算能力發揮到極致。

如果要追溯雲原生的源頭，從時間軸上，可以回到2006年，亞馬遜正式推出彈性計算雲服務EC2那個時候。但是雲原生的概念則出現在2013年。這一年，Pivotal公司的Matt Stine首次將雲原生定義為一系列雲計算技術和開發管理方法的合集，包括DevOps、持續交付、微服務、敏捷基礎設施和12要素等。似乎只要軟體“上雲”，或者說專門為“雲”設計的軟體應用，都可以稱之為雲原生應用。

從已取得的成果來看，對於企業，雲原生釋放出巨大的生產能力，在降本增效的同時，輕鬆承載幾何量級的業務量與資料流；對於使用者，即使在“雙11”這樣的流量請求高峰，已感覺不到延遲，或者出現所搶購物品不能及時呈現的情況。當然，大型影片直播、3D遊戲的體驗也更為順暢，體驗感提升。伴隨著雲原生的成長，不論是企業，還是使用者，在數字化與智慧化上所獲得的成果都超出預期。

雲原生從1.0到2.0

從企業數字化的升級過程中，可以更清楚地看到雲原生在雲計算中成長的過程。企業數字化最早經歷的是伺服器階段，之後是上雲階段，或者稱為雲化階段。雲上應用的數量迅速增加，導致企業的人力運維能力極為不足，形象的說法是人肉堆砌已經不能解決問題。雲原生由此自然進化而來，雲原生1。0開始，即雲原生的最初階段。所要解決的是企業數字化轉型升級過程中，傳統應用單體架構厚重、煙囪式架構等應用無法高效率成長的問題。

圖1 雲原生 2。0 參考架構

那麼，上雲出現的問題，當然要在雲上解決。而云計算的內生業務能力，就是雲原生，由此生於雲、長於雲、用於雲、信於雲的雲原生進入2。0。生於雲是指雲原生技術、架構和服務都是企業應用的擴充套件；長於雲是指企業應用和業務發展的成長性，推動企業數字化建設、業務智慧升級；用於雲是指所有的業務都以服務為核心，持續專注於解決企業應用升級中的問題；信於雲是指雲上執行值得信賴，安全可信。

概括而言，就是“資源高效、應用敏捷、業務智慧、安全可信”。

具體而言，資源高效的實現，是由多元算力滿足不同應用場景的個性化算力需求；由多雲治理和邊雲協同，構建高效率、高可靠的分散式泛在計算平臺，並構建包括容器、裸機、虛機、函式等多形態統一的計算資源能力；以“應用”為中心構建隨時可呼叫的資源排程和管理平臺，形成企業決策部署透明、感知應用智慧、靈活可控的應用能力。

應用敏捷主要體現在應用迭代的速度日漸加快，關鍵在於開發與運維融為一體，即所謂“立而不破”，新舊業務平滑過渡、無縫對接，任何一次升級都不會影響到原有業務。這是透過 DevSecOps 應用開發模式實現的。

業務智慧已經進入良性提升通道，企業的資料管理與應用能力，因為資料的資產化和資料的價值化，得以迅速放大，資料和AI技術的結合不斷賦能企業應用擴充套件，就如植物得到所有的適宜條件而自然生長，不再需要一次次人為干預決策，智慧升級是完全智慧化的，新的應用技術同樣內生出來。

安全可信度的提高，依賴於雲原生的內生能力。安全服務和安全合規能力也是自帶的，“外來物種”的入侵是被遮蔽掉的，應用在雲上安全構建，業務在雲上安全執行。

以上四點與雲計算資源池化、彈性伸縮、安全可靠的特性一脈相承。

以應用為中心

傳統IT架構是按照業務領域劃分，如開發、IT運營和質量保障等部門是各自獨立的，開發與運營之間雖然進行著合作與溝通，但其間的資訊“鴻溝”是存在的。即使是提供應用支撐的軟體企業，也是如此運作的。難以快速響應使用者需求，甚至人為拖延產品迭代週期，敏捷開發就是要解決這個問題，並將開發與運維完全打通，真正形成以使用者為中心的新業務結構。在此基礎上，為解決開發和運維“資訊對稱”的問題，DevOps應運而生。DevOps集開發、技術運營和質量保障為一體，從而提高開發效率，並縮短迭代週期，最終實現“持續交付”。

所謂“持續交付”，不再是一套解決方案包打天下，僅做售後運維，而是確保持續更新，隨時可以釋出新版本。

雲原生使得新基礎設施之一的雲計算硬體平等特效能很好發揮出來，不論是向下管理的各種異構硬體，還是向上遮蔽底層硬體，都是以應用為中心，而真正消弭了硬體差異性，或者說可以不考慮硬體的不同，無需針對特定硬體部署相應軟體程式。如傳統高效能計算（HPC）專用網路硬體成本高昂、組網規模不可擴充套件、技術演進緩慢，所導致的應用普及化難題，其高效能網路通訊協議被雲原生拓展應用到雲影片、金融交易等更廣泛的領域之後，就得以解決，類似專有裝置變為多用途的基礎裝置，尤其是雲原生推動的應用爆炸式增長，裝置的價格雖然不變，但被多應用快速攤薄。即應用的拓展速度，使得硬體的價格壁壘轟然坍塌。

以容器為例，原在私有云、公有云和混合雲上的核心應用，完全可以跨雲應用，對於雲服務商，業務部署能力增強，對於客戶，業務連續性、降本增效等需求得以暢快滿足。不僅如此，邊緣計算技術將越來越多的應用在邊緣側裝置實現，資料傳輸容量擴大、時延降低，減少了業務損耗。雲原生又適時生長出泛在計算。

同時，雲原生應用數量的快速增加，其對應用服務的流量治理、執行監控、訪問安全以及釋出等能力的訴求不斷提升，管控微服務模式無以為繼，應時蝶變為非侵入式微服務模式，應用是開放與開源的，隨時提供解決方案，客戶需求不再可能被置之不理。

雲原生具體應用特性

雲原生應用本身已具備雲計算基因，許多應用特性具有重合性，如網路訪問、遠端部署、可擴充套件彈性、共享、自主服務、高可用、持續交付等。這些應用是以微服務架構、容器、DevOps等關鍵技術為支撐的。

彈性

彈性是雲計算的重要特徵，理論上不受資源限制，可以無限佔用和使用資源（當然需要按使用量付費）。

實際上，彈性也應該是一切智慧軟硬體的特性，如容器的重要特性之一也是彈性。對於雲原生，其彈性主要是指彈性使用資源和服務例項彈性擴充套件能力，所要解決的是單例項擴充套件資源達到瓶頸時，配合負載均衡機制實現彈性擴充套件。

雲原生的這一特性，使得只有強力企業才可以解決彈性問題的專利，成為所有企業都可以獲得彈效能力的普惠選項。

共享

雲計算的IaaS、PaaS、SaaS，可視為分三種類型。與之對應，就涉及三個層級的共享，即資源共享、平臺共享、與應用共享。

雲原生應用作為SaaS層服務，部署於IaaS或PaaS層。共享體現在一份基準程式碼，可以實現多份部署，這是應用開發的共享，而不是雲應用意義上的共享。雲應用是可以對所有人開放的，並共享雲應用服務。

自治

雲應用部署與位置無關，或者說雲應用部署沒有確定位置，是隨機的，但底層則是透明的。所以雲原生應用的配置檔案、後端服務等是和應用共生的，是一體的兩面，完全具備自管理自治理能力。

微服務設計架構同樣遵循自治原則。因此，微服務總是與雲原生相伴生。這和雲的分散式中心特性高度相關。好處是自成一體，自我管理，就像獨立個體的人，必備自我管理能力。

標準交付

雲應用的構建可以在本地或者雲端，但執行一定是在雲端。這樣就要按照一定的標準交付，為的是在雲端的任何位置部署支援標準，不用考慮是什麼環境。

容器就是這樣被打造的標準執行工具，在容器內所有的應用都以標準化映象的方式交付並執行。但容器本身又可以在任何地方執行，只提交映象釋出就可以滿足業務需求頻繁變動、快速迭代、隨時釋出的求。

高可用性

彈性、共享、自治等應用特性保證了高可用。容器可以滿足敏捷啟停、多例項佈置等高可用性，但並不能保證所有應用的全天候穩定。如果需要穩定的高可用性，是否選擇容器，就需要進行新的平衡，或者做出其他選擇。

可監控性

這主要是指可監控審計。使用者可以透過日誌或者介面實時獲取應用執行狀態，以及應用訪問呼叫資料等，作為計量計費、監控和後期審計等的依據。

自助服務

使用者可以根據自己的需求，透過網路訪問，自助使用服務，不需要雲應用管理人員授予許可權。因為雲應用服務目錄簡單明瞭，並附有使用說明，使用者只需找到能滿足自身需求的應用即可。即使不能滿足，也可以隨時提出需求，獲得解決辦法。

可配置

雲應用往往依賴於配置中心，實現不同環境應用的部署執行。比如，開發、測試和生產環境，一些引數的配置往往是不一樣的。因此，不可能把所有配置檔案同應用一起打包，就要由配置中心來統一管理。這樣，還有一個好處，可以實現執行時的引數更新。

敏捷

前面提到敏捷開發可以打通開發與運維。實際上，敏捷更大程度上和輕量、微服務元件化相關，就如個體的人，小了輕了，自然輕巧敏捷。從這個角度說，雲原生的敏捷特性只是一個方面，高度相關於整體架構，如技術架構、組織架構等。所以說，敏捷可以在流程、管理或體驗中被感覺到。敏捷甚至被視為基礎設施，由Kubernetes驅動。

Kubernetes可以很方便地拉取一套基礎設施，滿足使用者開發，測試、釋出等需求。

雲原生關鍵技術

雲原生具體應用是由微服務、容器、DevOps、服務網路、不可變基礎、宣告式API等關鍵技術所構建。

容器及容器編排

容器被認為是雲原生應用的基石，微服務容器化被作為雲原生應用的第一步。雲原生程式碼、依賴項等在執行時被打包到容器映象檔案中。映象儲存在映象倉庫。需要時，則將映象轉換為可執行的容器例項。該例項可在裝有容器引擎的任何計算機上執行，並可以按需部署任意數量的容器例項。每個容器雖然可以共享基礎主機作業系統，記憶體和處理器的一部分，但彼此隔離。容器的移植性保證了跨雲應用的一致性。由此，微服務隔離並打包自己的依賴項、更改項，從而不影響整個系統，開發與釋出可以隨時進行。

因為共享底層作業系統和主機資源，容器所佔用空間大大小於虛擬機器，在一臺主機上可以同時執行多個微服務。

有了容器之後，還需要對容器進行管理，這就是容器編排。目前，通行的容器編排排程器是Kubernetes，簡稱K8s。

表1 雲原生應用與傳統應用對比

微服務

業務架構的變化和演進，是和業務越來越複雜一同改變的。演進或變化的目的基本上都是為了突破業務痛點，上一代系統架構被新的一代所代替。

第一代單體架構把所有業務相關聯的元件、庫全部打包成一個執行程式。雖然滿足了業務相互呼叫的需求，但卻增加了系統複雜度，導致系統維護成本過高，區域性修改可能影響全域性。更為困難的是，系統的封閉性，導致即使內部元件也不能共享，更不用說產品能力的共享，結果是開發效率低下，迭代速度被掣肘。

第二代面向服務架構的SOA（Service Oriented Architecture）是一種設計方法，其中包含多個服務，且服務之間透過相互依賴，可提供一系列解決功能。一個服務通常以獨立的形式存在，各個服務之間可以透過網路呼叫。第三代微服務架構是對SOA的升級，業務需求被元件化和服務化，原有的單個業務系統被拆分為多個獨立開發、設計、執行的小應用。這些小應用之間透過服務完成互動和整合，既可以單獨呼叫，也可以多個並用，企業可以根據業務的不同或業務階段的不同，進行合理引入與靈活呼叫。服務與服務之間透過高內聚低耦合的方式互動。

服務網路

服務網路（Service Mesh）被稱為微服務2。0，解決了服務之間的通訊，並解決了微服務1。0的技術門檻高、多語言支援不足、程式碼侵入性強等問題。

在Service Mesh架構中，非業務功能下層到Sidecar，使用者只需要關聯業務邏輯，而不用關聯服務治理等非業務功能。

DevOps

DevOps不是Dev（開發人員）與Ops（運維人員）的簡單相加，而是兩者的全新組合。DevOps強調的是如何透過自動化的工具協作和溝通來完成軟體的生命週期（開發、測試、運維）管理，從而更快速、更頻密地交付更穩定的軟體。

無服務架構

無服務架構由Serverless直譯而來，但Serverless並不意味著沒有伺服器去執行程式碼，只是不再需要管理伺服器，只專注程式碼，其餘部分工作交由提供者處理。

對於開發者來說，Serverless架構可以將伺服器端應用程式分解成多個，執行不同任務。使用Serverless架構可以免除所有運維操作，開發人員可以更加專注於核心業務的開發，實現快速上線和迭代。

不可變基礎

這裡所說的“不可變”類似於程式設計中的“不可變”定義，即不可變變數完成賦值後就不能更改，只能建立新的進行整體替換。這也是快速迭代的設計之一。對於雲原生來說，最基本的要求是伺服器在完成部署後，就不再進行更改。這是因為，不僅基礎設施的初始化及配置成本高昂，而且系統升級、配置修改以及補丁等會產生不可預估的副作用。可變基礎設施還會導致在災難發生時，難以重新構建服務；在服務執行過程中，持續的修改往往產生併發風險。而不可變基礎設施可提升釋出效率，方便快速擴充套件。

宣告式API

宣告式API是與命令式API截然不同的一種程式設計方式。命令式 API可以直接向伺服器發出執行命令：我要做什麼，而宣告式 API更像是一個指導，明示要執行什麼操作：你要做什麼。宣告式API容許系統不斷調整實際狀態，直到與期望狀態相一致。

雲原生是一種構建和執行應用程式的方法，是一套技術體系和方法論。

原文刊載於《中國工業與資訊化》2021年7月刊 作者：孟嶽