簡介： 雲原生架構本質上也是一種軟體架構，最大的特點是在雲環境下執行，也算是微服務的一種延伸。

起源

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 的方式釋放，大幅降低企業使用門檻。

作者：潘義文（空易）

原文連結

本文為阿里雲原創內容，未經允許不得轉載

&n