作者 | 右京 阿里云交付專家

**導讀：**云原生是什么？相信不同的人有不同的認識和解讀。本文結合大家的各種討論及項目實踐經驗，從交付的角度，分享阿里交付專家對云原生的理解，闡述如何構建云原生應用，云原生有哪些關鍵技術，以及關于云原生落地的思考。

前言

Internet 改變了人們生活、工作、學習和娛樂的方式。技術發展日新月異，云計算市場風起“云”涌，從最初的物理機到虛擬機（裸金屬） ，再到容器（Container），而互聯網架構也從集中式架構到分布式架構 ，再到云原生架構。如今 “云原生” 被企業和開發者奉為一種標準，并被認為是云計算的未來，讓我想到一句話：“未來已來，只是分布不均”。

伴隨著 “云原生” 技術（架構）越來越火，火得一塌糊涂，每個人對它的理解都各不相同，網上和阿里內部關于 Cloud Native 的相關文章和討論也非常多。不過，我發現大家對于云原生的定義、理解及實踐還處于探索階段，還沒有一個非常明確或者頂層設計的標準化定義。

最近參與了一個上云項目，里面用到很多云原生的技術，借此機會結合大家的各種討論，以及項目中的實踐，聊一下個人對于云原生的一些粗淺思考。

追本溯源

在正式討論之前，我們不妨先來看看幾位網紅主播是怎么定義云原生的。

1. Pivotal 的定義

Pivotal 公司是敏捷開發領域的領導者（曾經 Google 也是其客戶），出生名門（EMC、VMware等投資），是標準的富二代。它推出了 Pivotal Cloud Foundry（2011 ~ 2013 PAAS 界網紅） 和 Spring 生態系列框架，也是云原生的先驅者和探路者（開山鼻祖）。云原生具體定義如下圖：

Pivotal 公司的 Matt Stine 于 2013 年首次提出云原生（Cloud Native）的概念。2015 年，云原生推廣時，Matt Stine 在《遷移到云原生架構》的小冊子中定義了符合云原生架構的幾個特征：12 因素應用、微服務架構、自敏捷架構、基于 API 協作、抗脆弱性。到了 2017 年，Matt Stine 改了口風，將云原生架構歸納為：模塊化、可觀測性、可部署性、可測試性、可處理性、可替換性等 6 大特征。而 Pivotal 最新官網對云原生概括為 4 個要點：DevOps、持續交付、微服務、容器。

2. CNCF 的定義

CNCF（Cloud Native Computing Foundation，云原生基金會）相信大家已經非常熟悉。它是由開源基礎設施界的翹楚 Google、RedHat 等公司共同牽頭發起的一個基金會組織，其目的非常明確，就是為了對抗當時大紅大紫的 Docker 公司在容器圈一家獨大的局面，具體情況（有很多故事）不在這邊細說了。CNCF 通過 Kubernetes 項目在開源社區編排領域一騎絕塵，之后就扛起了云原生定義和推廣的大旗，風光無限。云原生具體定義如下：

2015 年 CNCF 摻和進來，最初把云原生定義為：應用容器化、面向微服務、容器編排。到了 2018 年，CNCF 更新了云原生的定義，加入了聲明式 API 和服務網格（2017 年社區新技術，和微服務并列，注意它不是微服務的升級版本），這些技術能夠構建容錯性好，易于管理和便于觀察的松耦合系統。

3. 小結

隨著云原生生態和邊界不斷的擴大，云原生自身的定義一直在變。不同的公司（Pivotal & CNCF）不同的人對它有不同的定義，同一家公司在不同的時間階段定義也不一樣。根據摩爾定律推斷，未來對于云原生的定義還會不斷變化。

針對兩家公司對云原生的定義不一樣的情況，不妨跳出技術界面，我嘗試用組織和立場的角度來分析下兩位網紅提出者：

• Pivotal 定位于 PaaS 層端到端的解決方案及數字化轉型，從文化、流程、方法論、藍圖規劃、軟件開發方式等，都有一套模式，主要用戶是傳統大中型企業 CIO，整體策略是自頂向下；

• CNCF 立足于整個云計算生態和技術創新、變革者，偏重于技術、工具鏈和底層基礎設施，主要用戶是開源社區的開發者、互聯網及新興企業，影響力可想而知，整體策略是自底向上。

結論：Pivotal 是 Cloud Native 概念和方法論的先行者， CNCF 是 Cloud Native 的最佳實踐者。

目前，針對定義唯一讓我感到困惑的是 Pivotal 提 “概念” 把容器技術放進來，CNCF 提 “技術” 把微服務概念放進來，難道這兩項是目前互聯網圈最 “火” 的，為了吸引大眾眼球？歡迎大家在下面留言討論。

我眼中的哈姆萊特（云原生）

1. 思維、概念

互聯網從剛開始誕生發展，到現在的互聯網思維、互聯網+（即 Internet Native ），云計算從誕生到發展至今，需要云原生思維（即 Cloud Native），類比企業發展到一定階段需要價值觀思維（即 Values Native ）。它們是一種抽象的思維模式，所以任何技術的變革和推廣，一定是思想先行，隨后才有具體的產品幫助落地。

上面講了思維方式，再具象點，結合 Pivotal 和 CNCF 對云原生定義及基于我自己的理解：

云原生根據一套方法論（Pivotal）和技術體系（CNCF），在云上構建一套可運行的應用系統。該應用系統會打破傳統的構建方式，充分利用“云”的原生能力，發揮出 “云” 的最大價值，使其具備原生特征，快速為業務賦能。

還是有點抽象，那要怎么理解這一段話，我簡單列一下 4 個要點，即靈魂拷問：

• 充分利用 “云” 的能力，“云” 有什么能力？

• 云上應用打破傳統構建方式，怎么構建？

• 應用具備云原生特征，有什么關鍵特征？

• 云原生技術體系，有什么關鍵技術？

2. “云”有什么能力？

云計算出現與虛擬化技術的發展與成熟密不可分。它是一種新興的 IT 基礎設施交付方式，通過虛擬化技術，對 IT 硬件資源與軟件組件進行了標準化、抽象化和規模化，變成 “產品服務” 和 “賬單”（pay as you go），某種意義上顛覆和重構了 IT 業界的供應鏈。具體提供的服務有 IaaS/PaaS/FaaS/DaaS 幾種形態：

1）IaaS（Infrastructure as a Service）

即 “基礎設施即服務”，一般指云計算所提供的計算、存儲、網絡、安全等基本最底層能力。

2）PaaS（Platform as a Service）

即 “平臺即服務”，通常指基于云底層能力而構建的面向領域或場景的高層服務，如云數據庫、云對象存儲、中間件（緩存、消息隊列、負載均衡、服務網格、容器平臺等）、應用服務等。

3）Serverless

即“無服務器計算架構”，指用戶無須購買或關注基礎設施，即可運行應用程序，按需付費，彈性擴容，也是 PaaS 演進的一種“極端”形態。目前包含 2 種方式：

• 面向應用：1. 開發者只需提供函數，通過事件或 HTTP 請求觸發實現相應的功能，代表有阿里云（函數計算），AWS（Lambda）；2. 開發者只需提供業務應用，無須購買服務器資源，代表有 Google（cloud run），阿里云（Serverless application engine, SAE）；

• 面向資源：載體是容器鏡像，屏蔽環境差異，靈活性好，代表有阿里云（Serverless kubernetes），AWS （Fargate）。

4）DaaS（Data as a Service）

“即數據即服務”，拓展到上層應用，AI 與云服務的結合，產生了很多高價值的服務。比如大數據決策系統、語音\面部識別、深度學習、基于場景的語義理解。這也是未來 “云” 的核心競爭力。

隨著開源和技術的不斷發展，我們可以看到，云廠商提供的產品和能力越來越多，從物理機、虛擬機、容器，到中間件，再到 IT Serverless 架構，每一層都在逐步的被標準化，而且標準化層面越來越高（即附加值也越高），跟業務沒有直接關系且相對通用的技術（比如服務網格）也被標準化并且下沉到基礎設施。技術每被標準化一層，原本低效繁瑣的工作就少一些。另外，應用層面提供 “人工智能” 等新興技術，幫助企業降低探索成本，加快了新技術的驗證和交付，真正賦能業務。

對應用戶則可以像宜家一樣通過搭積木的方式，選擇自己合適的云產品，站在巨人的肩膀上，避免重復造輪，極大提高了軟件與服務構建各環節的效率，加速了各類應用和架構的落地，而 “云” 端可以按需啟用和隨意擴展的彈性資源，能夠為企業節省巨大成本。

3. 原生應用“怎么構建”？

上面提到了 “云” 有很強大的能力，云上應用該如何適應，那么相比傳統應用，新應用從軟件架構的設計，開發，構建，部署，交付，監控及運維等整個應用生命周期各環節都需要被重塑，我從 “問題” 的角度切入講一下：

1）架構怎么設計

好的架構是演進而來的，不是設計出來的，空談架構 “如何設計” 是沒有意義的，架構演進的目的一定是解決某一類問題。我們不妨從 “問題” 的角度出發，來聊一下云原生架構如何設計，如下圖：

• 為了解決單體架構 “復雜度問題”，使用微服務架構；

• 為了解決微服務間 “通訊異常問題”，使用治理框架 + 監控；

• 為了解決微服務架構下大量應用 “部署問題”，使用容器；

• 為了解決容器的 “編排和調度問題”，使用 Kubernetes；

• 為了解決微服務框架的 “侵入性問題”，使用 Service Mesh；

• 為了讓 Service Mesh 有 “更好的底層支撐”，將 Service Mesh 運行在 k8s 上。

從單個微服務應用的角度看，自身的復雜度降低了，在 “強大底層系統” 支撐的情況下監控、治理、部署、調度功能齊全，已經符合云原生架構。但站在整個系統的角度看，復雜度并沒有減少和消失，要實現 “強大底層系統” 付出的成本是非常昂貴（很強的架構和運維能力）的。另外，企業為了實現這些功能所使用的技術棧及中間件體系是封閉的，私有化嚴重，很難滿足所有的業務需求（包括阿里也存在這種情況）。“為了解決項目整體復雜度，選擇上云托管”，將底層系統的復雜度交給云廠商，讓云提供保姆式服務，最終演變為無基礎架構設計，通過 YAML 或 JSON 聲明式代碼，編排底層基礎設施，中間件等資源，即應用要什么，云給我什么，企業最終會走向開放、標準的 “Cloud” 技術體系。

2）應用怎么交付

為了解決應用 “持續交付問題”，我們引入了 Devops。

Devops 理念大家應該比較熟悉了，我理解它是一系列價值觀，原則，方法，實踐及工具的集合，目的是實現快速交付價值且具有持續改進能力，其核心是用于打破研發和運維之間的隔閡、加快軟件交付流程、提高軟件質量。下面貼一張流水線工具平臺，如下圖：

平臺包括：GitHub、Travis、Artifactory、Spinnaker、FIAAS、Kubernetes、Prometheus、Datadog、Sumologic 和 ELK 等組件。

那怎么樣才能算真正落地和踐行 DevOps ，滿足靈魂拷問的幾個問題：

• 方式：開發每次寫完代碼是否可以部署到測試、生產環境，不需要運維幫助？

• 工具：是否有成熟運維工具平臺和監控體系供開發使用，輕松處理線上各種問題、故障和回滾？

• 文化：開發直接為線上?戶的體驗負責，不管是代碼缺陷還是運維故障，自己變更自己背鍋，是否有 owner 精神？

• 交付度量：在部署頻率、變更前置時間、服務恢復時間、變更失敗率等對應指標上能否滿足業界要求？

DevOps 本質上是為運維服務的，運維通過使用新技術和開發一系列自動化工具，讓開發更接近生產環境，負責開發和運維全部過程，保證了自由度和創新性。在監控、故障防控工具，功能開關的配合下，可以在保障用戶體驗和快速交付價值之間找到平衡點。

猜想：對于技術人來說，或許未來真的只會有業務解決方案和業務代碼，更多更迫切的能力需求將會是如何利用好業界已有的豐富的技術產品和云廠商平臺，在面對更加豐富多樣且復雜的業務領域需求時，能夠更加專注于尋求業界解決方案，以更好地將業務和技術連接起來。對于運維來說，云屏蔽了基礎設施的復雜度，從而轉向工具鏈開發的運維中臺和規模化運維，重點關注成本、效率、穩定性，并為應用保駕護航向上發展。

4. 原生應用有什么 “關鍵特征”？

• 彈性伸縮性：根據業務負載自動伸縮，做到秒級擴縮容能力，靈活動態分配或釋放資源，結合彈性計費策略，這是降低用戶費用重要手段之一，對服務而言需要的關鍵技術點就是服務本身的 “輕量級容器化” 和以此為基礎的 “不可變基礎設施” 特征；

• 容錯性：負載均衡，自動限流降級熔斷，異常流量自動調度，故障隔離，宕機自動遷移等；

• 可觀測性：豐富且細粒度的監控（實時指標、鏈路追蹤、日志），秒級監控能力，做到自動化報警，可持久化的提供查詢；

• 發布穩定性：為應對頻繁變更帶來的穩定性風險，需建立無人值守的變更發布系統，具備自動化的灰度、藍綠等發布策略，同時建立變更前中后的監控基線，具備異常變更的熔斷和自動化回滾能力；

• 易于管理：需要從人工運維到自動運維的轉變，具備自動化異常分析診斷能力，無需登錄服務器；

• 極致體驗：包括應用分配/創建/資源申請/環境配置/開發測試/發布/監控報警/排障定位等需要做到通暢與簡單，一站式體驗，避免繁雜的搭積木式操作；

• 彈性計費：支持按量（如流量，存儲量，調用次數，時長等），按天（固定的如年/月/日），預留式，搶占式等多種定價策略，業務可根據實際情況靈活動態切換匹配出一個最優計量模式。

5. 云原生有哪些“關鍵技術”？

1）容器

容器雛形最早出現在 1979 年叫 Chroot Jail ，定義于 2008 年 即 LXC（Linux Container），將 Cgroups 的資源管理能力和 Namespace 的視圖隔離能力組合在一起，實現進程級別的隔離。然而容器最大的創新在于容器鏡像（即集裝箱，Docker “現象級” 開創），它包含了一個應用運行所需的完整環境（整個操作系統的文件系統），具有一致性、輕量級、可移植、語言無關等特性，實現 “一次發布，隨處運行”（開發、測試、生產），使應用的構建、分發和交付完全標準化。它也是 “不可變基礎設施” 的核心基礎。

2）Kubernetes

Kubernetes 是云計算和云原生時代的 Linux。

Kubernetes 是 Google 基于 Borg 開源的容器編排調度系統，讓容器應用進入大規模工業生產。

聲明式的 API 與可擴展（CRD + Controller）的編程接口，先進的設計思想使其在容器編排大戰中（Kubernetes、Swarm、Mesos）處于王者地位，成為容器編排系統的事實標準。

通過采用 Kubernetes 平臺，用戶不必操心資源管理問題，使基礎設施更加標準化，復雜度降低，資源使用率提升。同時 Kubernetes 也簡化了混合云，多云，邊緣云等跨數據中心的部署成本。

3）ServiceMesh

ServiceMesh 核心是業務邏輯與非業務邏輯解耦，實現開發只需關注業務邏輯的偉大目標。將一大堆和業務邏輯無關的客戶端 SDK（如服務發現，路由，負載均衡，限流降級等）從業務應用中剝離出來，放到單獨的 Proxy（Sidecar） 進程中，之后下沉到基礎設施中間件 Mesh（類似 TDDL 到 DRDS 的模式）。針對應用減少了系統框架變更帶來的風險、瘦身后變的干凈和輕量化，加快了應用的啟動速度，使得應用往 Serverless 架構遷移變得輕松。針對 Mesh 可以根據自身需求自行迭代和升級功能，更加利于全局服務治理、灰度發布、監控等。同時，Mesh 邊界可以擴展到 DB Mesh，Cache Mesh、Msg Mesh等，真正做到服務通信的標準化即服務之間通信的 TCP/IP。

4）基礎設施即代碼（IaC）

將基礎設施及其完整的生命周期（創建、銷毀、擴容、替換）以代碼的方式進行描述、通過相應的工具（terraform、ROS、CloudFormation等）編排執行和管理。比如應用用到的所有基礎資源（如：ECS、VPC、RDS、SLB、Redis 等），無需在控制臺不停的切換頁面申請購買，只需定義相應代碼，一鍵創建。這樣做的受益是基礎設施代碼版本化，可 Review，可測試，可追溯，可回滾，一致性、防止配置漂移，方便共享、模板化和規模化，提升了運維整體效率和質量，通過代碼也可以輕松了解基礎設施的全貌。

5）Cloud IDE

云端 IDE 深入研發的整個生命周期，提供了完整的開發、調試、預發、生產環境及CI/CD 發布一體化體驗。云端可提供豐富的代碼庫模板，通過分布式運算提升編譯速度，以 “智能” 方式實現代碼推薦、代碼優化、自動掃描發現 BUG、識別邏輯和系統性風險。可以想像云時代開發模式與本地開發完全不同，擁有更高的研發效率，更快的迭代速度，更完善的質量控制。

云原生落地思考

作為 GTS 交付的一員，身上肩負著企業數字化轉型的重任，怎么樣能夠幫助傳統企業轉型（通過互聯網經驗降維打擊），更好的擁抱云原生，簡單梳理了下云原生的落地路徑，如下圖：

圖中縱坐標為業務敏捷性，云原生業務敏捷性方面的轉型大致包含以下幾步：

• 第一步：上云是基石；

• 第二步：構建 PaaS 平臺。ACK PaaS （阿里容器平臺）為運維人員屏蔽底層資源和運維的復雜度，提供高性能可伸縮的容器應用管理能力，而為開發人員提供了構建應用程序的環境，旨在加快應用開發的速度，實現平臺即服務，使業務敏捷且具有彈性、容錯性、可觀測性；

• 第三步：基于 PaaS 實現 DevOps。PaaS 平臺是通過提高基礎設施的敏捷而加快業務的敏捷，而 DevOps 則是在流程交付上加快業務的敏捷。通過 DevOps（云效）可以實現應用的持續集成、持續交付，加速價值流交付，實現業務的快速迭代；

• 第四步：實現微服務治理。通過對業務進行微服務化改造，將復雜業務分解為小的獨立單元，不同單元之間松耦合、支持獨立部署更新，真正從業務層面提升敏捷性。在微服務的實現上，客戶可以選擇采用阿里 EDAS（支持 SpringCloud、 Dubbo 等），但隨著技術的發展，微服務最好治理的治理方向應該是服務網格ServiceMesh（ASM 兼容 Istio）；

• 第五步：實現微服務高級管理。在微服務之上實現 API 管理、微服務的分布式集成以及微服務的流程自動化。通過 API 管理幫助企業打造多渠道（自營、微信、天貓等）生態，最終實現 API 經濟。通過微服務的分布式集成和流程自動化，企業可實現統一的業務中臺。

圖中橫坐標是業務健壯性，通常建設步驟為：

• 第一步：建設單數據中心。大多數企業級客戶，如金融、電信和能源客戶的業務系統運行在企業數據中心內部的私有云。在數據中心建設初期，通常是單數據中心；

• 第二步：建設多數據中心。隨著業務規模的擴張和重要性的提升，企業通常會建設災備或者雙活數據中心，這樣可以保證當一個數據中心出現整體故障時，業務不會受到影響；

• 第三步：構建混合云。隨著公有云的普及，很多企業級客戶，開始將一些前端業務系統向公有云遷移，或者使用多家云廠商，這樣客戶的 IT 基礎架構最終成為混合云、多云的模式。

“云原生” 看起來極其美好，可一旦深入進去到落地環節發現實際非常復雜，這個復雜體現在概念新、涉及技術面比較廣，也體現在客戶的期望價值差異很大，更體現在客戶對未來的判斷有很多不確定性。在未來的一段時間，我會不斷整理自己的所聞所見、所思所想和實踐中的思考，拿出來和大家分享，和大家探討，這是開頭的第一篇，希望能不斷寫下去，為企業數字化轉型出一份自己的綿薄之力。

寫在最后

“云” 時代必須以全新的思維、概念來看待應用架構和 IT 基礎設施，只有從這個角度理解云原生才能得到正確的答案。未來必然是屬于云原生的，所以，企業變革的絕不僅僅是工具，而是從思想到方法，再到工具的一整套理念。只有這樣，才能更好迎接云時代的到來，發揮云原生的價值。

這是 “開發者” 最好的時代。這是 “云廠商” 最好的時代。這是 “交付人” 最好的時代。

未來已來，只是分布不均。讓我們了解云原生，擁抱云原生，交付云原生。

測一測：你的云原生架構幾分熟？

企業該從什么維度制定云原生架構的落地戰略？云原生時代的企業該如何落地互聯網分布式架構？這些問題都需要企業花費大量時間和成本去探索。鑒于此，越來越多企業希望能夠通過云原生架構成熟度模型以指導數字化轉型實踐，并將之作為衡量轉型成果水平的統一標準，提高轉型效果。

**因此，我們正式發布《云原生架構成熟度模型》并上線測試。**具體內容可點擊鏈接了解詳情：https://jinshuju.net/f/XCU3lN。

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號。”

總結

以上是生活随笔為你收集整理的云原生已来，只是分布不均的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。