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

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

前言

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

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

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

追本溯源

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

1. Pivotal 的定義

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

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

2. CNCF 的定義

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

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

3. 小結(jié)

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

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

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

• CNCF 立足于整個云計算生態(tài)和技術(shù)創(chuàng)新、變革者，偏重于技術(shù)、工具鏈和底層基礎設施，主要用戶是開源社區(qū)的開發(fā)者、互聯(lián)網(wǎng)及新興企業(yè)，影響力可想而知，整體策略是自底向上。

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

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

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

1. 思維、概念

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

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

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

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

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

• 云上應用打破傳統(tǒng)構(gòu)建方式，怎么構(gòu)建？

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

• 云原生技術(shù)體系，有什么關鍵技術(shù)？

2. “云”有什么能力？

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

1）IaaS（Infrastructure as a Service）

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

2）PaaS（Platform as a Service）

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

3）Serverless

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

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

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

4）DaaS（Data as a Service）

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

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

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

3. 原生應用“怎么構(gòu)建”？

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

1）架構(gòu)怎么設計

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

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

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

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

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

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

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

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

2）應用怎么交付

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

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

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

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

• 方式：開發(fā)每次寫完代碼是否可以部署到測試、生產(chǎn)環(huán)境，不需要運維幫助？

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 云原生有哪些“關鍵技術(shù)”？

1）容器

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

2）Kubernetes

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

Kubernetes 是 Google 基于 Borg 開源的容器編排調(diào)度系統(tǒng)，讓容器應用進入大規(guī)模工業(yè)生產(chǎn)。

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

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

3）ServiceMesh

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

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

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

5）Cloud IDE

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

云原生落地思考

作為 GTS 交付的一員，身上肩負著企業(yè)數(shù)字化轉(zhuǎn)型的重任，怎么樣能夠幫助傳統(tǒng)企業(yè)轉(zhuǎn)型（通過互聯(lián)網(wǎng)經(jīng)驗降維打擊），更好的擁抱云原生，簡單梳理了下云原生的落地路徑，如下圖：

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

• 第一步：上云是基石；

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

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

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

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

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

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

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

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

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

寫在最后

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

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

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

測一測：你的云原生架構(gòu)幾分熟？

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。