如何了解“雲原生”、“雲原生”的應用價值及關鍵屬性？ | 趨勢解讀

“雲原生”是雲計算中很重要的一個概念，不過對“雲原生”的認識和解讀各有側重。我們覺得雲原生圍繞的是“雲原生應用”這個核心，微服務、容器、DevOps等是實作雲原生的工具和方法論，它們并不等價。澄清概念、厘清認知，是推動“雲原生應用”落地實踐的基礎。

初次聽到“雲原生（Could Native）”的時候也是一頭霧水，對雲原生的十二要素也是不了解。随着項目的推進，對雲計算了解的越來越多，也有了一些自己的體會，再次看雲原生的概念的時候，有了新的認知。也總是看到很多人讨論雲原生，有人說雲原生是建構和運作應用程式的方法；有人說雲原生是一套技術體系和方法論；有人說雲原生應用；有人說雲原生架構；也有人說雲原生就是是持續傳遞、微服務、容器、DevOps等等不一而足。不能說是錯的，也不能說對，不同的人所說的根本不在一個頻道上。我們一向強調從整體上、全面的看待問題，不要有選擇的隻看一點。我們覺得很多人都或多或少的忽略了雲原生的核心實質：Native。

一、 雲原生（Cloud Native）

雲原生概念到底是什麼？

我們覺得對于新技術首先最重要的就是弄清楚它的概念和适用場景。先看Native在英語中的意思：天然的、天生的、本國的、土著的。Cloud Native就是天生的雲，就是天生就具備雲的基因，适合雲環境。就像美國人的native language 是English一樣，不是說美國人改變了國籍加入了其他國家的國籍，其native language就變了，native是一輩子都不會變的。

其核心是雲原生應用，範圍包括雲原生應用生命周期過程的理論、工具和方法。雲原生十二因素是判斷是否是雲原生的基本原則，也是實作雲原生應用的基本理論指導（雖然這些因素并不完全準确）。至于持續傳遞、容器、微服務、DevOps是實作雲原生應用或服務的方法、工具架構和環境支援。不是采用所謂的微服務、容器技術、DevOps就是雲原生了，那隻不過是一種實作方式而已。沒有它們，換其他工具方法同樣可以實作雲原生。即便有了它們，用了它們也不一定就是雲原生。

二、 雲原生所應具備的特性

首先要明白雲原生要具備雲的天然基因，天生就是雲的一部分。雲原生不是為雲而生，而是天生就是雲，生而是雲，是以它具有雲的特性：通過網絡通路、遠端部署執行、可擴充彈性伸縮、共享、按需使用自助服務、高可用、可遠端監控計費審計、标準化傳遞與位置無關等。

雲原生十二因素中，基準代碼是為共享；依賴、配置、後端服務、管理程序是自治自主服務範疇；建構、釋出、運作以及端口綁定是标準化傳遞與位置無關範疇；端口綁定也是遠端通路範疇；程序、并發是擴充彈性要求；易處理是高可用要求；日志是監控計費審計需求，作為事件流則是雲應用與位置無關要求。

雲原生十二因素雖然提出了雲原生應用的大部分特性，但并沒有明确雲原生到底是什麼？讨論雲原生的時候到底該讨論什麼？

三、 讨論雲原生該關注什麼？

我們在讨論雲原生的時候到底該關注什麼？是架構？體系？或是方法？

我們覺得讨論雲原生最重要的是讨論雲原生應用。這是所有讨論雲原生的核心。雲原生架構是雲原生應用的架構，雲原生方法論是實作雲原生應用的方法論，雲原生程式就是雲原生應用，雲原生體系就是建構、釋出、運作雲原生應用的理論、方法、工具、環境、流程、文化等等。最終目的是為了業務應用。雲原生要素中第一條就是“一份基準代碼，多份部署”，也已明确了是雲原生應用。

應用可以是天生具備雲基因，适合部署于雲環境，或者通過改造之後适合雲計算環境，但改造的應用不是雲原生應用，因為它不是天然的雲應用。雲原生應用也不是為了遷雲，傳統應用改造為雲應用才是為了遷雲。這是我們在讨論雲原生的時候需要厘清楚的概念，不能混為一談。概念不清就會越談越亂，越談越糊塗。

四、 雲原生應用

雲原生應用，就是天生具備雲計算基因，以雲計算的思想建構并适用于雲計算環境的應用。它應該具備我們提到的特性：可以通過網絡通路、遠端部署執行、可擴充彈性伸縮、共享、按需使用自主服務、高可用、可遠端監控計費審計、标準化傳遞與位置無關等。有人說輕量、無狀态是不是雲原生的特征？我們并不認為是。輕量、無狀态是容器的特征，容器非常适合部署微服務應用，但微服務應用并不一定是雲原生應用。

應用雲原生思想，可以采用微服務架構、容器、DevOps等技術建構輕量、無狀态的雲原生應用，使應用具備雲端部署、可遠端通路、彈性、共享、按需自助服務、高可用、與位置無關等特征，使之天生就具備雲的基因，适合雲環境部署運作。雲原生十二因素更多的也是從建構雲原生應用的角度讨論的。

（一） 彈性

彈性是雲計算的重要特征，理論上不受資源限制，可以無限占用資源（當然需要按使用量付費）。容器之是以和雲原生扯上關系，因為彈性也是容器的重要特征，采用容器很重要的是其彈性能力。彈性包括彈性使用資源和服務執行個體彈性擴充能力。在單執行個體擴充資源達到瓶頸，則配合負載均衡機制實作容器執行個體的彈性擴充。我們談論雲原生應用彈性，應該包括應用使用資源的彈性和應用執行個體彈性擴充的彈性。

（二） 共享

雲計算分三種類型：IaaS、PaaS、SaaS，這就涉及三個層級的共享：資源共享、平台共享、應用共享。雲原生應用是SaaS層服務，部署于IaaS或PaaS層。應用有一份基準代碼，多份部署，也是共享，是從應用開發角度考慮，但不是雲應用共享意義。

雲應用可以對所有人開放，大家共享雲應用提供的服務。雲應用需要部署在雲計算平台上，使用雲計算資源，這就實作了平台共享和資源共享。

（三） 自治

雲應用部署與位置無關，你不知道它會被部署到什麼位置，底層對使用者透明。是以雲原生應用的依賴包、配置檔案、後端服務等就需要和應用一起同生共死，成為一個整體，實作自管理自治理。

微服務的設計也遵循自治原則，和雲原生應用非常相似。這可能也是把它們放一起讨論的原因。是以我們在用微服務實作雲原生應用的時候，自治是一個重要的判斷标準。這是分布式中心的好處，自成一體。就像人，每個人都是一個分布式中心，具備自我管理的能力。

（四） 傳遞标準化，與位置無關

雲應用建構可以在本地或者雲端，運作一定在雲端，那就要按照一定的标準傳遞，比如容器鏡像，使傳遞标準化。标準傳遞就可以在雲端任何支援标準的位置部署，或者根本不需要知道被部署到了什麼位置運作，和環境無關。就像Java曾經宣稱的那樣: Write Once, Run Anywhere，實作Build Once, Run Anywhere。

容器的一個好處是應用運作工具标準化，所有的應用都以标準化鏡像的方式傳遞，在标準化的容器裡運作。容器可以運作在任何地方，或者也無需知道它運作在哪裡，隻需要送出鏡像釋出運作就可以了。

（五） 高可用性

多執行個體部署、彈性、自治等特性是高可用的保證。采用容器有時候并不能保證應用的穩定性，但可以是靈活啟停、多執行個體高可用的。如果需要穩定的高可用機制，容器可能不是最好的選擇。

（六） 可監控審計

使用者對應用的通路調用，應用的運作情況狀态，不管通過日志或者接口能實時擷取到這些資訊，用于計量計費、監控和後期審計等。比如可以根據負載流量實作彈性伸縮。

（七） 按需通路自助服務

雲應用部署在雲端，根據客戶自己的需求，通過網絡通路，自助使用服務，不需要聯系雲應用管理人員。通常會有個雲應用服務目錄，每個應用服務都有使用說明，通過服務目錄可以找到适合自己滿足自身需求的應用。

（八） 可配置

雲應用往往依賴配置中心，實作不同環境應用的部署運作。比如開發、測試和生産環境，一些參數的配置可能是不一樣的。很多時候又不友善把所有的配置檔案都和應用打包在一起，是以可以通過配置中心來統一管理應用配置檔案，甚至可以實作運作時參數更新。

配置中心更多的是從應用運維的角度來考慮的。從自治角度來說，它并不是必須的。但是也是很重要的載體，就像人有大腦存儲，但依然需要借助紙筆記憶一樣。

（九） 靈活

靈活不管從應用開發部署角度或者運維營運角度，都是需要的。但我們覺得它不是雲原生應用的關鍵特性。靈活通常和輕量、微服務元件化相關，小了，輕了相對就靈活多了。很多時候靈活和架構相關，不隻是技術架構，也群組織架構相關。靈活更多的是流程、管理或體驗的需求。

五、 微服務、容器和DevOps建構雲原生應用

容器輕量、彈性；微服務小而專使開發、測試、更新效率提高，實作了靈活；DevOps持續內建、持續部署、持續釋出、持續監控、持續回報、持續改進而形成應用生命周期管理的閉環。容器的輕量特性非常适合運作微服務化應用。微服務架構使應用設計架構思想發生了改變。采用小而專的微服務完成某一特定的業務單元工作；通過微服務的組合或編排而成一個業務應用，完成特定的業務流程；業務流程可以按需編排，實時部署；鏡像使傳遞标準化，容器使運維排程标準化，鏡像倉庫使分發部署标準化。标準化使持續內建、部署、釋出流程簡化，服務編排使應用研發實作靈活化，DevOps持續監控、回報、改進使響應變化靈活化。可以及時反映市場業務需求的變化和要求。

也是以容器、微服務和DevOps會被放在一起來共同建構輕量、無狀态的雲原生應用。

六、 應用改造和遷移

應用通過改造使其具備雲原生的特性（重生），部署于雲環境，可以簡單的把它看到雲原生應用。但是如果不做改造直接遷移到雲環境，并不能成為雲原生應用，即便具備雲的某些特性，比如ESB服務，并不是雲原生應用。