前言
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 基礎設施，隻有從這個角度了解雲原生才能得到正确的答案。未來必然是屬于雲原生的，是以，企業變革的絕不僅僅是工具，而是從思想到方法，再到工具的一整套理念。隻有這樣，才能更好迎接雲時代的到來，發揮雲原生的價值。
這是 “開發者” 最好的時代。這是 “雲廠商” 最好的時代。這是 “傳遞人” 最好的時代。
未來已來，隻是分布不均。讓我們了解雲原生，擁抱雲原生，傳遞雲原生。