雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
阿里妹導讀：雲原生是什麼？相信不同的人有不同的認識和解讀。本文結合大家的各種討論及項目實踐經驗，從交付的角度，分享阿里交付專家對雲原生的理解，闡述如何構建雲原生應用，雲原生有哪些關鍵技術，以及關於雲原生落地的思考。
前言
Internet 改變了人們生活、工作、學習和娛樂的方式。技術發展日新月異，雲計算市場風起“雲”湧，從最初的物理機到虛擬機（裸金屬） ，再到容器（Container），而互聯網架構也從集中式架構到分佈式架構 ，再到雲原生架構。如今 “雲原生” 被企業和開發者奉爲一種標準，並被認爲是雲計算的未來，讓我想到一句話：“未來已來，只是分佈不均”。
伴隨着 “雲原生” 技術（架構）越來越火，火得一塌糊塗，每個人對它的理解都各不相同，網上和阿里內部關於 Cloud Native 的相關文章和討論也非常多。不過，我發現大家對於雲原生的定義、理解及實踐還處於探索階段，還沒有一個非常明確或者頂層設計的標準化定義。
最近參與了一個上雲項目，裏面用到很多雲原生的技術，藉此機會結合大家的各種討論，以及項目中的實踐，聊一下個人對於雲原生的一些粗淺思考。
追本溯源
在正式討論之前，我們不妨先來看看幾位網紅主播是怎麼定義雲原生的。
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、持續交付、微服務、容器。
CNCF 的定義
CNCF（Cloud Native Computing Foundation，雲原生基金會）相信大家已經非常熟悉。它是由開源基礎設施界的翹楚 Google、RedHat 等公司共同牽頭髮起的一個基金會組織，其目的非常明確，就是爲了對抗當時大紅大紫的 Docker 公司在容器圈一家獨大的局面，具體情況（有很多故事）不在這邊細說了。CNCF 通過 Kubernetes 項目在開源社區編排領域一騎絕塵，之後就扛起了雲原生定義和推廣的大旗，風光無限。雲原生具體定義如下：
2015 年 CNCF 摻和進來，最初把雲原生定義爲：應用容器化、面向微服務、容器編排。到了 2018 年，CNCF 更新了雲原生的定義，加入了聲明式 API 和服務網格（2017 年社區新技術，和微服務並列，注意它不是微服務的升級版本），這些技術能夠構建容錯性好，易於管理和便於觀察的松耦合系統。
小結
隨着雲原生生態和邊界不斷的擴大，雲原生自身的定義一直在變。不同的公司（Pivotal & CNCF）不同的人對它有不同的定義，同一家公司在不同的時間階段定義也不一樣。根據摩爾定律推斷，未來對於雲原生的定義還會不斷變化。
針對兩家公司對雲原生的定義不一樣的情況，不妨跳出技術界面，我嘗試用組織和立場的角度來分析下兩位網紅提出者：
- Pivotal 定位於 PAAS 層端到端的解決方案及數字化轉型，從文化、流程、方法論、藍圖規劃、軟件開發方式等，都有一套模式，主要用戶是傳統大中型企業 CIO，整體策略是自頂向下。
- CNCF 立足於整個雲計算生態和技術創新、變革者，偏重於技術、工具鏈和底層基礎設施，主要用戶是開源社區的開發者、互聯網及新興企業，影響力可想而知，整體策略是自底向上。
結論：Pivotal 是 Cloud Native 概念和方法論的先行者， CNCF 是 Cloud Native 的最佳實踐者。
目前，針對定義唯一讓我感到困惑的是 Pivotal 提 “概念” 把容器技術放進來，CNCF 提 “技術” 把微服務概念放進來，難道這兩項是目前互聯網圈最 “火” 的，爲了吸引大衆眼球？歡迎大家在下面留言討論。
我眼中的哈姆萊特（雲原生）
思維、概念
互聯網從剛開始誕生髮展，到現在的互聯網思維、互聯網+（即 Internet Native ），雲計算從誕生到發展至今，需要雲原生思維（即 Cloud Native），類比企業發展到一定階段需要價值觀思維（即 Values Native ）。它們是一種抽象的思維模式，所以任何技術的變革和推廣，一定是思想先行，隨後纔有具體的產品幫助落地。
上面講了思維方式，再具象點，結合 Pivotal 和 CNCF 對雲原生定義及基於我自己的理解：
雲原生根據一套方法論（Pivotal）和技術體系（CNCF），在雲上構建一套可運行的應用系統。該應用系統會打破傳統的構建方式，充分利用“雲”的原生能力，發揮出 “雲” 的最大價值，使其具備原生特徵，快速爲業務賦能。
還是有點抽象，那要怎麼理解這一段話，我簡單列一下 4 個要點，即靈魂拷問：
- 充分利用 “雲” 的能力，“雲” 有什麼能力？
- 雲上應用打破傳統構建方式，怎麼構建？
- 應用具備雲原生特徵，有什麼關鍵特徵？
- 雲原生技術體系，有什麼關鍵技術？
“雲”有什麼能力
雲計算出現與虛擬化技術的發展與成熟密不可分。它是一種新興的 IT 基礎設施交付方式，通過虛擬化技術，對 IT 硬件資源與軟件組件進行了標準化、抽象化和規模化，變成 “產品服務” 和 “賬單”（pay as you go），某種意義上顛覆和重構了 IT 業界的供應鏈。具體提供的服務有 IaaS/PaaS/FaaS/DaaS 幾種形態：
IaaS（Infrastructure as a Service）
即 “基礎設施即服務”，一般指雲計算所提供的計算、存儲、網絡、安全等基本最底層能力。
PaaS（Platform as a Service）
即 “平臺即服務”，通常指基於雲底層能力而構建的面向領域或場景的高層服務，如雲數據庫、雲對象存儲、中間件（緩存、消息隊列、負載均衡、服務網格、容器平臺等）、應用服務等。
Serverless
即 “無服務器計算架構”，指用戶無須購買或關注基礎設施，即可運行應用程序，按需付費，彈性擴容，也是 PaaS 演進的一種 “極端” 形態。目前包含 3 種方式：
- 面向函數：開發者只需提供函，通過事件或 HTTP 請求觸發實現相應的功能，代表有阿里雲（函數計算），AWS（Lambda）。
- 面向應用：開發者只需提供業務應用，無須購買服務器資源，代表有Google（cloud run），阿里雲（EDAS Serverless）。
- 面向容器：應用的升級版，載體是容器鏡像，屏蔽環境差異，靈活性好，代表有阿里雲（Serverless kubernetes），AWS （Fargate）。
DaaS（Data as a Service）
“即數據即服務”，拓展到上層應用，AI 與雲服務的結合，產生了很多高價值的服務。比如大數據決策系統、語音面部識別、深度學習、基於場景的語義理解。這也是未來 “雲” 的核心競爭力。
隨着開源和技術的不斷髮展，我們可以看到，雲廠商提供的產品和能力越來越多，從物理機、虛擬機、容器，到中間件，再到 IT Serverless 架構，每一層都在逐步的被標準化，而且標準化層面越來越高（即附加值也越高），跟業務沒有直接關係且相對通用的技術（比如服務網格）也被標準化並且下沉到基礎設施。技術每被標準化一層，原本低效繁瑣的工作就少一些。另外，應用層面提供 “人工智能” 等新興技術，幫助企業降低探索成本，加快了新技術的驗證和交付，真正賦能業務。
對應用戶則可以像宜家一樣通過搭積木的方式，選擇自己合適的雲產品，站在巨人的肩膀上，避免重複造輪，極大提高了軟件與服務構建各環節的效率，加速了各類應用和架構的落地，而 “雲” 端可以按需啓用和隨意擴展的彈性資源，能夠爲企業節省巨大成本。
原生應用“怎麼構建”
上面提到了 “雲” 有很強大的能力，雲上應用該如何適應，那麼相比傳統應用，新應用從軟件架構的設計，開發，構建，部署，交付，監控及運維等整個應用生命週期各環節都需要被重塑，我從 “問題” 的角度切入講一下：
架構怎麼設計
好的架構是演進而來的，不是設計出來的，空談架構 “如何設計” 是沒有意義的，架構演進的目的一定是解決某一類問題。我們不妨從 “問題” 的角度出發，來聊一下雲原生架構如何設計，如下圖：
- 爲了解決單體架構 “複雜度問題”，使用微服務架構。
- 爲了解決微服務間 “通訊異常問題”，使用治理框架 + 監控 。
- 爲了解決微服務架構下大量應用 “部署問題”，使用容器。
- 爲了解決容器的 “編排和調度問題”，使用 Kubernetes。
- 爲了解決微服務框架的 “侵入性問題”，使用 Service Mesh。
- 爲了讓 Service Mesh 有 “更好的底層支撐”，將 Service Mesh 運行在 k8s 上。
從單個微服務應用的角度看，自身的複雜度降低了，在 “強大底層系統” 支撐的情況下監控、治理、部署、調度功能齊全，已經符合雲原生架構。但站在整個系統的角度看，複雜度並沒有減少和消失，要實現 “強大底層系統” 付出的成本是非常昂貴（很強的架構和運維能力）的。另外，企業爲了實現這些功能所使用的技術棧及中間件體系是封閉的，私有化嚴重，很難滿足所有的業務需求（包括阿里也存在這種情況）。“爲了解決項目整體複雜度，選擇上雲託管”，將底層系統的複雜度交給雲廠商，讓雲提供保姆式服務，最終演變爲無基礎架構設計，通過 YAML 或 JSON 聲明式代碼，編排底層基礎設施，中間件等資源，即應用要什麼，雲給我什麼，企業最終會走向開放、標準的 “Cloud” 技術體系。
應用怎麼交付
爲了解決應用 “持續交付問題”，我們引入了 Devops。
Devops 理念大家應該比較熟悉了，我理解它是一系列價值觀，原則，方法，實踐及工具的集合，目的是實現快速交付價值且具有持續改進能力，其核心是用於打破研發和運維之間的隔閡、加快軟件交付流程、提高軟件質量。下面貼一張流水線工具平臺，如下圖：
平臺包括：GitHub、Travis、Artifactory、Spinnaker、FIAAS、Kubernetes、Prometheus、Datadog、Sumologic 和 ELK 等組件。
那怎麼樣才能算真正落地和踐行 DevOps ，滿足靈魂拷問的幾個問題：
- 方式：開發每次寫完代碼是否可以部署到測試、生產環境，不需要運維幫助？
- 工具：是否有成熟運維工具平臺和監控體系供開發使用，輕鬆處理線上各種問題、故障和回滾？
- 文化：開發直接爲線上⽤戶的體驗負責，不管是代碼缺陷還是運維故障，自己變更自己背鍋，是否有 owner 精神？
- 交付度量：在部署頻率、變更前置時間、服務恢復時間、變更失敗率等對應指標上能否滿足業界要求？
DevOps 本質上是爲運維服務的，運維通過使用新技術和開發一系列自動化工具，讓開發更接近生產環境，負責開發和運維全部過程，保證了自由度和創新性。在監控、故障防控工具，功能開關的配合下，可以在保障用戶體驗和快速交付價值之間找到平衡點。
猜想：對於技術人來說，或許未來真的只會有業務解決方案和業務代碼，更多更迫切的能力需求將會是如何利用好業界已有的豐富的技術產品和雲廠商平臺，在面對更加豐富多樣且複雜的業務領域需求時，能夠更加專注於尋求業界解決方案，以更好地將業務和技術連接起來。對於運維來說，雲屏蔽了基礎設施的複雜度，從而轉向工具鏈開發的運維中臺和規模化運維，重點關注成本、效率、穩定性，併爲應用保駕護航向上發展。
原生應用有什麼 “關鍵特徵”
- 彈性伸縮性：根據業務負載自動伸縮，做到秒級擴縮容能力，靈活動態分配或釋放資源，結合彈性計費策略，這是降低用戶費用重要手段之一，對服務而言需要的關鍵技術點就是服務本身的 “輕量級容器化” 和以此爲基礎的 “不可變基礎設施” 特徵。
- 容錯性：負載均衡，自動限流降級熔斷，異常流量自動調度，故障隔離，宕機自動遷移等。
- 可觀測性：豐富且細粒度的監控（實時指標、鏈路追蹤、日誌），秒級監控能力，做到自動化報警，可持久化的提供查詢。
- 發佈穩定性：爲應對頻繁變更帶來的穩定性風險，需建立無人值守的變更發佈系統，具備自動化的灰度、藍綠等發佈策略，同時建立變更前中後的監控基線，具備異常變更的熔斷和自動化回滾能力。
- 易於管理：需要從人工運維到自動運維的轉變，具備自動化異常分析診斷能力，無需登錄服務器。
- 極致體驗：包括應用分配/創建/資源申請/環境配置/開發測試/發佈/監控報警/排障定位等需要做到通暢與簡單，一站式體驗，避免繁雜的搭積木式操作。
- 彈性計費：支持按量（如流量，存儲量，調用次數，時長等），按天（固定的如年/月/日），預留式，搶佔式等多種定價策略，業務可根據實際情況靈活動態切換匹配出一個最優計量模式。
雲原生有哪些“關鍵技術”
容器
容器雛形最早出現在 1979 年叫 Chroot Jail ，定義於 2008 年 即 LXC（Linux Container），將 Cgroups 的資源管理能力和 Namespace 的視圖隔離能力組合在一起，實現進程級別的隔離。然而容器最大的創新在於容器鏡像（即集裝箱，Docker “現象級” 開創），它包含了一個應用運行所需的完整環境（整個操作系統的文件系統），具有一致性、輕量級、可移植、語言無關等特性，實現 “一次發佈，隨處運行”（開發、測試、生產），使應用的構建、分發和交付完全標準化。它也是 “不可變基礎設施” 的核心基礎。
Kubernetes
Kubernetes 是雲計算和雲原生時代的 Linux。
Kubernetes 是 Google 基於 Borg 開源的容器編排調度系統，讓容器應用進入大規模工業生產。
聲明式的 API 與可擴展（CRD + Controller）的編程接口，先進的設計思想使其在容器編排大戰中（Kubernetes、Swarm、Mesos）處於王者地位，成爲容器編排系統的事實標準。
通過採用 Kubernetes 平臺，用戶不必操心資源管理問題，使基礎設施更加標準化，複雜度降低，資源使用率提升。同時 Kubernetes 也簡化了混合雲，多雲，邊緣雲等跨數據中心的部署成本。
ServiceMesh
ServiceMesh 核心是業務邏輯與非業務邏輯解耦，實現開發只需關注業務邏輯的偉大目標。將一大堆和業務邏輯無關的客戶端 SDK（如服務發現，路由，負載均衡，限流降級等）從業務應用中剝離出來，放到單獨的 Proxy（Sidecar） 進程中，之後下沉到基礎設施中間件 Mesh（類似 TDDL 到 DRDS 的模式）。針對應用減少了系統框架變更帶來的風險、瘦身後變的乾淨和輕量化，加快了應用的啓動速度，使得應用往 Serverless 架構遷移變得輕鬆。針對 Mesh 可以根據自身需求自行迭代和升級功能，更加利於全局服務治理、灰度發佈、監控等。同時，Mesh 邊界可以擴展到 DB Mesh，Cache Mesh、Msg Mesh等，真正做到服務通信的標準化即服務之間通信的 TCP/IP。
基礎設施即代碼（IaC）
將基礎設施及其完整的生命週期（創建、銷燬、擴容、替換）以代碼的方式進行描述、通過相應的工具（terraform、ROS、CloudFormation等）編排執行和管理。比如應用用到的所有基礎資源（如：ECS、VPC、RDS、SLB、Redis 等），無需在控制檯不停的切換頁面申請購買，只需定義相應代碼，一鍵創建。這樣做的受益是基礎設施代碼版本化，可 Review，可測試，可追溯，可回滾，一致性、防止配置漂移，方便共享、模板化和規模化，提升了運維整體效率和質量，通過代碼也可以輕鬆瞭解基礎設施的全貌。
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://yqh.aliyun.com/live立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK