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

一.云原生的定義

云原生(Cloud Native)是一種構建和運行應用程序的方法，是一套技術體系和方法論。Cloud Native是一個組合詞，Cloud+Native。Cloud是適應范圍為云平臺，Native表示應用程序從設計之初即考慮到云的環(huán)境，原生為云而設計，在云上以最佳姿勢運行，充分利用和發(fā)揮云平臺的彈性+分布式優(yōu)勢。

1、原生云的歷史

2013年，Pivotal公司的Matt Stine于首次提出原生云(CloudNative)的概念，用于區(qū)分為云而設計的應用和云上部屬傳統(tǒng)應用。

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

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

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

2、CNCF對云原生的定義

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

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

“云原生技術有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網(wǎng)格、微服務、不可變基礎設施和聲明式API。

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

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

CNCF還給出了構建云原生的相關技術棧，已經(jīng)基金會相關的孵化項目信息。

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

3、云原生的關鍵技術

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

▲云原生技術棧

• 容器

容器技術是一種輕量級的虛擬化技術。通過操作系統(tǒng)內核的能力，對每個進程的資源使用(包括CPU、內存、硬盤I/O、網(wǎng)絡等)進行隔離，達到容器里運行的進程與其他進程進行一定程度的隔離，同時避免了虛擬機(Virtual Machine)過高的額外消耗。

容器通常與容器編排系統(tǒng)一起工作，容器編排系統(tǒng)提供容器的部署和組織能力。容器編排系統(tǒng)通?？梢詫⒋罅康臋C器(物理機或虛擬機)作為一個集群進行統(tǒng)一管理，通過設定的策略，將容器部署到這個集群的機器上;實現(xiàn)容器多實例的部署和應用路由的自動化配置;對基礎設施和容器進行監(jiān)控。

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

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

目前最主流的容器編排實現(xiàn)就是Kubernetes了，Kubernetes 是用于自動部署，擴展和管理容器化應用程序的開源系統(tǒng)。它將組成應用程序的容器組合成邏輯單元，以便于管理和服務發(fā)現(xiàn)。Kubernetes 源自Google 15 年生產(chǎn)環(huán)境的運維經(jīng)驗，同時凝聚了社區(qū)的最佳創(chuàng)意和實踐。目前商用和開源的容器平臺，基本都是基于Kubernetes的。

• 不可變基礎設施

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

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

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

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

• 微服務

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

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

由于微服務是一種分布式系統(tǒng)，分布式系統(tǒng)設計的復雜性。為解決微服務系統(tǒng)設計復雜性，各種微服務治理框架層出不窮。比較流行的有Spring Cloud，Dubbo和Istio等。

Spring Cloud是基于微服務優(yōu)秀開源項目的一個微服務治理全家桶?？梢赃x擇不同的解決方案和開源組件，比較完備的解決方案有Spirng cloud Neflix。Spring Cloud是目前全球用的最多的微服務治理框架，可以利用現(xiàn)有Spring的完整生態(tài)，和SpringBoot無縫寫作文。

Dubbo是國內阿里巴巴提供的服務治理開源項目，同樣和Spring整合。國內很多互聯(lián)網(wǎng)公司選用Dubbo作為微服務框架。

Istio是一個服務網(wǎng)格的開源項目，我們會在下章介紹。

• 服務網(wǎng)格

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

服務網(wǎng)格是最近很火的一個概念，服務網(wǎng)格是用于控制和監(jiān)控微服務應用程序中的內部服務到服務流量的軟件基礎結構層。它通常采取與應用程序代碼一起部署，作為網(wǎng)絡代理的 "數(shù)據(jù)平面" 和與這些代理交互的 "控制平面" 的形式。在此模型中，服務網(wǎng)格對于業(yè)務開發(fā)人員是透明的， 而平臺運維人員也可以在不關心業(yè)務的情況下，有效的運維應用，確保應用的可靠性、安全性和可見性。而且服務網(wǎng)格對對業(yè)務應用開發(fā)過程的侵入性降到最低，對所有語言友好。

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

• 聲明式API

和聲明式相對的是命令式的API。命令式的API是給出每一個操作步驟，目標系統(tǒng)只需要按照步驟進行執(zhí)行，目標系統(tǒng)將結果返回給調用者，調用者對結果進行處理;聲明式API是給出一個最終的狀態(tài)，目標系統(tǒng)對資源進行操作，以到達要求，調用者不需要進行干預。

聲明式API的優(yōu)勢在于讓分布式系統(tǒng)之間的交付變的簡單。我們不需要關心任何過程細節(jié)。聲明式的方式能夠大量地減少使用者的工作量，極大地增加開發(fā)的效率，這是因為聲明式能夠簡化需要的代碼，減少開發(fā)人員的工作，如果我們使用命令式的方式進行開發(fā)，雖然在配置上比較靈活，但是帶來了更多的工作。

聲明式API的一個最好實例就是Kubernetes。用于操作K8s的yml文件都是聲明式的。另外還有一些用于部署的聲明式API開源項目，如Terraform。

二.云原生的發(fā)展趨勢

1、運維繼續(xù)下沉，服務網(wǎng)格將成為主流，Serverless逐步推廣

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

▲運維職能下移

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

因為業(yè)務功能的提供才是業(yè)務開發(fā)團隊的價值體現(xiàn)，業(yè)務開發(fā)團隊應該聚焦于業(yè)務功能的實現(xiàn)，非功能的需求應該交給平臺處理?；谶@個訴求服務網(wǎng)格出現(xiàn)了，微服務治理的問題可以有服務網(wǎng)格統(tǒng)一運維管理，業(yè)務應用只需關注業(yè)務能力的實現(xiàn)。

服務網(wǎng)格出現(xiàn)后，業(yè)務應用本身的生命周期還是需要應用來運維保障。這就逐步演化出了Serverless的概念，Serverless并非沒有Server，而是對于開發(fā)團隊來說根本不在意Server是什么樣的。開發(fā)團隊只需要提交業(yè)務代碼，就可以得到需要的運行實例，對應用開發(fā)團隊來說，Server是不存在的。

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

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

隨著云計算的發(fā)展，虛擬化技術越來越多的被使用，從計算虛擬化到存儲虛擬化到網(wǎng)絡虛擬化。虛擬化技術帶來了很多的好處，虛擬化是基礎設施服務化的基礎，通過虛擬化，可以實現(xiàn)基礎設施即代碼，大大提升了資源的可管理性和自動化程度。但是虛擬化帶來了另外一個問題，就是性能的損耗和軟件進程之間的相互影響問題。

對于性能損耗，會導致需要的資源比實際業(yè)務耗費的資源更多，提升了服務器資源的成本;進程之間的相互影響則會導致云平臺的整體性能問題，網(wǎng)絡虛擬化和存儲虛擬化都需要通過軟件進程的方式，來處理網(wǎng)絡流量和IO。為了實現(xiàn)分布式高可用和減少數(shù)據(jù)包轉發(fā)，基礎的SDN，SDS的進程通常是和應用進程部署在同一套集群上。這就導致了有可能部分的SDN和SDS的管理進程所在服務由于各種原因，CPU或是內存占用過大，導致無法及時處理網(wǎng)絡和IO請求，導致云平臺整體性能下降。

為了解決這兩個問題，目前一個解決思路就是軟硬結合，講云平臺的管理進程，如調度管理，網(wǎng)絡的虛擬交換機，存儲的虛擬存儲網(wǎng)關從操作系統(tǒng)進程中剝離出來，讓這些進程跑在專門設計的服務器板卡上，這些板卡專門設計的，通常含有定制化的芯片(FPGA)，可以進行編程，從而可以保持虛擬化話的優(yōu)勢的同時，使的管理進程和業(yè)務進程隔離，避免相互影響;同時由于通過定制芯片(如FPGA)來處理，性能會有很大提升，大大降低了虛擬化的損耗。

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

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

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

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

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

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

安全容器，或是叫沙箱容器。為了解決容器的隔離性上的弱點，安全容器為容器的運行提供了一層沙箱(Sandbox)，容器在沙箱中運行的應用程序有自己的內核和虛擬設備，與主機和其它沙箱區(qū)分開來。安全容器的優(yōu)點是可以兼容目前的容器鏡像，不需要對容器編排Kubernetes做出大的修改就可以直接應用，缺點是犧牲了部分的性能和靈活度。目前安全容器的開源項目有Kata container，Google的gVisor等。

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

三.綜述

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