什么是云原生架構？云原生和應用上云不是一碼事！

什么是云原生架構

所謂云原生架構，Cloud Native Computing Foundation 的定義是這樣的：

?

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.

?

云原生架構的目的是使企業(yè)能夠在公有云，私有云或者混合云等動態(tài)環(huán)境中構建和運行可擴展的應用。代表技術包括容器，服務網(wǎng)格，微服務，不可變基礎設施和聲明式 API。這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結合可靠的自動化手段，云原生技術使工程師們能夠輕松地對系統(tǒng)作出頻繁和可預測的重大變更。

軟件架構的目的一般都是幫助開發(fā)團隊將關注點盡可能聚焦在業(yè)務代碼的實現(xiàn)上。通常，開發(fā)軟件系統(tǒng)，代碼包含三部分內容，即處理業(yè)務邏輯的代碼、第三方依賴、處理非功能特性的代碼。這三部分中只有業(yè)務代碼真正產(chǎn)生業(yè)務價值，另外兩個部分都只算附屬物。軟件規(guī)模越大、非功能特性要求越復雜，非業(yè)務代碼開發(fā)量越大，復雜度越高，系統(tǒng)迭代會越來越緩慢，成本業(yè)務越來越高。所以，在軟件規(guī)模較大、功能復雜的情況下又要保證敏捷迭代，就需要將非業(yè)務代碼盡可能剝離出來，利用可靠的第三方托管服務來提升開發(fā)效率和系統(tǒng)質量。而云平臺提供了豐富的用于處理非功能需求的服務和組件，所以利用云原生架構充分利用云平臺上的各類資源，可以很好的解決這方面的問題，下面是微軟整理應用云原生技術的實際案例：

云原生架構必要條件

所以，云原生架構要解決的問題不是只簡單的將應用遷移到云上，而是通過一組架構原則和設計模式，將應用中的非業(yè)務代碼部分進行最大化的剝離，從而讓云設施接管應用中原有的大量非功能特性（如彈性、韌性、安全、 可觀測性、灰度等），使業(yè)務不再受非功能性業(yè)務中斷困擾的同時，具備輕量、敏捷、高度自動化的特點。而為了實現(xiàn)這些，云原生架構應具備如下條件：微服務架構，不可變基礎設施和托管服務。

微服務架構

云原生架構的初衷是為了充分利用云平臺的技術資源來減輕應用開發(fā)非功能業(yè)務需求的負擔，但同時對應用本身架構的影響也很大。傳統(tǒng)的單體應用是無法上面提到的特性的，所以微服務架構是實現(xiàn)云原生應用的必要條件（再說一次，把應用遷移到云平臺上的虛擬機里不叫云原生應用）。而成熟度較高的云原生的架構設計要求也更多， 12-Factor 可以作為云原生架構的方法論：

• 使用標準化流程自動配置，從而使新的開發(fā)者花費最少的學習成本加入這個項目；
• 和操作系統(tǒng)之間盡可能的劃清界限，在各個系統(tǒng)中提供最大的可移植性；
• 適合部署在現(xiàn)代的云計算平臺，從而在服務器和系統(tǒng)管理方面節(jié)省資源；
• 將開發(fā)環(huán)境和生產(chǎn)環(huán)境的差異降至最低，并使用持續(xù)交付實施敏捷開發(fā)；
• 可以在工具、架構和開發(fā)流程不發(fā)生明顯變化的前提下實現(xiàn)擴展；

這套理論適用于任意語言和后端服務（數(shù)據(jù)庫、消息隊列、緩存等）開發(fā)的應用程序。

THE TWELVE-FACTOR APPLICATION

在文章 Beyond the Twelve-Factor App中， Kevin Hoffman 解釋了 12 factors (written in 2011). 另外基于現(xiàn)在對于云應用開發(fā)的需求又增加了三個要素。

不可變基礎設施

云原生架構理想的計算環(huán)境是動態(tài)的，平臺提供的計算資源可以隨時快速交付，提升、擴展、遷移或者銷毀。并且，整個基礎環(huán)境變化過程中都是在無人關注的情況下自動實現(xiàn)的。如何實現(xiàn)呢？在DevOps中提出了一個Pets vs. Cattle （寵物和牲口）的概念。

在過去依賴傳統(tǒng)的高可靠性基礎設施的時代，服務的可靠性依賴于高可靠性的服務器。因此對待服務器就像對待寵物一樣，要實時關注服務的狀態(tài)并精心維護，在系統(tǒng)故障或需要升級的時候需要通過對服務器進行修復、配置實現(xiàn)。但這種模式下，基礎設施具有很高的擁有成本，并且初始化，配置的成本也非常高（對于大中型機，甚至重啟都是一種奢侈）。

而“牲口”模式下，處理就簡單粗暴的多了，如果底層系統(tǒng)故障或者需要升級，直接殺掉然后重新創(chuàng)建一個新的就好了。而云原生架構下底層基礎資源采用的就是這種“Cattle”的運維模式，即所謂“「不可變基礎設施」”。不可變基礎設施里的“不可變”非常類似于程序設計中的“不可變”概念。程序設計中不可變變量（Immutable Variable）就是在完成賦值后就不能發(fā)生更改，只能創(chuàng)建新的來整體替換舊的。由于具有這樣的特性這種變量可以在并發(fā)環(huán)境下安全的使用。對于基礎設施的不可變性，最基本的就是指運行服務的服務器在完成部署后，就不再進行更改。這一點是通過容器鏡像來實現(xiàn)的，其含義就是應用的基礎設施應該是不可變的，是一個自包含、自描述可以完全在不同環(huán)境中遷移的東西。

Cloud Native Computing Foundation (CNCF)定義了如下的云原生架構模型。

基礎設施層（Infrastructure）代表實際的計算資源，包括物理服務器或者虛擬機。提供層（Provisioning）實現(xiàn)對宿主機的管理，包括安裝操作系統(tǒng)等。

運行時層（Runtime）主要包括容器運行時環(huán)境，包含容器運行時接口（CRI），例如 Docker。容器網(wǎng)絡接口（CNI）和容器存儲接口（CSI）。

容器編排和管理層（Container orchestration and management）幫助在多宿主機上實現(xiàn)大量容器化應用的部署。Cloud Foundry, Mesos, Nomad和Kubernetes都是流行的容器編排工具。

在應用定義層（Application Definition）開發(fā)者負責實現(xiàn)云原生應用的功能，定義應用架構，配置，部署文件，鏡像倉庫，持續(xù)集成/持續(xù)交付等。

托管服務

托管服務（managed service）以服務的形式提供如網(wǎng)絡、應用、基礎設施以及安全功能，并向用戶提供持續(xù)的支持和底層運維。托管服務的好處就是開箱即用，省去了用戶開發(fā)相應功能甚至運維的煩惱，一切交給 MSP（managed service provider）。并且在云平臺中，服務的交付都是采用 XaaS，即按需付費的方式，所以計費也很靈活方便。

目前成熟的 PaaS 云平臺中，都已經(jīng)提供了相對完善的托管服務列表，如訪問控制、數(shù)據(jù)庫、緩存、權限管理、持續(xù)集成等，幫助用戶盡可能將非功能實現(xiàn)都外移到 PaaS 或 SaaS 服務中，而更加關注業(yè)務代碼的實現(xiàn)。

云原生架構成熟度模型

如何判斷應用架構是不是云原生架構？可以參考阿里的云原生架構成熟度模型（SESORA）：

綜上所述，云原生架構在系統(tǒng)規(guī)模較大、功能較復雜的情況下，可以最大化的分離非功能需求代碼實現(xiàn)并充分利用云平臺提供的各種資源，但相對的架構要求和復雜度也較高，如何選擇還需要開發(fā)團隊和架構師認真權衡。

參考資料

• https://github.com/cncf/foundation/blob/master/charter.md
• https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition
• https://www.infoq.com/articles/cloud-native-architecture/
• https://www.infoq.cn/article/NZUG7uR1kdwhrIQ05HMM
• https://www.infoq.cn/article/2017/11/WHAT-SERVICE-MESH-WHY-NEED
• https://blog.csdn.net/alisystemsoftware/article/details/103370388
• https://www.gartner.com/en/information-technology/glossary/msp-management-service-provider
• http://www.uml.org.cn/yunjisuan/202101071.asp