作者 | 潘義文（空易）
來源|阿里巴巴云原生公眾號

起源

1. 云原生（Cloud Native）的由來

云原生的概念最早開始于 2010 年，在當時 Paul Fremantle 的一篇博客中被提及，他一直想用一個詞表達一種架構，這種架構能描述應用程式和中間件在云環境中的良好運行狀態，因此他抽象出了 Cloud Native 必須包含的屬性，只有滿足了這些屬性才能保證良好的運行狀態，當時提出云原生是為了能構建一種符合云計算特性的標準來指導云計算應用的撰寫，

后來到 2013 年 Matt Stine 在推特上迅速推廣云原生概念，并在 2015 年《遷移到云原生架構》一書中定義了符合云原生架構的特征：12 因素、微服務、自服務、基于 API 協作、扛脆弱性，而由于這本書的推廣暢銷，這也成了很多人對云原生的早期印象，同時云原生也被 12 要素變成了一個抽象的概念，Matt Stine 認為在單體架構向 Cloud Native 遷移的程序中，需要文化、組織、技術共同變革， **解讀：**云原生架構本質上也是一種軟體架構，最大的特點是在云環境下運行，也算是微服務的一種延伸，

2. CNCF 基金會成立及云原生概念的演化

2015 年由 Linux 基金會發起了一個 The Cloud Native Computing Foundation（CNCF） 基金組織，CNCF基金會的成立標志著云原生正式進入高速發展軌道，Google、Cisco、Docker 各大廠紛紛加入，并逐步構建出圍繞 Cloud Native 的具體工具，而云原生這個的概念也逐漸變得更具體化，因此，CNCF 基金最初對云原生定義是也是深窄的，當時把云原生定位為容器化封裝+自動化管理+面向微服務：

The CNCF defines “cloud-native” a little more narrowly, to mean using open source software stack to be containerized, where each part of the app is packaged in its own container, dynamically orchestrated so each part is actively scheduled and managed to optimize resource utilization, and microservices-oriented to increase the overall agility and maintainability of applications.

這主要因為 CNCF 基金會在當時的核心拳頭軟體就是 K8s，因此在概念定義上主要是圍繞著容器編排建立起來的生態，其實這也是為什么我們可以看到 CNCF 定義云原生的時候有時感覺就是再說容器生態，

到了 2017 年, 云原生應用提出者之一的 Pivotal 在其官網上將云原生的定義概括為 DevOps、持續交付、微服務、容器四大特征，這也成了很多人對 Cloud Native 的基礎印象，

而到 2018 年，隨著 Service Mesh 的加入，CNCF 對云原生的定義發生了改變，而這也逐漸成為被大家認可的官方定義：

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

總結一下就是：

• 基于容器、服務網格、微服務、不可變基礎設施和宣告式 API 構建的可彈性擴展的應用，

• 基于自動化技術構建具備高容錯性、易管理和便于觀察的松耦合系統，

• 構建一個統一的開源云技術生態，能和云廠商提供的服務解耦，

可以看出，CNCF 在當前定義基礎上加上了服務網格 (service mesh) 和宣告式 API，這為云原生的概念闡述增加了更深一層的意義，也就是建立一個相對中立的開源云生態，這對云原生的生態定位是很重要的，也算 CNCF 最初成立的宗旨之一，打破云巨頭的壟斷，

解讀：概念隨著新的技術發展而演化

• 第一階段：容器化封裝+自動化管理+面向微服務
• 第二階段：DevOps、持續交付、微服務、容器
• 第三階段：DevOps、持續交付、容器、服務網格、微服務、宣告式API

3. 對云原生的解構

對一個詞的解讀，除了看其歷史發展背景，還有一種偏向于語言學的方法解讀，也就是我們常說的從“字面意思”來理解，

Cloud Native，從詞面上拆解其實就是 Cloud 和 Native，也就是云計算和土著的意思——云計算上的原生居民，即天生具備云計算的親和力，

首先從 Cloud 來理解，云可以看作是一種提供穩定計算存盤資源的物件，為了實作這一點，云提供了像虛擬化、彈性擴展、高可用、高容錯性、自恢復等基本屬性，這是云原生作為一種云計算所具備的第一層含義，第二層要從 Native 來看，云原生和在云上跑的傳統應用不同，一些基于公有云搭建的應用是基于傳統的 SOA 架構來搭建的，然后再移植到云上去運行，那么這些應用和云的整合非常低，

為什么低呢？云作為一種分布式架構，其“土著居民”也應該是基于分布式架構設計出來的，而微服務或 Serverless 這種將服務或函式拆分成一個個模塊的松耦合系統，天然具備分布式設計的屬性，這是 Native 的第一種表現，

其次云作為一種 PaaS 服務，這位“土著居民”從出生(設計)到成長(開發)，再到生活(部署)都應該是基于云的理念來實作的，那么就需要一套自動化的開發流程 CI/CD 來實作，這是 Native 的第二種表現，

而最后“土著居民”的特點希望做到能夠適應所有云端，都能做到無縫的運行和連接，

解讀：前面三節都是來自《什么是云原生？聊聊云原生的今生》這篇文章中，

關鍵點

下面介紹云原生架構的一些關鍵技術點，涉及內容由微服務、分布式常見架構設計(性能、資料一致性、可擴展性、高可用)、研發流程、DevOps、組織文化等，可以根據目錄選擇性的看看，基本上都是一些介紹，詳細的設計可以查看相關檔案進一步了解，

1. 微服務

Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務架構是以開發一組小型服務的方式來開發一個獨立的應用系統，每個服務都以一個獨立行程的方式運行，每個服務與其他服務使用輕量級（通常是 HTTP API）通信機制，這些服務是圍繞業務功能構建的，可以通過全自動部署機制獨立部署，同時服務會使用最小規模的集中管理（例如 Docker）能力，也可以采用不同的編程語言和資料庫，

1）優勢

• 敏捷開發幫助我們減少浪費、快速反饋，以用戶體驗為目標，

• 持續交付促使我們更快、更可靠、更頻繁地改進軟體；基礎設施即代碼（Infrastructure As Code）幫助我們簡化環境的管理，

2）什么時候開始微服務架構

• 幾乎所有成功的微服務架構都是從一個巨大的單體架構開始的，并且都是由于單體架構太大而被拆分為微服務架構，

• 在所一開始就構建微服務架構的故事中，往往都有人遇到了巨大的麻煩，

3）如何決定微服務架構的拆分粒度

微服務架構中的“微”字，并不代表足夠小，應該解釋為合適，

4）單體架構 VS 微服務架構對比

流行的微服務框架：spring-cloud/dubbo，

2. 敏捷基礎設施及公共基礎服務

敏捷基礎設施及公共基礎服務是微服務架構成敗的關鍵因素之一，能夠簡化業務開發，

1）敏捷基礎設施的目標

• 標準化：所有的基礎設施最好都是標準的，
• 可替換：任意節點都能夠被輕易地創建、銷毀、替換，
• 自動化：所有的操作都通過工具自動化完成，無須人工干預，
• 可視化：當前環境要做到可控，就需要對當前的環境狀況可視，
• 可追溯：所有的配置統一作為代碼進行版本化管理，所有的操作都可以追溯，
• 快速：資源申請及釋放要求秒級完成，以適應彈性伸縮和故障切換的要求，

2）基于公共基礎服務的平臺化

• 平臺化是指利用公共基礎服務提升整體架構能力，

• 公共基礎服務是指與業務無關的、通用的服務，包括監控服務、快取服務、訊息服務、資料庫服務、負載均衡、分布式協調、分布式任務調度等，

3）常見的平臺服務

• 監控告警服務
• 分布式訊息中間件服務
• 分布式快取服務
• 分布式任務調度服務

3. 分布式架構 - 可用性設計

可用性（Availability）是關于系統可以被使用的時間的描述，以丟失的時間為驅動（Be Driven by Lost Time），

可用性公式：A=Uptime /（Uptime+Downtime），其中，Uptime 是可用時間，Downtime 是不可用時間，

1）什么降低了可用性

• 發布

• 故障

• 壓力

• 外部依賴

2）設計階段考慮如下幾個比較重要的方法

• 20/10/5，設計系統的時候，以實際流量的 20 倍來設計；開發系統的時候，以實際流量的 10 倍來開發系統；發布系統的時候，以實際流量的 5 倍來部署，這只是一個通用的原則，可以根據實際情況來確定，不需要嚴格按照倍數來執行，
• Design for failure，預測可能發生的問題，做好預案，

3）容錯設計

如果說錯誤是不可避免或者難以避免的，那么我們應該換一個思路，保證錯誤發生時，我們可以從容應對，

• 消除單點
• 特性開關
• 服務分級
• 降級設計
• 超時重試

4）隔離策略

隔離是為了在系統發生故障時，限制傳播范圍和影響范圍，特別要注意非核心系統的故障對核心系統的影響，

• 執行緒池隔離
• 行程隔離
• 集群隔離
• 用戶隔離
• 租戶隔離
• 邏輯隔離
• 物理隔離
• 混合隔離

5）熔斷器

熔斷器模式（Circuit Breaker Patten）的原理類似于家里的電路熔斷器的原理，當發生短路或者超負荷時，熔斷器能夠主動熔斷電路，以避免災難發生，

Spring Cloud Hystrix 提供了熔斷器、執行緒隔離等一系列服務保護的能力，使用起來非常簡單，引入依賴的 JAR 包，通過簡單的注解即可實作，

6）流控設計

• 限流演算法，限流也就是調節資料流的平均速率，通過限制速率保護自己，常見的演算法有：

  • 固定視窗演算法（fixed window），
  • 漏桶演算法（Leaky Bucket）：漏桶演算法主要目的是控制資料注入網路的速率，平滑網路上的突發流量，
  • 令牌桶演算法（token bucket）：令牌桶控制的是一個時間視窗內通過的資料量，通常我們會以 QPS、TPS 來衡量，

• 流控策略

  • 請求入口處，

  • 業務服務入口處，

  • 公共基礎服務處，

  • 基于 Guava 限流：Guava 是 Google 提供的 Java 擴展類別庫，其中的限流工具類 RateLimiter 采用的就是令牌桶演算法，使用起來非常簡單，

  • 基于 Nginx 限流，

7）容量預估

互聯網公司普遍采用全鏈路壓測的方式，來進一步預估容量，

8）故障演練

• 隨機關閉生產環境中的實體，
• 讓某臺機器的請求或回傳變慢，觀察系統的表現，可以用來測驗上游服務是否有服務降級能力，當然如果回應時間特別長，也就相當于服務不可用，
• 模擬 AZ 故障，中斷一個機房，驗證是否跨可用區部署，業務容災和恢復的能力，
• 查找不符合最佳實踐的實體，并將其關閉，

9）資料遷移

• 邏輯分離，物理不分離，
• 物理分離 ，

4. 分布式架構 - 可擴展設計

• 水平擴展，指用更多的節點支撐更大量的請求，
• 橫向擴展通常是為了提升吞吐量，回應時間一般要求不受吞吐量影響即可，

1）AKF 擴展立方體

2）如何擴展資料庫

• X 軸擴展——主從復制集群
• Y 軸擴展——分庫、垂直分表
• Z 軸擴展——分片（sharding）

5. 分布式架構 - 性能設計

1）性能指標

• 回應時間（Latency），就是發送請求和回傳結果的耗時，
• 吞吐量（Throughput），就是單位時間內的回應次數，
• 負載敏感度，是指回應時間隨時間變化的程度，例如，當用戶增加時，系統回應時間的衰減速度，
• 可伸縮性，是指向系統增加資源對性能的影響，例如，要使吞吐量增加一倍，需要增加多少服務器，

2）如何樹立目標

• 通過快取提升讀性能，

• 通過訊息中間件提升寫性能，

6. 分布式架構 - 一致性設計

1）事務的四大特征

• 原子性（Atomicity），
• 一致性（Consistency）是指通過事務保證資料從一種狀態變化到另一種狀態，
• 隔離性（Isolation）是指事務內的操作不受其他操作影響，當多個事務同時處理同一個資料的時候，多個事務之間是互不影響的，
• 持久性（Durability）是指事務被提交后，應該持久化，永久保存下來，

2）CPA 定理

該定理認為對于一個分布式計算系統來說，不可能同時滿足以下三點：

• 一致性（Consistence）
• 可用性（Availability）
• 磁區容錯性（Partition tolerance）

分布式意味著必須滿足磁區容錯性，也就是 P，因此一般只能是 AP 或 CP，

3）BASE 理論

BASE 理論的核心思想是：如果無法做到強一致性，或者做到強一致性要付出很大的代價，那么應用可以根據自身業務特點，采用適當方式來使系統達到最終一致性，只要對最終用戶沒有影響，或者影響是可接受的即可，

• BA:Basically Available，基本可用，
• S:Soft state，軟狀態，
• E:Eventually consistent，最終一致，

4）Quorum 機制（NWR 模型）

如果多個服務分別向三個節點寫資料，為了保證強一致，就必須要求三個節點全部寫成功才回傳；同步寫三個節點的性能較低，如果換一個思路，一致性并不一定要在寫資料的時候完成，可以在讀的階段再決策，只要每次能讀到最新版本即可，

Quorum 機制就是要滿足公式 W+R>N，式中 N 代表備份個數，W 代表要寫入至少 W 份才認為成功，R 表示至少讀取 R 個備份，

5）租約機制（Lease）

如果現在我們有三個節點，為了實作一致性，要確保有且只有一個是 Leader，另外兩個為 Follower，只有 Leader 是可寫的，Follower 只能讀，管理節點 M 通過心跳判斷各個節點的狀態，用 M 去指定 Leader，一旦 Leader 死掉，就可以重新指定一個 Leader，

6）腦裂問題

• 一種是采用投票機制（Paxos 演算法），
• 一種是采用租約機制——Lease，租約機制的核心就是在一定時間內將權力下放，

7）分布式系統的一致性分類

• 建立多個副本，可以把副本放到不同的物理機、機架、機房、地域，當一個副本失效時，可以讓請求轉到其他副本，
• 對資料進行磁區，復制多個副本解決了讀的性能問題，但是無法解決寫的性能問題，

8）以資料為中心的一致性模型

從資料存盤的角度出發的，包括資料庫、檔案等，

• 嚴格一致性（Strict Consistency）
• 順序一致性（Sequential Consistency）
• 因果一致性（Causal Consistency）

9）以用戶為中心的一致性模型

以下一致性模型適應的場景為不會同時發生更新操作，或者同時發生更新操作時能夠比較容易地化解，因為這里的資料更新默認有一個與之關聯的所有者，此所有者擁有唯一被允許修改資料的權限，可以按照用戶 ID 進行路由，

• 單調讀一致性（Monotonic-read Consistency）
• 單調寫一致性（Monotonic-write Consistency）
• 寫后讀一致性（Read-your-writes Consistency）
• 讀后寫一致性（Writes-follow-reads Consistency）

10）業界常用的一致性模型

• 弱一致性：寫入一個資料 a 成功后，在資料副本上可能讀出來，也可能讀不出來，不能保證每個副本的資料一定是一致的，
• 最終一致性（Eventual Consistency）：寫入一個資料 a 成功后，在其他副本有可能讀不到 a 的最新值，但在某個時間視窗之后保證最終能讀到，
• 強一致性（Strong Consistency）：資料 a 一旦寫入成功，在任意副本任意時刻都能讀到 a 的最新值，

11）如何實作強一致性

• 兩階段提交
• 三階段提交（3PC）

12）如何實作最終一致性

• 重試機制：超時時間，重試的次數，重試的間隔時間，重試間隔時間的衰減度，
• 本地記錄日志，
• 可靠事件模式，
• Saga 事務模型：又叫 Long-running-transaction，核心思想是把一個長事務拆分為多個本地事務來實作，由一個 Process manager 統一協調，
• TCC 事務模型：兩階段提交是依賴于資料庫提供的事務機制，再配合外部的資源協調器來實作分布式事務，TCC（Try Confirm Cancel）事務模型的思想和兩階段提交雖然類似，但是卻把相關的操作從資料庫提到業務中，以此降低資料庫的壓力，并且不需要加鎖，性能也得到了提升，

7. 十二因素

12 因素應用是一系列云原生應用架構的模式集合，這些模式可以用來說明什么樣的應用才是云原生應用，關注速度、安全、通過宣告式配置擴展、可橫向擴展的無狀態/無共享行程以及部署環境的整體松耦合，

在 12 因素的背景下，應用指的是獨立可部署單元，組織中經常把一些互相協作的可部署單元稱作一個應用，

• 基準代碼，一份基準代碼，多份部署，使用 GIT 或者 SVN 管理代碼，并且有明確的版本資訊，
• 依賴，顯示宣告依賴，
• 配置：環境中存盤配置，
• 后端服務：把后端服務當作附加資源，后端服務是指程式運行所需要的通過網路呼叫的各種服務，如資料庫（MySQL、CouchDB）、訊息/佇列系統（RabbitMQ、Beanstalkd）、SMTP 郵件發送服務（Postfix），以及快取系統（Memcached），
• 構建、發布、運行：嚴格分離構建和運行，
• 行程，以一個或多個無狀態行程運行應用，如果存在狀態，應該將狀態外置到后端服務中，例如資料庫、快取等，
• 埠系結，通過埠系結提供服務，應用通過埠系結來提供服務，并監聽發送至該埠的請求，
• 并發，通過行程模型進行擴展，擴展方式有行程和執行緒兩種，行程的方式使擴展性更好，架構更簡單，隔離性更好，執行緒擴展使編程更復雜，但是更節省資源，
• 易處理，快速啟動和優雅終止可最大化健壯性，只有滿足快速啟動和優雅終止，才能使服務更健壯，
• 開發環境與線上環境等價，盡可能保持開發、預發布、線上環境相同，
• 日志，把日志當作事件流，微服務架構中服務數量的爆發需要具備呼叫鏈分析能力，快速定位故障，
• 管理行程，把后臺管理任務當作一次性行程運行，一些工具類在生產環境上的操作可能是一次性的，因此最好把它們放在生產環境中執行，而不是本地，

8. 研發流程

1）為什么選擇 DevOps

能提高交付速度、更新頻率，這兩點是衡量一個公司能力的重要指標，

2）Gartner 提出的 DevOps 模型

文化、技術、程序和人，其中團隊文化才是最難改變的，技術方面包括基礎設施即代碼、全域監控、持續監控，

3）自動化測驗

• 自動化測驗可以代替人工測驗，
• 測驗成了全堆疊工程師的作業，因為不溝通才是最有效率的溝通，

4）Code Review

• 提升代碼易讀性，
• 統一規范、標準，
• 技術交流，提升能力，
• Code Review 原則：以發現問題為目標，團隊開放、透明，整個 Code Review 的程序對事不對人，不設定懲罰，
• 線上線下接合的方式，長期線上，定期線下，

5）流水線

持續交付：降低交付周期，通過自動化工具實作設計、開發、測驗、發布、運維各個階段的重復性作業，通過工具實作標準化、規范化，降低出錯概率，

6）開發人員自服務

對于開發程序來說，少交流、少溝通、少開會就是最高效的，

• 高覆寫率的自動化測驗
• 全面的監控
• 持續交付流水線
• 敏捷基礎設施
• 自動化/智能化運維
• 好的架構
• 全堆疊工程師
• 服務型管理
• 工程師文化
• 信任文化
• 分享文化

7）代碼即設計

• 模糊敏捷研發流程階段性：業務需求太多和技術變化速度太快，

• 整個進化設計需要簡單的架構+持續集成+重構+整個研發流程設計，

9. 團隊文化

團隊文化就好比土壤，要培養什么樣的員工，就要有適合他的土壤，

1）團隊規模導致的問題

• 缺乏信任，由于人數眾多，難于管理，只能通過制度、流程、規范、績效約束，
• 沒有責任感，高層管理者忙著開各種決策會議，
• 部門墻，跨部門協調還不如與第三方合作，
• 不尊重專業人士，當所有的生殺大權都掌握在少數人手中的時候，
• 管理層級太深，管理層級太深導致的問題很多，

2）組織結構 - 康威定律

設計系統的組織，其產生的設計和架構等價于組織間的溝通結構，通俗來講，就是什么樣的團隊結構，就會設計出什么樣的系統架構，如果將團隊拆分為前端、后端、平臺、資料庫，那么系統也會按照前端、后端、平臺、資料庫結構隔離，

• 第一定律：Communication dictates design，即組織溝通方式會通過系統設計呈現，
• 第二定律：There is never enough time to do something right,but there is always enough time to do it over，即時間再多，一件事情也不可能做得完美，但總有時間做完一件事情，
• 第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization，即線型系統和線型組織架構間有潛在的異質同態特性，
• 第四定律：The structures of large systems tend to disintegrate during development,qualitatively more so than with small systems，即大的系統組織總是比小系統更傾向于分解，

3）“溝通漏斗”是指作業中團隊溝通效率下降的一種現象

如果一個人心里想表述事專案標的 100%，當你在眾人面前、在開會的場合用語言表達時，你說出來的只剩下 80%，而進入別人的耳朵時，由于文化水平、知識背景等關系，只留存了 60%，實際上，真正被別人理解了大概只有 40%，等到這些人遵照領悟的 40% 具體行動時，只具備了當初事專案標的 20% 了，三個月后資訊只剩下 5% 了，

4）環境氛圍

• 公開透明的作業環境.
• 學習型組織：讓團隊擁有共同愿景、目標，并持續學習，
• 減少無效的正式匯報，
• 高效的會議：縮小會議范圍，常規會議不應該超過 45 分鐘；限制“意見領袖”的發言時長；會議中不允許開小差；會議中的分歧不應該延伸到會議之外，

10. Serverless

隨著以 Kubernetes 為代表的云原生技術成為云計算的容器界面，Kubernetes 成為云計算的新一代作業系統，面向特定領域的后端云服務 (BaaS) 則是這個作業系統上的服務 API，存盤、資料庫、中間件、大資料、 AI 等領域的大量產品與技術都開始提供全托管的云形態服務，如今越來越多用戶已習慣使用云服務，而不是自己搭建存盤系統、部署資料庫軟體，

當這些 BaaS 云服務日趨完善時，Serverless 因為屏蔽了底層設施的運維復雜度，讓開發人員可以將更多精力用于業務邏輯設計與實作，而逐漸成為云原生主流技術之一，Serverless 計算包含以下特征：

• 全托管的計算服務，客戶只需要撰寫代碼構建應用，無需關注同質化的、負擔繁重的基礎設施開發、運維、安全、高可用等作業，
• 通用性，結合云 BaaS API 的能力，能夠支撐云上所有重要型別的應用，
• 自動的彈性伸縮，讓用戶無需為資源使用提前進行容量規劃，
• 按量計費，讓企業使用成本得有效降低，無需為閑置資源付費，

函式計算 (Function as a Service) 是 Serverless 中最具代表性的產品形態，通過把應用邏輯拆分多個函式，每個函式都通過事件驅動方式觸發執行，例如當物件存盤 (OSS) 中產生的上傳 / 洗掉物件等事件， 能夠自動、可靠地觸發 FaaS 函式處理且每個環節都是彈性和高可用的，客戶能夠快速實作大規模資料的實時并行處理，同樣的，通過訊息中間件和函式計算的集成，客戶可以快速實作大規模訊息的實時處理，

Serverless 不足的地方：

• 成功案例太少
• 很難滿足個性化
• 缺乏行業標準
• 初次訪問性能差
• 缺乏開發除錯工具

11. Service Mesh 技術

Service Mesh 是分布式應用在微服務軟體架構之上發展起來的新技術，旨在將那些微服務間的連接、安全、流量控制和可觀測等通用功能下沉為平臺基礎設施，實作應用與平臺基礎設施的解耦，這個解耦意味著開發者無需關注 微服務相關治理問題而聚焦于業務邏輯本身，提升應用開發效率并加速業務探索和創新，換句話說，因為大量非功能性從業務行程剝離到另外行程中，Service Mesh 以無侵入的方式實作了應用輕量化，下圖展示了 Service Mesh 的 典型架構：

在這張架構圖中，Service A 呼叫 Service B 的所有請求，都被其下的 Proxy(在 Envoy 中是 Sidecar) 截獲， 代理 Service A 完成到 Service B 的服務發現、熔斷、限流等策略，而這些策略的總控是在 Control Plane 上配置，

服務網格的技術發展上資料平面與控制平面間的協議標準化是必然趨勢，控制平面可以認為是注冊中心及管理配置面板；資料平面可以認為是由服務化框架依賴的組件獨立而成的一個行程，資料平面代理業務服務的注冊發現、負載均衡、容錯等能力， 為什么需要 Service Mesh：

• 在微服務架構中，讓開發人員感覺不到微服務之間的通信，
• 當服務數量越來越多，升級微服務框架變得越來越復雜的時候，微服務框架不可能一直不變且沒有 bug，
• Service Mesh 則從業務行程集成客戶端的方式演進為獨立行程的方式，客戶端變成了一個獨立行程，
• 對這個獨立行程升級、運維要比綁在一起強得多，
• 微服務架構更強調去中心化、獨立自治、跨語言，Service Mesh 通過獨立行程的方式進行隔離，低成本實作跨語言，
• 每個服務獨立占用一個容器，將服務、依賴包、作業系統、監控運維所需的代理打包成一個鏡像，這種模式促成了 Service Mesh 的發展，讓 Service Mesh 實作起來更容易，

12. 云原生架構成熟度模型

由于云原生架構包含了 6 個關鍵架構維度(簡寫為 SESORA，Service + Elasticity + Serverless + Observability + Resilience + Automation)，因此我們先定義關鍵維度的成熟度級別：

現狀

容器的標準化使用改變了軟體開發方式，基于云原生的開發能夠幫助我們構建更靈活、更強大的應用，近日，CNCF（云原生計算基金會）就發布了云原生開發現狀的報告解讀，

該報告通過對 17,000 多位軟體開發人員的調查資料，對云原生開發深入分析，希望能夠幫助大家更好地掌握云原生開發生態系統的當前狀況，其要點包括：

• 全球云原生開發人員超過 470 萬，
• 使用 Kubernetes 的開發人員超過 170 萬，
• 使用 Serverless 架構及云函式的開發人員超過 330 萬，
• Kubernetes 用戶更有可能影響購買決策，

1. 市場規模

據估計，全球云原生開發人員數量超過 470 萬，占后端開發的 36%，其中包括 290 萬使用編排的用戶，以及 330 萬使用云函式或 Serverless 架構的開發人員，二者分別占據了后端開發的 22% 和 25%，

該估算資料還考慮了 150 萬同時使用編排和 Serverless 技術的開發人員，

2. 各個國家及地區的情況

全球范圍內云原生技術的使用差異很大，

總的來說，歐洲和北美的容器使用率遠超亞洲，容器的使用已在東歐得到普及，54% 的后端開發人員使用容器，北美和西歐等發達地區的使用率也很高，在北美、西歐和以色列，一半后端開發人員都使用了容器，同時在三個地區內，25%-26% 的后端開發人員采用編排技術來管理這些容器，

大洋洲地區云原生技術的使用情況非常獨特，盡管容器的使用在該地區并沒有其他地區那么普遍，但與全球其他地區相比，Serverless 以及容器編排等技術在大洋洲的普及率最高，

亞洲、中東和非洲地區的開發人員采用容器和云原生技術的速度較慢，中國的各大公司在向云的遷移方面一直滯后，并且云原生技術的使用也呈現同樣的趨勢，隨著阿里巴巴的 CaaS 獲得市場的青睞，相信將來東亞地區會涌現更多云原生開發人員，

3. 云原生開發人員掌握多種基礎架構

云原生開發的靈活性讓各個組織更靈活地操作分布式基礎架構，并按需合理分配作業資源，

與未參與云原生的開發人員相比，云原生開發人員掌握的計算基礎架構確實更多，這些開發人員更加愿意在私有云、公共云、混合云和本地服務器等四種環境中運行代碼，且平均使用了1.8種環境，而未參與云原生開發人員的平均值為1.5，資料顯示，270萬云原生開發人員（58%）在公共云上運行后端代碼，220萬開發人員（47%）選擇了私有云，選擇本地服務器的開發人員為220萬（47%），而選擇混合云的開發人員為170萬（ 36%），

無論是云原生開發人員還是傳統開發人員，選擇在本地服務器上運行代碼的比例都相同，這表明，盡管云原生開發人員已經掌握了云的靈活性，但他們并未放棄本地服務器，

4. 云的使用在各個行業各不相同

雖然開發人員采用了云原生開發策略，但運行這些軟體的計算資源在各個行業往往各不相同，

例如，與本地服務器或私有云相比，軟體公司更傾向于在公共云中運行代碼，在軟體公司作業的云原生開發人員中，近三分之二在公共云中運行代碼，同時該行業一半的開發人員在私有云上運行代碼，

資料分析、商業智能以及硬體領域的開發人員更傾向于在公共云上運行軟體，與其他行業的平均水平相比，這些行業中的云原生開發人員在公共云中運行代碼的概率高 7%，

在涉及敏感資料的行業作業的云原生開發人員更傾向于在本地服務器或私有云上運行代碼，與其他行業相比，金融服務領域的云原生開發人員在本地服務器上運行代碼的比例高 12%，而醫療保健領域的開發人員的比例高 8%，

他們希望通過本地計算，更好地控制敏感資料，

市場營銷、娛樂和房地產領域的云原生開發人員不太可能在本地服務器上運行代碼，這些行業的重點是內容，因此需要輕松快速地訪問，可訪問性和性能對這些領域的成功至關重要，而本地服務器可能無法滿足這些要求，

另外，電信和政府/國防領域的云原生開發人員使用私有云、公共云和本地服務器的比例大致相同，這些開發人員使用公共云的比例相對較低，

未來

“未來的軟體一定是生長于云上的”，這是云原生理念的最核心假設，

1. 容器技術發展趨勢

1）趨勢一：無處不在的計算催生新一代容器實作

隨著互聯網的發展到萬物智聯，5G、AIoT 等新技術的涌現，隨處可見的計算需求已經成為現實，針對不同計算場景，容器運行時會有不同需求，KataContainer、Firecracker、gVisor、Unikernel 等新的容器運行時技術層出不窮，分別解決安全隔離性、執行效率和通用性三個不同維度要求，OCI(Open Container Initiative)標準的出現， 使不同技術采用一致的方式進行容器生命周期管理，進一步促進了容器引擎技術的持續創新，

2）趨勢二：云原生作業系統開始浮現

Kubernetes 已經成為云時代的作業系統，對比 Linux 與 Kubernetes 概念模型，兩者都定義了開放的、標準化的訪問介面：向下封裝資源，向上支撐應用，

它們都提供了對底層計算、存盤、網路、異構計算設備的資源抽象和安全訪問模型，可以根據應用需求進行資源調度和編排，Linux 的計算調度單元是行程，調度范圍限制在一臺計算節點，而 Kubernetes 調度單位是 Pod， 可以在分布式集群中進行資源調度，甚至跨越不同云環境，

過往 Kubernetes 上主要運行著無狀態的 Web 應用，隨著技術演進和社區發展，越來越多有狀態應用和大資料 / AI 應用負載逐漸遷移到 Kubernetes 上，Flink、Spark 等開源社區以及 Cloudera、Databricks 等商業公司都 開始加大對 Kubernetes 的支持力度，

統一技術堆疊提升資源利用率：多種計算負載在 Kubernetes 集群統一調度，可以有效提升資源利用率，

統一技能堆疊降低人力成本：Kubernetes 可以在 IDC、云端、邊緣等不同場景進行統一部署和交付，云原生提 倡的 DevOps 文化和工具集可以有效提升技術迭代速度并降低人力成本，

加速資料服務的云原生化：由于計算存盤分離具備巨大的靈活性和成本優勢，資料服務的云原生化也逐漸成為 趨勢，容器和 Serverless 的彈性可以簡化對計算任務的容量規劃，結合分布式快取加速(比如 Alluxio 或阿里云 Jindofs)和調度優化，大大提升資料計算類和 AI 任務的計算效率，

3）趨勢三：Serverless 容器技術逐漸成為市場主流

Serverless 和容器技術也開始融合得到了快速的發展，通過 Serverless 容器，一方面根本性解決 Kubernetes 自身復雜性問題，讓用戶無需受困于 Kubernetes 集群容量規劃、安全維護、故障診斷等運維作業; 一方面進一步釋放云計算能力，將安全、可用性、可伸縮性等需求下沉到基礎設施實作，

4）趨勢四：動態、混合、分布式的云環境將成為新常態

上云已是大勢所趨，但對于企業而言，有些業務出于對資料主權、安全隱私的考量，會采用混合云架構，一些企業為了滿足安全合規、成本優化、提升地域覆寫性和避免云廠商鎖定等需求，會選擇多個云廠商，混合云 / 多云架構已成為企業上云新常態，Gartner 指出“到 2021，超過 75% 的大中型組織將采用多云或者混合 IT 戰略，”

2. 基于云原生的新一代應用編程界面

Kubenetes 已經成為了云原生的作業系統，而容器成為了作業系統調度的基本單元，同時定義了應用交付的標準，但對于開發者來說，這些還遠沒有深入到應用的架構，改變應用的編程界面，但是這種變革已經在悄然發生了，而且有不斷加速之勢，

• Sidecar 架構徹底改變了應用的運維架構，由于 Sidecar 架構支持在運行時隔離應用容器與其他容器，因此 原本在虛擬機時代和業務行程部署在一起的大量運維及管控工具都被剝離到獨立的容器里進行統一管理，對于應用來說，僅僅是按需宣告使用運維能力，能力實作成為云平臺的職責，

• 應用生命周期全面托管，在容器技識訓礎上，應用進一步描述清晰自身狀態(例如通過 Liveness Probe)， 描述自身的彈性指標以及通過 Service Mesh 和 Serverless 技術將流量托管給云平臺，云平臺能夠全面管理應用的生命周期，包括服務的上下線、版本升級、完善的流量調配、容量管理等保障業務穩定性，

• 用宣告式配置方式使用云服務，云原生應用的核心特點之一就是大量依賴云服務(包括資料庫、快取、訊息等) 構建，以實作快速交付，

• 語言無關的分布式編程框架成為一種服務，為了解決分布式帶來的技術挑戰，傳統中間件需要在客戶端 SDK 撰寫大量的邏輯管理分布式的狀態，我們看到很多專案在把這些內容下沉到 Sidecar 中，并通過語言無關的 API (基于 gRPC/HTTP) 提供給應用，這一變化進一步簡化應用代碼邏輯和應用研發的職責，例如配置系結，身份認證和鑒權都可以在 Sidecar 被統一處理，

綜上，包括生命周期管理、運維管理、配置范圍和擴展和管理、以及語言無關的編程框架，一起構成了嶄新的應用與云之間的編程界面，這一變革的核心邏輯還是把應用中和業務無關的邏輯和職責，剝離到云服務，并在這一程序中形成標準，讓應用開發者能夠在專有云、公有云或者混合云的場景中，能有一致的研發運維體驗，

Sidecar 架構模式

將應用程式的組件部署到單獨的行程或容器中以提供隔離和封裝，這種模式還可以使應用程式由異構組件和技術組成，該模式被命名為 Sidecar，因為它類似于連接到摩托車的輔助車，輔助車被附加到父應用程式并為應用程式提供支持功能，

3. Serverless 發展趨勢

近年來，Serverless 一直在高速發展，呈現出越來越大的影響力，在這樣的趨勢下，主流云服務商也在不斷豐富云產品體系，提供更便捷的開發工具，更高效的應用交付流水線，更完善的可觀測性，更豐富的產品間集成，

1）趨勢一：Serverless 將無處不在

任何足夠復雜的技術方案都可能被實作為全托管、Serverless 化的后端服務，不只是云產品，也包括來自合作 伙伴和三方的服務，云及其生態的能力將通過 API + Serverless 來體現，事實上，對于任何以 API 作為功能透出方式的平臺型產品或組織，Serverless 都將是其平臺戰略中最重要的部分，

2）趨勢二：Serverless 將通過事件驅動的方式連接云及其生態中的一切

通過事件驅動和云服務連接，Serverless 能力也會擴展到整個云生態，

3）趨勢三:Serverless 計算將持續提高計算密度，實作最佳的性能功耗比和性能價格比

虛擬機和容器是兩種取向不同的虛擬化技術，前者安全性強、開銷大，后者則相反，Serverless 計算平臺一方面要求兼得最高的安全性和最小的資源開銷，另一方面要保持對原有程式執行方式的兼容，比如支持任意二進制檔案， 這使得適用于特定語言 VM 的方案不可行，

當 Serverless 計算的規模與影響力變得越來越大，在應用框架、語言、硬體等層面上根據 Serverless 負載特點進行端對端優化就變得非常有意義，新的 Java 虛擬機技術大幅提高了 Java 應用啟動速度，非易失性記憶體幫助實體更快被喚醒，CPU 硬體與作業系統協作對高密環境下性能擾動實作精細隔離，新技術正在創造嶄新的計算環境，

實作最佳性能功耗比和性能價格比的另一個重要方向是支持異構硬體，由于 x86 處理器的性能越來越難以提升，而在 AI 等對算力要求極高的場景，GPU、FPGA、TPU(Tensor Processing Units)等架構處理器的計算效率更具優勢，隨著異構硬體虛擬化、資源池化、異構資源調度和應用框架支持的成熟，異構硬體的算力也能通過 Serverless 的方式釋放，大幅降低企業使用門檻，

4. 參考文獻

• Paul Fremantle’s Blog
• Cloud-Native: What It Is and How It All Started
• The Twelve Factor App
• shikanon’s Blog
• Migrating to Cloud Native Application Architectures
• 遷移到云原生應用架構
• 微軟技術檔案: 云原生的定義
• CNCF 官網
• 什么是云原生？聊聊云原生的今生
• 調查近兩萬程式員，當前云原生開發現狀究竟如何？
• 阿里云云原生架構白皮書