雲原生已來，只是分佈不均

做者 | 右京  阿里雲交付專家

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

前言

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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」