作者 | 潘義文（空易）

來源|阿裡巴巴雲原生公衆号

起源

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

雲原生的概念最早開始于 2010 年，

，他一直想用一個詞表達一種架構，這種架構能描述應用程式和中間件在雲環境中的良好運作狀态。是以他抽象出了 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 的方式釋放，大幅降低企業使用門檻。

快速了解雲原生架構起源關鍵點現狀未來

起源