一、什么是云原生

云原生的概念，由來自Pivotal的MattStine根據其多年的框架經驗總結于2013年首次提出，被一直延續使用至今。這是他當時提出的幾個主要特征:

• 面向微服務框架
• 自服務敏捷架構
• 基于API的協作
• 符合12因素應用
• 抗脆弱性

它的出現其實也得益于虛擬技術的發展，在社區中不斷完善，并逐漸成為一種新興的基礎設施交付方案，在某種意義上重新定義了IT界軟硬件資源的標準。2015年谷歌主導CNCF成立之后，給出的1.0云原生定義主要是云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。目前CNCF給出了云原生應用的三大特征：

• 容器化封裝：以容器為基礎，提高整體開發水平，形成代碼和組件重用，簡化云原生應用程序的維護。在容器中運行應用程序和進程，并作為應用程序部署的獨立單元，實現高水平資源隔離。
• 動態管理：通過集中式的編排調度系統來動態的管理和調度。
• 面向微服務：明確服務間的依賴，互相解耦。

 

上圖可以看出，其實云原生涉及的技術領域眾多，上面收集了和其技術相關的工具、平臺和項目。通過此圖可快速了解和應用相關的技術，根據業務能力可對架構進行重組與建設。

二、云原生的核心技術

1、容器

容器(container)這一概念最早出現在Linux中出現的，又稱LXC(Linux Container)，主要是通過Cgroups的資源管理能力和Namespace的資源隔離能力結合在一起實現進程級別的隔離。

2、K8s

全稱是Kubernetes，由Google 基于 Borg 開源容器編排的調度系統，是一種基于容器技術的分布式架構領先方案。在Docker技術的基礎上，為容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等功能，用戶不需要再過多關注資源的管理問題，降低操作的復雜度，提高了大規模容器集群管理的便捷性。

3、微服務(Microservices)

微服務則是一種用于構建應用的架構方案，微服務架構有別于為傳統的單體應用的是將應用拆分成多個核心功能，每個功能都被稱為一個獨立的服務，可以單獨構建和部署，其中某個服務出現故障也不會影響其他的功能模塊，這句體現了其針對特定服務發布，影響小，風險小等特點。

4、服務網格(Service Mesh)

服務網格指的是用于微服務應用的可配置基礎架構層。在使用服務網格時通常會提供一個sidecar代理實例，主要處理 service 間的通信、監控、以及一些安全相關的考量，每個service里面都會有一個sidecar，同樣也提供了服務發現、負載均衡、授權等功能。

5、無服務(Serverless)

根據 CNCF 的定義，Serverless 是指構建和運行不需要服務器管理的應用程序的概念。即開發人員無需關注底層的基礎設施，只需要關注應用程序的業務本身就行，且該服務可以自動擴展。

6、DevOps

早期的項目使用的是“瀑布模型”進行軟件交付，即一個階段所有的工作完成之后再往下一個階段，但這樣的模式無法滿足業務快速開發交付及變更需求的情況，于是后面就出現了敏捷開發這一概念，即一種快速應對需求變化軟件開發能力，而DevOps就是基于敏捷開發將軟件開發/測試人員/IT運維關聯在一起，通過工具、組織等方式使開發、測試、發布流程自動化，讓軟件可以頻繁、高效的發布。

7、云(Cloud)

常常聽到的公有云，私有云，混合云都是基于這個生態衍生出來的各種場景，不同的云搭建環境，所需資源亦有所不同，比如公有云是在互聯網上發布的云計算服務，而私有云則是在公司內網發布的云計算服務，目前沒有一種云計算類型可以解決所有場景出現的問題，怎么選擇適合自己的場景則需要根據技術需求決定。

三、云原生之實踐

1、云原生中的DevOps

DevOps這一概念雖然比容器、微服務出現得早，卻是隨著他們的出現才得以快速的發展。實際上DevOps不單是一個實現自動化的工具鏈，更是通過構建企業文化的方式促進開發與運維之間的協作。下圖可以看出，這樣的運作模式已經顛覆了傳統的工作模式，每個環節都不再獨立分割開，而是用協作的方式生產更快、更高質量的生產軟件。

2、持續集成

(CONTINUOUS INTEGRATION，CI)其核心是新提交的代碼與原代碼正確的集成。開發人員多次、頻繁的將代碼提交到代碼倉庫中，在合并到指定分支之前，對新提交上來的內容進行編譯、自動化檢測(如：代碼格式檢測)的驗證。這樣的過程既保證了代碼的完整性、安全性，也為后面的工作提供了質量保證。

 

3、持續交付

(CONTINUOUS DELIVERY，CD)其重點不在代碼本身，而是在可以交付的產品上。在發布到生產環境之前，對新增的代碼進行測試(test) -> 模擬(staging) -> 生產(production)，即簡化繁瑣的發布流程，又保障新添加的代碼在生產環境是可用的。

4、持續部署

（CONTINUOUS DEPLOYMENT) 通過自動化部署的方式頻繁的交付產品，關注的重點在于自動化部署。從開發人員提交代碼到編譯、測試、部署整個流程都是通過自動化執行，這種方式加快了交付的速度，同時在發現問題時也縮短修復的時間。

CICD關注整個開發到交付的過程，中間的測試、模擬、自動部署等整條生產鏈上所需要的每一步都是需要關注的。而DevOps則更關注于各部門、不同崗位之間的協同過程，尤其是開發和運維之間的溝通壁壘。總的來說，DevOps與CICD一體兩面，CICD 自動化是DevOps 具體實現方式。

云原生之于國內，還是一個非常新的話題。云原生的覆蓋面廣、已知和潛在的用處大，由于全面及深入的理解需投入大量的人力及時間成本，因此不管是學習研究還是在實戰中需要分而治之。總體來說，云原生有以下幾個方面的優勢：

① 快速迭代：利用云原生應用程序開發，多種技術、多種方案相互融合，為項目交付提供自動化和編排的快速迭代方案。

② 自動部署：云原生的方法對于傳統的方法而言，直擊代碼質量低下、發布流程繁瑣的痛點，通過其具備的自動化和組合功能，針對編譯、測試、部署等過程建立良好流程基礎，快速交付。

③ 獨立高效：云原生帶來的微服務化框架，打破了傳統的開發模式，對于一個應用來說，一個微服務就是一個可獨立發布的應用；對于一個團隊來說，為各個部門，不同崗位提供更多協同與溝通上的的思路。

相信現在大家對容器和云原生有了一定的了解，過去我們也分享過容器化改造的具體步驟，供各位借鑒：

1、建設組織級鏡像倉庫（若有Artifactory，可使用其作為Docker鏡像倉庫；如果沒有，建議選用Harbor作為鏡像倉庫）。

2、制定鏡像管理規范，確定是由哪個部門來管。

3、關于基礎鏡像、中間件鏡像構建、管理及維護，要有專人負責。

4、制定不同語言類型的標準鏡像模板及CICD工作流。

5、結合鏡像管理規范對現有應用進行容器化改造（如一些目錄調整、啟停腳本編寫等）。

6、選擇合適應用進行試點。

7、試點階段回顧與總結，持續反饋、持續改進。

8、制定全面推廣策略并實施。