雲原生下一步的發展方向是什麼？

雲端計算經過十幾年的發展，從一開始討論什麼是雲端計算，到爭論雲端計算是否是舊瓶裝新酒，再到討論如何建設雲基礎能力，到如何建設雲平臺上的應用，隨著業界對雲端計算技術的不斷探索，我們對雲端計算的理解和期望在日益提升。當前，大部分的企業已經確實體會到了雲端計算帶來的競爭優勢，並已經建成企業內部的私有云基礎能力，或是將資料中心遷移到公有云上。應用如何使用好雲端計算基礎設施，使雲計算髮揮最大能力，是目前雲端計算技術中最重要的議題。基於雲端計算平臺設計的應用，業界稱之為雲原生應用。

一、雲原生的定義

雲原生(Cloud Native)是一種構建和執行應用程式的方法，是一套技術體系和方法論。Cloud Native是一個組合詞，Cloud+Native。Cloud是適應範圍為雲平臺，Native表示應用程式從設計之初即考慮到雲的環境，原生為雲而設計，在雲上以最佳姿勢執行，充分利用和發揮雲平臺的彈性+分散式優勢。

1、原生雲的歷史

2013年，Pivotal公司的Matt Stine於首次提出原生雲(CloudNative)的概念，用於區分為雲而設計的應用和雲上部屬傳統應用。

2015年，Matt Stine在《遷移到雲原生架構》一書中定義了符合原生雲架構的幾個特徵：12因素、微服務、自敏捷架構、基於API協作、抗脆弱性;

2015年雲原生計算基金會(CNCF)成立,CNCF作為一個廠商中立的基金會，致力於雲原生應用推廣和普及。

2017年，Matt Stine將原生雲架構歸納為模組化、可觀察、可部署、可測試、可替換、可處理6特質;而Pivotal最新官網對雲原生概括為4個要點：DevOps+持續交付+微服務+容器。

2、CNCF對雲原生的定義

CNCF(Cloud Native Computing Foundation)於 2015 年 7 月成立,隸屬於 Linux 基金會,初衷圍繞“雲原生”服務雲端計算。CNCF作為一個廠商中立的基金會，致力於Github上的快速成長的開源技術的推廣，如Kubernetes、Prometheus、Envoy等，幫助開發人員更快更好的構建出色的產品。

原生計算基金會(CNCF)成立，是雲端計算的一個里程碑，標誌著雲端計算的建設關注點從基礎設施的建設嚮應用的雲架構轉變。CNCF對雲原生的定義是個不斷優化的過程。目前CNCF對於原生雲的定義為：

“雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和執行可彈性擴充套件的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API。

這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。“

CNCF對雲原生的描述，前半部分是給出了雲原生的定義，並給出目前雲原生最佳的技術實踐。後半部分指出構建雲原生應用的目標。

CNCF還給出了構建雲原生的相關技術棧，已經基金會相關的孵化專案資訊。

▲CNCF 雲原生全景圖(Cloud Native Landscape)

3、雲原生的關鍵技術

CNCF在定義中給出了雲原生的關鍵技術，容器、服務網格、微服務、不可變基礎設施和宣告式API，是目前雲原生應用的最佳實踐。

▲雲原生技術棧

• 容器

容器技術是一種輕量級的虛擬化技術。通過作業系統核心的能力，對每個程序的資源使用(包括CPU、記憶體、硬碟I/O、網路等)進行隔離，達到容器裡執行的程序與其他程序進行一定程度的隔離，同時避免了虛擬機器(Virtual Machine)過高的額外消耗。

容器通常與容器編排系統一起工作，容器編排系統提供容器的部署和組織能力。容器編排系統通常可以將大量的機器(物理機或虛擬機器)作為一個叢集進行統一管理，通過設定的策略，將容器部署到這個叢集的機器上;實現容器多例項的部署和應用路由的自動化配置;對基礎設施和容器進行監控。

容器和容器編排技術對於雲原生的意義巨大，容器為雲原生應用提供了一個輕量級的執行平臺， 首先相對於傳統虛擬化技術，容器極其輕量，;可以實現秒級部署;同時容器應用易於移植，一次構建，隨處部署。而容器編排技術可以將容器部署到一個很大的叢集的同時，還能為應用提供彈性伸縮，故障轉移的能力，實現了容器上應用的高可用。提升應用部署的自動化能力和快速部署的能力。

目前常見的容器技術有Linux Container(簡稱LXC)和runC等。runC是目前的被廣泛認可的容器實現，他是基於根據 OCI 標準來建立和執行容器。而 OCI(Open Container Initiative)組織，旨在圍繞容器格式和執行時制定一個開放的工業化標準。

目前最主流的容器編排實現就是Kubernetes了，Kubernetes 是用於自動部署，擴充套件和管理容器化應用程式的開源系統。它將組成應用程式的容器組合成邏輯單元，以便於管理和服務發現。Kubernetes 源自Google 15 年生產環境的運維經驗，同時凝聚了社群的最佳創意和實踐。目前商用和開源的容器平臺，基本都是基於Kubernetes的。

• 不可變基礎設施

傳統運維的基礎設施通常是申請一臺或一組伺服器，運維人員通過SSH或是Agent的方式，將軟體的二進位制包的安裝到伺服器上並進行環境的配置。如果需要進行版本升級和引數變更等變更操作，就需要逐個伺服器地調整配置檔案，以及將新程式碼直接部署到現有伺服器上。這些伺服器承載的應用和引數是可以改變的，所以是可變基礎設施。這種運維方式也被稱為“雪花伺服器( Snowflake Server)”，伺服器像雪花一樣，每一片都獨特的與眾不同。

不可變基礎設施不同於傳統的運維，伺服器在部署後永遠不會被修改。如果需要以任何方式更新，如版本升級或是引數配置，需要構建新伺服器以替換舊伺服器。在不可變基礎設施中，伺服器的構建通常是以映象(Image)的方式提供的，任何一個更改都對應一個映象。不可變基礎設施又被稱為“鳳凰伺服器(Phoenix Server)”，伺服器應該像鳳凰，能夠從灰燼中重生。

不可變基礎架構的好處包括基礎架構中更高的一致性和可靠性，以及更簡單，更可預測的部署過程。它可以減少或完全杜絕可變基礎架構中常見的問題，例如配置漂移、叢集配置一致性和環境複製問題。

不可變基礎設施的一個實現方式就是被我們熟知的Docker。Docker通常被作為容器技術被人熟知，實際上Docker提供的是一種容器打包的技術。Docker的核心理念就是不可變基礎設施，Docker通過映象(Docker Images)或是Dockerfile來交付軟體。每一次新的版本的釋出都對整個執行環境進行重建，每一次更新都是一個新版本的Image。Docker利用容器的輕量化部署，可以達到最高的收益。

• 微服務

隨著需求不斷增加，單體應用可能會出現的諸多問題，比如每個小的變更都需要重新部署整個應用，一個小模組的程式碼缺陷可能導致所有業務不可用等問題。微服務是為解決這些問題的一種架構模式，微服務通過將業務應用由通過明確定義的 API 進行通訊的小型獨立服務組成。這些服務由各個小型獨立團隊負責。微服務架構使應用程式更易於擴充套件和更快地開發，從而加速創新並縮短新功能的上市時間。

微服務將應用拆分為小的獨立部署的服務的方式，和容器存在著天然的契合。雲上的應用要求可以故障轉移，彈性伸縮和快速啟停，這些也是微服務應用的設計要求。可以說容器和容器編排技術的發展，大大的推動了微服務的發展;反過來，微服務應用的發展，也推動了容器技術的推廣。

由於微服務是一種分散式系統，分散式系統設計的複雜性。為解決微服務系統設計複雜性，各種微服務治理框架層出不窮。比較流行的有Spring Cloud，Dubbo和Istio等。

Spring Cloud是基於微服務優秀開源專案的一個微服務治理全家桶。可以選擇不同的解決方案和開源元件，比較完備的解決方案有Spirng cloud Neflix。Spring Cloud是目前全球用的最多的微服務治理框架，可以利用現有Spring的完整生態，和SpringBoot無縫寫作文。

Dubbo是國內阿里巴巴提供的服務治理開源專案，同樣和Spring整合。國內很多網際網路公司選用Dubbo作為微服務框架。

Istio是一個服務網格的開源專案，我們會在下章介紹。

• 服務網格

前面我們講了，Docker和Kubernetes已經解決了應用部署，排程和更新的問題。但是微服務應用作為一種分散式系統，執行時的很多問題都需要應用去處理，比如服務的發現、故障熔斷和負載均衡等。為了解決這些問題，業界逐漸發展出了微服務治理框架。初期的微服務治理都是基於開發框架的，如Spring Cloud和Dubbo。這些開發框架很好的解決了微服務執行時的問題，但是存在開發語言鎖定，對應用存在侵入性、開發運維職責不清等弊端。服務網格(ServiceMesh)就是在這種環境下出現的。

服務網格是最近很火的一個概念，服務網格是用於控制和監控微服務應用程式中的內部服務到服務流量的軟體基礎結構層。它通常採取與應用程式程式碼一起部署，作為網路代理的 "資料平面" 和與這些代理互動的 "控制平面" 的形式。在此模型中，服務網格對於業務開發人員是透明的， 而平臺運維人員也可以在不關心業務的情況下，有效的運維應用，確保應用的可靠性、安全性和可見性。而且服務網格對對業務應用開發過程的侵入性降到最低，對所有語言友好。

服務網格目前最主要的開源專案是Istio。Istio基於Kubernetes環境提供的一個完整的解決方案來滿足微服務應用程式的各種需求。通過Kubernetes的Pod，Istio為每一個微服務例項注入一個Sidecar，代理(Proxy)業務例項的所有外部流量，從而實現微服務治理框架所需要的行為洞察和操作控制的能力，如服務註冊發現、配置管理、熔斷和鏈路追蹤等。還可以提供靈活的灰度釋出策略配置。

• 宣告式API

和宣告式相對的是命令式的API。命令式的API是給出每一個操作步驟，目標系統只需要按照步驟進行執行，目標系統將結果返回給呼叫者，呼叫者對結果進行處理;宣告式API是給出一個最終的狀態，目標系統對資源進行操作，以到達要求，呼叫者不需要進行干預。

宣告式API的優勢在於讓分散式系統之間的交付變的簡單。我們不需要關心任何過程細節。宣告式的方式能夠大量地減少使用者的工作量，極大地增加開發的效率，這是因為宣告式能夠簡化需要的程式碼，減少開發人員的工作，如果我們使用命令式的方式進行開發，雖然在配置上比較靈活，但是帶來了更多的工作。

宣告式API的一個最好例項就是Kubernetes。用於操作K8s的yml檔案都是宣告式的。另外還有一些用於部署的宣告式API開源專案，如Terraform。

二、雲原生的發展趨勢

1、運維繼續下沉，服務網格將成為主流，Serverless逐步推廣

雲端計算的一個發展方向就是運維下沉，將和業務無關的管理功能和運維工作儘量下沉到基礎設施中，應用可以聚焦在業務能力的開發和運營。這個趨勢演化的過程，影響了雲端計算的發展方向。從一開始的虛擬化，到IaaS，到PaaS都是將應用系統的部分運維職責交給平臺運維的過程。

▲運維職能下移

PaaS為雲應用提供了執行容器，解決了應用部署的問題和執行時管理的問題，但是應用仍然有大量的運維工作，特別是對於微服務應用，需要解決諸多的問題，如服務的釋出和感知，多例項應用的負載均衡，服務故障檢測和隔離，已經應用灰度釋出的策略等。這些在PaaS層面是無法解決的，通常是由開發框架解決，就是我們前面提到的微服務治理框架。

因為業務功能的提供才是業務開發團隊的價值體現，業務開發團隊應該聚焦於業務功能的實現，非功能的需求應該交給平臺處理。基於這個訴求服務網格出現了，微服務治理的問題可以有服務網格統一運維管理，業務應用只需關注業務能力的實現。

服務網格出現後，業務應用本身的生命週期還是需要應用來運維保障。這就逐步演化出了Serverless的概念，Serverless並非沒有Server，而是對於開發團隊來說根本不在意Server是什麼樣的。開發團隊只需要提交業務程式碼，就可以得到需要的執行例項，對應用開發團隊來說，Server是不存在的。

從目前業界的技術趨勢來看，ServiceMesh的概念已經被大部分的大型雲上企業接受，ServiceMesh被詬病的效能問題也在被逐步解決中，可以預測今年將有更多的微服務應用採用這一基礎能力。Serverless目前發展還比較初期，包括了全託管的服務和FaaS(函式即服務)，全託管服務在公有云已經逐步成熟，隨著混合雲的普及，全託管服務會逐步發展。FaaS由於涉及開發模式的轉變，目前要取代現有的開發模式還需要時日，不過有些合適的應用場景應該會有越來越多的應用。

2、軟硬結合，解決虛擬化效能問題的利器

隨著雲端計算的發展，虛擬化技術越來越多的被使用，從計算虛擬化到儲存虛擬化到網路虛擬化。虛擬化技術帶來了很多的好處，虛擬化是基礎設施服務化的基礎，通過虛擬化，可以實現基礎設施即程式碼，大大提升了資源的可管理性和自動化程度。但是虛擬化帶來了另外一個問題，就是效能的損耗和軟體程序之間的相互影響問題。

對於效能損耗，會導致需要的資源比實際業務耗費的資源更多，提升了伺服器資源的成本;程序之間的相互影響則會導致雲平臺的整體效能問題，網路虛擬化和儲存虛擬化都需要通過軟體程序的方式，來處理網路流量和IO。為了實現分散式高可用和減少資料包轉發，基礎的SDN，SDS的程序通常是和應用程序部署在同一套叢集上。這就導致了有可能部分的SDN和SDS的管理程序所在服務由於各種原因，CPU或是記憶體佔用過大，導致無法及時處理網路和IO請求，導致雲平臺整體效能下降。

為了解決這兩個問題，目前一個解決思路就是軟硬結合，講雲平臺的管理程序，如排程管理，網路的虛擬交換機，儲存的虛擬儲存閘道器從作業系統程序中剝離出來，讓這些程序跑在專門設計的伺服器板卡上，這些板卡專門設計的，通常含有定製化的晶片(FPGA)，可以進行程式設計，從而可以保持虛擬化話的優勢的同時，使的管理程序和業務程序隔離，避免相互影響;同時由於通過定製晶片(如FPGA)來處理，效能會有很大提升，大大降低了虛擬化的損耗。

目前大的公有云廠商都有相關的產品在自身的公有云應用。

3、容器虛擬機器進一步融合

容器和虛擬機器的優勢和劣勢，從容器技術誕生的那天起就一直在爭論。容器輕量化，良好的封裝能力和部署簡便的特點，特別是在Kubernetes出現後，大有取代虛擬機器的氣勢。但是在處理重應用(如關係型資料庫，大資料等)的這點上，容器技術顯得有些力不從心。另外容器技術在資源隔離和安全性上，還達不到虛擬機器的水準，所以在很多場景，仍然是虛擬機器的用武之地。

在這種情況下，如何實現容器技術和虛擬化技術的融合，發揮兩者的長處，成為雲端計算的一個發展課題。目前的技術主要有三種，一種是容器虛擬機器的混布;一種是輕量級虛擬機器;最後是安全容器。

容器虛擬機器的混布。通過修改容器或是虛擬機器的編排引擎，使得可以通過一套API，支援容器和虛擬機器的部署，同時打通虛擬化層和容器的網路，使之更高效率的進行互訪。這是一些傳統的虛擬化廠商目前的做法。目前比較成熟的實現有Redhad的Kubevirt。

輕量級虛擬機器。解決虛擬機器映象過於龐大，啟動慢，耗費資源大的問題，業界提出了輕量級虛擬機器的解決方案。輕量級虛擬機器使用精簡專屬的庫作業系統(LibraryOS)，它能夠使用高階語言編譯並直接執行在商用雲平臺虛擬機器管理程式之上。相比於容器技術它們有很多的優點，不僅僅有著媲美虛擬機器的隔離能力，而且有更快的啟動時間和更小的攻擊面。輕量級虛擬機器的由於使用了專屬的作業系統，在語言支援和相容性上都不如其他解決方案。目前輕量級虛擬機器的技術有很多，例如Unikernel，Drawbridge, MirageOS 和HaLVM等。

安全容器，或是叫沙箱容器。為了解決容器的隔離性上的弱點，安全容器為容器的執行提供了一層沙箱(Sandbox)，容器在沙箱中執行的應用程式有自己的核心和虛擬裝置，與主機和其它沙箱區分開來。安全容器的優點是可以相容目前的容器映象，不需要對容器編排Kubernetes做出大的修改就可以直接應用，缺點是犧牲了部分的效能和靈活度。目前安全容器的開源專案有Kata container，Google的gVisor等。

安全容器和輕量級虛擬機器的實現上，可能會有一些重疊，但是不管哪一個方向，都是向著虛擬機器和容器融合這個大的方向發展。目標都是在發揮容器的輕量級，快速交付和靈活排程能力的同時，提升業務應用的隔離性和安全性。

三、綜述

雲原生技術是目前技術階段，企業IT系統的最優模式的集合。企業通過遵循雲原生的技術和設計模式，可以充分發揮雲端計算平臺的優勢的同時，可以最大限度的減少對開發效率的影響，實現穩定而高效的系統。技術是不斷髮展的，雲原生技術也是一個不斷更新迭代的過程，相應的開發習慣和方法也會跟著改變。