![560-260.png](https://ucc.alicdn.com/pic/developer-ecology/d007818afd354e71bec2ed756432c3e4.png)

-[**點選領取《雲原生架構白皮書》**](https://developer.aliyun.com/topic/cn-architecture-paper?spm=a2c6h.12873639.0.0.147c6c7eq9vjWV)-

**導語：** 有幸作為阿里雲MVP提前獲得了阿里云云原生團隊編寫的《雲原生架構白皮書》，希望透過自己對於雲原生的理解為開發者提供一篇觀後感或者是能夠參考的博文。

# 1 雲原生與分散式系統架構的關係

## 1.1 雲原生架構的定義

《雲原生架構白皮書》中對於雲原生架構的定義為“基於雲原生技術的一組架構原則和設計模式的集合，旨在將雲應用中的非業務程式碼部分進行最大化的剝離，從而讓雲設施接管應用中原有的大量非功能特性（如彈性、韌性、安全、可觀測性、灰度等），使業務不再有非功能性業務中斷困擾的同時，具備輕量、敏捷、高度自動化的特點。”

## 1.2 分散式系統架構的定義

此處定義參考百度百科為“在一個分散式系統中，一組獨立的計算機展現給使用者的是一個統一的整體，就好像是一個系統似的。系統擁有多種通用的物理和邏輯資源，可以動態的分配任務，分散的物理和邏輯資源透過計算機網路實現資訊交換。系統中存在一個以全域性的方式管理計算機資源的分散式作業系統。通常，對使用者來說，分散式系統只有一個模型或範型。在作業系統之上有一層軟體中介軟體負責實現這個模型。”

## 1.3 雲原生與分散式系統架構的關係

分散式架構的重點在於解決計算力的保障問題以及為了提高計算力並同時確保系統的可靠性、可用性和安全性而產生的諸如彈性伸縮、負載均衡、分散式儲存等問題，其目標是在於構建一個分散式的安全可靠的計算力基礎平臺。通常來說，對於資訊系統的架構方式的進化和改變即是伴隨著接入資料和所提供的業務由少變多的過程，目前為止資訊系統的架構經歷了單機架構、叢集架構、分散式架構、分散式多活資料中心架構幾個階段，同時伴隨著業務系統架構一同演變的還有各種外圍系統和儲存系統，比如關聯式資料庫的分庫分表改造、從本地快取過渡到分散式快取等。

要理清分散式架構和雲原生的關係，先來歸納一下分散式架構與雲之間的關係，雲一般指的是一個提供資源的平臺，雲端計算的本質是按需分配資源和彈性計算，而針對目前資料井噴並隨著物聯網應用的推進仍然接入量在呈指數上升的現狀下，分散式架構是最能夠滿足構建一個合格的雲平臺所應具有特質的架構方式。雲原生應用即專門為在雲平臺部署和執行而設計的應用，採用雲原生的設計模式可以最佳化和改進傳統應用模式，使應用更加適合在雲平臺上執行，因此雲原生髮展的本質需求來自於SAAS層面設計理念的改進，由於SAAS層的設計理念的改進而進一步從北向往南向推動了PAAS層特別是中介軟體的升級從而確保整個雲平臺的架構能夠更好的服務於雲原生架構的改變。

因此，雲原生和分散式架構的升級和迭代是一個滾動的過程，為了更好的發揮雲平臺的特點而有了雲原生的需求和設計模式改變，而在這個過程中雲原生也反過來促進了下層架構的升級。這個迭代的過程充分的反應了網際網路或者說資料時代開發理念的特徵，即滾動而非單向。

## 1.3 《雲原生架構白皮書》章節導讀

透過《雲原生架構白皮書》的第1章和第2章內容可以充分的理解雲原生的本質和雲原生架構的特點，在閱讀這兩章的內容時推薦參考分散式架構的相關書籍，因為雲原生和分散式架構密切相關，但是升級迭代的著力點又有所區別，所以能夠結合在一起進行閱讀是最好的。

# 2 雲原生主要架構原則和技術分析

## 2.1 微服務和小系統服務

微服務架構，從宏觀上來看，無非就是細化了服務拆分過程中的粒度，粒度越細，業務耦合越小，容錯性就越好，並且後期擴充套件也會越容易。但是顆粒度過細，又會帶來另外一些麻煩比如提升了維護成本、影響排查問題時的效率、業務開發人員很難梳理清楚服務之間的依賴關係等。

因此《雲原生架構白皮書》在微服務相關章節中又提到了小系統服務的概念，即是一個顆粒度的中間狀態，其實核心就是一個服務拆分顆粒度的問題，白皮書中的第3章中有專門章節對於雲原生微服務特別是微服務設計過程中的約束做了詳細介紹，根本目的就是使微服務的發展處於一個受約束的狀態，而不是因為有了微服務的理念就是服務拆分的顆粒度越細越好。

## 2.2 容器技術與雲原生的關係

![1 (2).png](https://ucc.alicdn.com/pic/developer-ecology/23804da31e424466952cdeb8c5f32394.png)

從白皮書中提供的對比圖可以清楚的發現，雲原生在程式碼方面，對於程式碼通常所包含的三部分：業務程式碼、三方軟體和處理非功能特性的程式碼進行剝離，最終想實現的理想狀態是把所有非功能性程式碼（即除業務程式碼部分）從SAAS層剝離到PAAS層和IAAS層中去，當然目前還是沒有完全做到。剝離非功能程式碼仍然是一個設計模式理念的變化，而在這個理念的落地過程中容器技術成為了最好的工具。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/17285cc9d7014f1eb9696a17e72ebcde.png)

在白皮書中這張對比圖的基礎上，根據其他一些公開資料能夠更清晰的反映出容器技術應用之後，雲原生架構所產生的變化。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/1cc036e0bf6b416f82fd0fbf93404eba.png)
（單機架構）

注：以上圖片來源於《超大流量分散式系統架構解決方案：人人都是架構師2.0》高翔龍著 電子工業出版社

![4.png](https://ucc.alicdn.com/pic/developer-ecology/e9e8994e02a44c57a0ab4e66a33a91f9.png)
（叢集架構）

注：以上圖片來源於《超大流量分散式系統架構解決方案：人人都是架構師2.0》高翔龍著 電子工業出版社

![5.png](https://ucc.alicdn.com/pic/developer-ecology/189deb4f2bca489e8de3bc2037dbfe27.png)
（服務化架構）

注：以上圖片來源於《超大流量分散式系統架構解決方案：人人都是架構師2.0》高翔龍著 電子工業出版社

在這種架構方式下以被廣泛應用的Kubernetes為例，K8S中的大部分概念如Node（除了叢集控制節點Master外K8S叢集中的其他機器）、Pod（容器）等可以被看作資源物件，幾乎所有資源物件都可以透過K8S提供的kubectl工具執行增、刪、改、查等操作並將其儲存在etcd中持久化儲存，也就是說容器服務包括DOCKER、K8S等的全新設計模式天生就適合於分散式服務架構。當然相比叢集架構來說，在開發運維自動化水平的要求上也自然較高以確保對於容器能夠進行有序而全域性化的管理防止系統出現不可控制的狀態。

## 2.2 《雲原生架構白皮書》章節導讀

白皮書的第3章和第4章主要介紹的就是主要的雲原生技術和阿里雲原生架構設計的內容，其實核心的技術就是容器技術，在這個基礎上包括微服務的理念、Serverless和Service Mesh等才能夠被順利的付諸於實踐，而在容器技術中自動化水平又是一個重中之重，所以白皮書中數次提到的所有過程自動化原則就是能否發揮雲原生技術優勢的核心因素。

# 3 小結：雲原生的未來發展方向

雲原生畢竟是一個很大的概念，理論上所有從設計和開發之始就以部署在雲上的設計理念都能夠稱為雲原生，而微服務則是雲原生在服務維度典型的表現形式，而容器服務即是能夠將微服務成功落地的核心技術。Serverless是一個技術也可以從字面意思理解為未來的發展方向，核心理念仍然是將非業務部分的功能下沉至基礎設施，從這點上來說，理想中的Serverless甚至不必包含目前K8S中的叢集容量規劃、安全維護和故障診斷等功能，將這些集中考慮為雲基礎設施所應該具有的功能，而功能模組只需考慮自身的業務，充分體現出的是輕量，透過事件驅動將輕量的服務和服務間以及輕量服務和雲平臺之間連線起來，整個體系相比叢集化部署來說，與其說是一個系統，不如說是雲基礎設施基礎上各類微服務形成的生態。

#### 作者簡介
朱祺
國際電氣電子工程師協會IEEE高階會員、阿里雲全球MVP

分散式系統架構與雲原生—阿里雲《雲原生架構白皮書》導讀

相關文章