淺析阿裡《雲原生架構白皮書》簡介為什麼需要雲原生雲原生架構主要的雲原生技術阿裡雲原生架構設計阿裡雲原生産品介紹各行業面臨的挑戰&解決方案

簡介

提前看了《雲原生架構白皮書》一直想着要寫點東西，拖延來去

《白皮書》

已經正式釋出2天了，我還遲遲沒有動手。沒動手的一方面原因是我的懶癌症又犯了；另一個原因是《白皮書》覆寫面之廣，基本觸及到雲原生的方方面面，而我在雲原生方面的知識儲備不足以支撐我寫出一篇好文。

雲原生概念雖然在2013年就已被提出，但到目前為止各家對它的了解都些許不同的側重，在這兒阿裡給出了自己對雲原生的了解。看《白皮書》目錄如下圖，全文從7個章節對雲原生架構進行剖析、講解。我也從這7個方面帶大家快速過一遍……

為什麼需要雲原生

這一部分内容比較少，大家可以看下《白皮書》上是怎麼說的。我了解的重點是：科技發展進入了雲的時代，硬體更新，更新速度要求越來越高，「生産關系」已經嚴重制約「生産力」的發展。在雲的時代，需要新的技術架構，來解決人們「生産力」越來越高的要求。于是，雲原生架構應運而生。

雲原生架構

雲原生架構定義

從技術的角度，雲原生架構是基于雲原生技術的一組架構原則和設計模式的集合，旨在将雲應用中的 非業務代碼部分進行最大化的剝離，進而讓雲設施接管應用中原有的大量非功能特性(如彈性、韌性、安全、 可觀測性、灰階等)，使業務不再有非功能性業務中斷困擾的同時，具備輕量、靈活、高度自動化的特點。

利用雲服務和提升軟體傳遞能力，進一步加快軟體開發
讓開發專注于對公司業務最核心的部分，剝離大量非功能性特性
具有高度自動化的軟體傳遞           

雲原生架構原則

1. 服務化原則: 把一個大服務拆分成多個小服務，每個小團隊負責指定服務，各個服務間的更新互不影響，加快業務疊代的速度。
2. 彈性原則: 彈性是指系統的部署規模可以随着業務量的變化自動伸縮。
3. 可觀測原則: 可觀測性是指通過log, trace, metric等手段，讓一次點選背後的多次服務調用的耗時、傳回值和參數都清晰可見。
4. 韌性原則: 韌性是指當軟體所依賴的軟硬體元件出現各種異常時，軟體表現出來的抵禦能力。
5. 所有過程自動化原則: 軟體技術棧的複雜度群組件規模的增加，帶來了軟體傳遞的複雜性，通過使用自動化傳遞工具實作傳遞和運維的自動化。
6. 零信任原則: 預設情況下不應該信任網絡内部和外部的任何人 / 裝置 / 系統，需要基于認證和授權重構訪 問控制的信任基礎。
7. 架構持續演進原則: 現在技術和業務還處在快速變化的時代，雲原生架構本身也需要具有具備持續演進能力。

主要架構模式

1. 服務化架構模式: 服務化架構是雲時代建構雲原生應用的标準架構模式，要求以應用子產品為顆粒度劃分一個軟體，以接口契約(例如 IDL)定義彼此業務關系，以标準協定(HTTP、gRPC 等)確定彼此的互聯互通，結合 DDD(領域模型驅動)、TDD(測試驅動開發)、容器化部署提升每個接口的代碼品質和疊代速度。
2. Mesh 化架構模式: Mesh化架構是把中間件架構(比如 RPC、緩存、異步消息等)從業務程序中分離，讓中間件 SDK與業務代碼進一步解耦。
3. Serverless 模式: Serverless模式更進一步，把使用者從非核心中解放出來，隻需要關心核心業務邏輯。
4. 存儲計算分離模式: 把存儲這種有狀态的操作和計算這種不需要狀态的操作分别用不同的方式處理。
5. 分布式事務模式: 微服務模式提倡每個服務使用私有的資料源，而不是像單體這樣共享資料源。但實際使用場景中總有一些别的因素考量。是以有下面幾個分布式事務模式分别适應不同的場景：XA模式、BASE、TCC模式、SAGA模式、AT 模式。
6. 可觀測架構: 可觀測架構包括 Logging、Tracing、Metrics 三個方面。
7. 事件驅動架構: 本質上是一種應用 / 元件間的內建架構模式。

典型的雲原生架構反模式

1. 龐大的單體應用: 龐大單體應用的最大問題在于缺乏依賴隔離，是以需要考慮通過服務化進行一定的拆分。
2. 單體應用“硬拆”為微服務: 服務的拆分需要适度，過分服務化拆分反而會導緻新架構與組織能力的不比對。
3. 缺乏自動化能力的微服務: 當軟體規模變大後，自動化能力的缺失還會帶來更大的危害。

主要的雲原生技術

容器技術

容器技術背景與價值

Docker 提出了創新的應用打包規範 —— Docker 鏡像，解耦了應用與運作環境，使應用可以在不同計 算環境間一緻、可靠地運作。讓開發所需要的靈活性、開放 性和運維所關注的标準化、自動化達成相對平衡。

容器編排

Kubernetes 已經成為容器編排的事實标準，被廣泛用于自動部署，擴充和管理容器化應用。Kubernetes 提

供了分布式應用管理的核心能力。

Kubernetes 在容器編排中有幾個關鍵設計理念:

1. 聲明式API
2. 可擴充性架構
3. 可移植性           

雲原生微服務

微服務發展背景

在雲原生時代，雲原生微服務體系将充分利用雲資源的高可用和安全體系，讓應用獲得更有保障的彈性、 可用性與安全性。

微服務設計限制

相較于單體應用，微服務架構的架構轉變，在提升開發、部署等環節靈活性的同時，也提升了在運維、監控環節的複雜性。

1 微服務個體限制: 個微服務修改或者釋出時，不應該影響到同一系統裡另一個微服務的業務互動。

2 微服務與微服務之間的橫向關系: 主要微服務的可發現性和可互動性處理服務間的橫向關系。

3 微服務與資料層之間的縱向限制: 在微服務領域，提倡資料存儲隔離原則。對于有狀态的微服務，通常使用計算與存儲分離的方式.

4 全局視角下的微服務分布式限制: 微服務系統設計一開始，就需要考慮全局視角。

雲原生微服務典型架構

第一代微服務架構:

第二代微服務架構:

第三代微服務架構:

第四代微服務架構:

主要微服務技術

Apache Dubbo
Spring Cloud
Eclipse MicroProfile
Tars
SOFAStack
Dapr           

Serverless

1 技術特點

全托管的計算服務
通用性
自動的彈性伸縮
按量計費           

2 常見場景

小程式 /Web/Mobile/API 後端服務
大規模批處理任務
基于事件驅動架構的線上應用和離線資料處理
開發運維自動化           

3 技術關注點

計算資源彈性排程
負載均衡和流控
安全性           

開放應用模型(OAM)

2019 年末，阿裡雲聯合微軟共同釋出了 Open Application Model (OAM) 開源項目，其主要目标是解決從 Kubernetes 項目到“以應用為中心”的平台之間最關鍵環節——标準化應用定義。

Service Mesh 技術

Service Mesh 是分布式應用在微服務軟體架構之上發展起來的新技術，旨在将那些微服務間的連接配接、安全、流 量控制和可觀測等通用功能下沉為平台基礎設施，實作應用與平台基礎設施的解耦。這個解耦意味着開發者無需關注 微服務相關治理問題而聚焦于業務邏輯本身，提升應用開發效率并加速業務探索和創新。

根據 Gartner 研究報告，Istio 有望成為 Service Mesh 的事實标準（話外音:OUC的成立不知道會不會對此事造成影響？），而 Service Mesh 本身也将成為容器服務技術的标配技術元件。

DevOps

1 概述

DevOps 就是為了提高軟體研發效率，快速應對變化，持續傳遞價值的的一系列理念和實踐，其基本思想就是 持續部署(CD)，讓軟體的建構、測試、釋出能夠更加快捷可靠，以盡量縮短系統變更從送出到最後安全部署到生産 系統的時間。

要實施 DevOps，需要遵循一些基本原則，這些原則被簡寫為 CAMS:

文化(Culture) 
自動化(Automation) 
度量(Measurement) 
共享(Sharing)           

運維平台一般都經曆過如下幾個發展階段:手工、腳本、工具、平台、智能化運維等。

現有運維平台雖然很多實作方式，但總體來說分為兩類:

指令式 
聲明式           

阿裡雲原生架構設計

阿裡巴巴獨有的雲原生架構設計方法——ACNA(Alibaba Cloud Native Architecting)。ACNA 是一個 「4+1」 的架構設計流程

「4」 代表架構設計的關鍵視角，包括:

企業戰略視角
業務發展視角
組織能力視角
雲原生技術架構視角           

「1」 表示雲原生架構的架構持續演進閉環。

4 個架構視角和一個閉環的關系如下圖所示:

阿裡雲原生産品介紹

雲原生産品家族

阿裡巴巴雲原生産品家族包括容器産品家族、微服務産品家族、Serverless 産品家族、Service

Mesh 産品家族、消息産品、雲原生資料庫家族、雲原生大資料産品家族等。

1. 容器産品家族:

容器服務 Kubernetes 版(ACK)
Serverless Kubernetes(ASK)
鏡像服務(ACR)           

1. 微服務産品家族

EDAS(企業分布式應用服務)
MSE(微服務引擎)
ACM(應用配置管理)
CSB Micro Gateway(微服務網關服務)
GTS(全局事務服務)
ARMS(應用實時監控服務 ) 
鍊路追蹤(Tracing Analysis)
PTS(Performance Testing Service)           

1. Serverless 産品家族

FC(函數計算)
SAE(Serverless 應用引擎)
Serverless 工作流           

1. Service Mesh 産品家族

托管服務網格(ASM)
AHAS(應用高可用服務)           

1. 消息産品家族

消息隊列 RocketMQ 版
消息隊列 Kafka 版
消息隊列 AMQP 版
微消息隊列 MQTT 版
阿裡雲消息服務 MNS
事件總線 EventBridge           

1. 雲原生資料庫産品家族

PolarDB
PolarDB-X           

1. 雲原生大資料産品家族

雲原生資料倉庫 AnalyticDB MySQL 版
雲原生資料倉庫 AnalyticDB PostgreSQL 版           

各行業面臨的挑戰&解決方案

分别舉了「申通」「完美日記」「特步」「中國聯通」「Timing App」5個例子

雲原生架構未來發展趨勢

容器技術發展趨勢

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

新的容器運作時技術解決了安全隔離性、執行效率和通用性三個不同次元的要求:

KataContainer
Firecracker
gVisor
Unikernel            

趨勢二:雲原生作業系統開始浮現

Linux 的計算排程單元是程序，排程範圍限制在一台計算節點。而 Kubernetes 的排程機關是 Pod， 可以在分布式叢集中進行資源排程，甚至跨越不同的雲環境。

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

通過 Serverless 容器，一方面根本性解決 Kubernetes 自身複雜性問題，讓使用者無需受困于 Kubernetes 叢集容量規劃、安全維護、故障診斷等運維工作; 一方面進一步釋放雲計算能力，将安全、可用性、可伸縮性等需求下沉到基礎設施實作。

趨勢四:動态、混合、分布式的雲環境将成為新常态

對于企業客戶而言，有些業務出于對資料主權、安全隐私的考量，會采用混合雲架構。一些企業為了滿足安全合規、成本優化、提升地域覆寫性和避免雲廠商鎖定等需求，會選擇多個雲廠商。混合雲 / 多雲 架構已成為企業上雲新常态。

基于雲原生的新一代應用程式設計界面

包括生命周期管理、運維管理、配置範圍和擴充和管理、以及語言無關的程式設計架構，一起構成了嶄新的應 用與雲之間的程式設計界面。這一變革的核心邏輯還是把應用中和業務無關的邏輯和職責，剝離到雲服務，并在這個過程 中形成标準，讓應用開發者能夠在專有雲、公有雲、或者混合雲的場景中，都能有一緻的研發運維體驗。

Serverless 發展趨勢

1 趨勢一:Serverless 将無處不在

2 趨勢二:Serverless 将通過事件驅動的方式連接配接雲及其生态中的一切

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