作者簡介
Gavin，程式員、軟體架構師、企業架構師，關注智能制造。
本文是專欄《智能制造系統架構》中的文章，其它文章請參閱入坑智能制造系統架構。
什麼是雲原生架構
所謂雲原生架構，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.
雲原生架構的目的是使企業能夠在公有雲，私有雲或者混合雲等動态環境中建構和運作可擴充的應用。代表技術包括容器，服務網格，微服務，不可變基礎設施和聲明式API。這些技術能夠建構容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師們能夠輕松地對系統作出頻繁和可預測的重大變更。
軟體架構的目的一般都是幫助開發團隊将關注點盡可能聚焦在業務代碼的實作上。通常，開發軟體系統，代碼包含三部分内容，即處理業務邏輯的代碼、第三方依賴、處理非功能特性的代碼。這三部分中隻有業務代碼真正産生業務價值，另外兩個部分都隻算附屬物。軟體規模越大、非功能特性要求越複雜，非業務代碼開發量越大，複雜度越高，系統疊代會越來越緩慢，成本業務越來越高。是以，在軟體規模較大、功能複雜的情況下又要保證靈活疊代，就需要将非業務代碼盡可能剝離出來，利用可靠的第三方托管服務來提升開發效率和系統品質。而雲平台提供了豐富的用于處理非功能需求的服務群組件，是以利用雲原生架構充分利用雲平台上的各類資源，可以很好的解決這方面的問題，下面是微軟整理應用雲原生技術的實際案例：
| 公司 | 案例 |
|---|---|
| Netflix | 生産環境中部署 600+個服務。每天部署上百次。 |
| Uber | 生産環境中部署 1000+個服務。每周部署數百次。 |
| 生産環境中部署 3000+個服務。每天部署上千次。 |
雲原生架構必要條件
是以，雲原生架構要解決的問題不是隻簡單的将應用遷移到雲上，而是通過一組架構原則和設計模式，将應用中的非業務代碼部分進行最大化的剝離，進而讓雲設施接管應用中原有的大量非功能特性（如彈性、韌性、安全、 可觀測性、灰階等），使業務不再受非功能性業務中斷困擾的同時，具備輕量、靈活、高度自動化的特點。而為了實作這些，雲原生架構應具備如下條件：微服務架構，不可變基礎設施和托管服務。
微服務架構
雲原生架構的初衷是為了充分利用雲平台的技術資源來減輕應用開發非功能業務需求的負擔，但同時對應用本身架構的影響也很大。傳統的單體應用是無法上面提到的特性的，是以微服務架構是實作雲原生應用的必要條件（再說一次，把應用遷移到雲平台上的虛拟機裡不叫雲原生應用）。而成熟度較高的雲原生的架構設計要求也更多，12-Factor 可以作為雲原生架構的方法論：
- 使用标準化流程自動配置，進而使新的開發者花費最少的學習成本加入這個項目；
- 和作業系統之間盡可能的劃清界限，在各個系統中提供最大的可移植性；
- 适合部署在現代的雲計算平台，進而在伺服器和系統管理方面節省資源；
- 将開發環境和生産環境的差異降至最低，并使用持續傳遞實施靈活開發；
- 可以在工具、架構和開發流程不發生明顯變化的前提下實作擴充；
這套理論适用于任意語言和後端服務（資料庫、消息隊列、緩存等）開發的應用程式。:
| 要素 | 解釋 | |
|---|---|---|
| 1 | 基準代碼 | 一份基準代碼（Codebase），多份部署（deploy）。
|
| 2 | 依賴 | 顯式聲明依賴關系（ dependency ） 通過依賴清單 ，确切地聲明所有依賴項。此外，在運作過程中通過 依賴隔離工具來確定程式不會調用系統中存在但清單中未聲明的依賴項。這一做法會統一應用到生産和開發環境。 |
| 3 | 配置 | 在環境中存儲配置 12-Factor推薦将應用的配置存儲于 環境變量 中（ env vars, env ）。 |
| 4 | 後端服務 | 把後端服務(backing services)當作附加資源 2-Factor 應用不會差別對待本地或第三方服務。 對應用程式而言，兩種都是附加資源，通過一個 url 或是其他存儲在配置中的服務定位/服務證書來擷取資料。 |
| 5 | 建構，釋出，運作 | 嚴格分離建構和運作 基準代碼 轉化為一份部署(非開發環境)需要以下三個階段：
|
| 6 | 程序 | 以一個或多個無狀态程序運作應用 12-Factor 應用的程序必須無狀态且無共享 。 任何需要持久化的資料都要存儲在後端服務内，比如資料庫。 |
| 7 | 端口綁定 | 通過端口綁定(Port binding)來提供服務 網際網路應用有時會運作于伺服器的容器之中。 12-Factor 應用完全自我加載 而不依賴于任何網絡伺服器就可以建立一個面向網絡的服務。網際網路應用通過端口綁定來提供服務 ，并監聽發送至該端口的請求。 |
| 8 | 并發 | 通過程序模型進行擴充 在 12-factor 應用中，程序是一等公民。12-Factor 應用的程序主要借鑒于 unix 守護程序模型 。開發人員可以運用這個模型去設計應用架構，将不同的工作配置設定給不同的 程序類型 。例如，HTTP 請求可以交給 web 程序來處理，而常駐的背景工作則交由 worker 程序負責。 |
| 9 | 易處理 | 快速啟動和優雅終止可最大化健壯性 12-Factor 應用的程序是易處理（disposable）的，意思是說它們可以瞬間開啟或停止。 這有利于快速、彈性的伸縮應用，迅速部署變化的 代碼 或 配置 ，穩健的部署應用。 |
| 10 | 開發環境與線上環境等價 | 盡可能的保持開發，預釋出，線上環境相同 12-Factor 應用想要做到 持續部署 就必須縮小本地與線上差異。 再回頭看上面所描述的三個差異:
|
| 11 | 日志 | 把日志當作事件流 日志應該是事件流的彙總，将所有運作中程序和後端服務的輸出流按照時間順序收集起來。盡管在回溯問題時可能需要看很多行，日志最原始的格式确實是一個事件一行。日志沒有确定開始和結束，但随着應用在運作會持續的增加。 12-factor應用本身從不考慮存儲自己的輸出流。 不應該試圖去寫或者管理日志檔案。相反，每一個運作的程序都會直接的标準輸出（stdout）事件流。開發環境中，開發人員可以通過這些資料流，實時在終端看到應用的活動。 |
| 12 | 管理程序 | 背景管理任務當作一次性程序運作 一次性管理程序應該和正常的 常駐程序 使用同樣的環境。這些管理程序和任何其他的程序一樣使用相同的代碼和配置，基于某個釋出版本運作。背景管理代碼應該随其他應用程式代碼一起釋出，進而避免同步問題。所有程序類型應該使用同樣的依賴隔離技術。12-factor尤其青睐那些提供了REPL shell的語言，因為那會讓運作一次性腳本變得簡單。 |
在文章 Beyond the Twelve-Factor App中， Kevin Hoffman 解釋了 12 factors (written in 2011). 另外基于現在對于雲應用開發的需求又增加了三個要素.
| New Factor | Explanation | |
|---|---|---|
| 13 | API優先 | 萬物皆服務。假設你的代碼将會被一個前端用戶端、網關或者其它服務調用。 |
| 14 | 資源監控 | 確定你的設計包含監控以及領域相關的健康/系統資料。 |
| 15 | 認證/授權 | 從一開始就實作認證。考慮在公有雲環境下可用的RBAC (role-based access control,基于角色的通路控制) |
不可變基礎設施
雲原生架構理想的計算環境是動态的，平台提供的計算資源可以随時快速傳遞，提升、擴充、遷移或者銷毀。并且，整個基礎環境變化過程中都是在無人關注的情況下自動實作的。如何實作呢？在DevOps中提出了一個Pets vs. Cattle （寵物和牲口）的概念。
在過去依賴傳統的高可靠性基礎設施的時代，服務的可靠性依賴于高可靠性的伺服器。是以對待伺服器就像對待寵物一樣，要實時關注服務的狀态并精心維護，在系統故障或需要更新的時候需要通過對伺服器進行修複、配置實作。但這種模式下，基礎設施具有很高的擁有成本，并且初始化，配置的成本也非常高（對于大中型機，甚至重新開機都是一種奢侈）。
而“牲口”模式下，處理就簡單粗暴的多了，如果底層系統故障或者需要更新，直接殺掉然後重新建立一個新的就好了。而雲原生架構下底層基礎資源采用的就是這種“Cattle”的運維模式，即所謂“不可變基礎設施”。不可變基礎設施裡的“不可變”非常類似于程式設計中的“不可變”概念。程式設計中不可變變量（Immutable Variable）就是在完成指派後就不能發生更改，隻能建立新的來整體替換舊的。由于具有這樣的特性這種變量可以在并發環境下安全的使用。對于基礎設施的不可變性，最基本的就是指運作服務的伺服器在完成部署後，就不再進行更改。這一點是通過容器鏡像來實作的，其含義就是應用的基礎設施應該是不可變的，是一個自包含、自描述可以完全在不同環境中遷移的東西。
Cloud Native Computing Foundation (CNCF)定義了如下的雲原生架構模型。
基礎設施層（Infrastructure）代表實際的計算資源，包括實體伺服器或者虛拟機。提供層（Provisioning）實作對主控端的管理，包括安裝作業系統等。
運作時層（Runtime）主要包括容器運作時環境，包含容器運作時接口（CRI），例如Docker。容器網絡接口（CNI）和容器存儲接口（CSI）。
容器編排和管理層（Container orchestration and management）幫助在多主控端上實作大量容器化應用的部署。Cloud Foundry, Mesos, Nomad和Kubernetes都是流行的容器編排工具。
在應用定義層（Application Definition）開發者負責實作雲原生應用的功能，定義應用架構，配置，部署檔案，鏡像倉庫，持續內建/持續傳遞等。
托管服務
托管服務（managed service）以服務的形式提供如網絡、應用、基礎設施以及安全功能，并向使用者提供持續的支援和底層運維。托管服務的好處就是開箱即用，省去了使用者開發相應功能甚至運維的煩惱，一切交給MSP（managed service provider）。并且在雲平台中，服務的傳遞都是采用XaaS，即按需付費的方式，是以計費也很靈活友善。
目前成熟的PaaS雲平台中，都已經提供了相對完善的托管服務清單，如通路控制、資料庫、緩存、權限管理、持續內建等，幫助使用者盡可能将非功能實作都外移到PaaS或SaaS服務中，而更加關注業務代碼的實作。
雲原生架構成熟度模型
如何判斷應用架構是不是雲原生架構？可以參考阿裡的雲原生架構成熟度模型（SESORA）：
綜上所述，雲原生架構在系統規模較大、功能較複雜的情況下，可以最大化的分離非功能需求代碼實作并充分利用雲平台提供的各種資源，但相對的架構要求和複雜度也較高，如何選擇還需要開發團隊和架構師認真權衡。
參考資料
- 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?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&dist_request_id=1328740.26522.16169095587137867&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.control
- https://www.gartner.com/en/information-technology/glossary/msp-management-service-provider
- http://www.uml.org.cn/yunjisuan/202101071.asp