【作者】金果，某股份制銀行云架構(gòu)師，超過(guò)15年的IT從業(yè)經(jīng)驗(yàn)，先后在國(guó)內(nèi)外大型IT企業(yè)任職軟件開發(fā)工程師，系統(tǒng)工程師和架構(gòu)師，目前負(fù)責(zé)私有云基礎(chǔ)設(shè)施的規(guī)劃，了解云基礎(chǔ)設(shè)施和微服務(wù)架構(gòu)。
云計(jì)算經(jīng)過(guò)十幾年的發(fā)展，從一開始討論什么是云計(jì)算，到爭(zhēng)論云計(jì)算是否是舊瓶裝新酒，再到討論如何建設(shè)云基礎(chǔ)能力，到如何建設(shè)云平臺(tái)上的應(yīng)用，隨著業(yè)界對(duì)云計(jì)算技術(shù)的不斷探索，我們對(duì)云計(jì)算的理解和期望在日益提升。當(dāng)前，大部分的企業(yè)已經(jīng)確實(shí)體會(huì)到了云計(jì)算帶來(lái)的競(jìng)爭(zhēng)優(yōu)勢(shì)，并已經(jīng)建成企業(yè)內(nèi)部的私有云基礎(chǔ)能力，或是將數(shù)據(jù)中心遷移到公有云上。應(yīng)用如何使用好云計(jì)算基礎(chǔ)設(shè)施，使云計(jì)算發(fā)揮最大能力，是目前云計(jì)算技術(shù)中最重要的議題。基于云計(jì)算平臺(tái)設(shè)計(jì)的應(yīng)用，業(yè)界稱之為云原生應(yīng)用。
一．云原生的定義
云原生（Cloud Native）是一種構(gòu)建和運(yùn)行應(yīng)用程序的方法，是一套技術(shù)體系和方法論。Cloud Native是一個(gè)組合詞，Cloud+Native。Cloud是適應(yīng)范圍為云平臺(tái)，Native表示應(yīng)用程序從設(shè)計(jì)之初即考慮到云的環(huán)境，原生為云而設(shè)計(jì)，在云上以最佳姿勢(shì)運(yùn)行，充分利用和發(fā)揮云平臺(tái)的彈性+分布式優(yōu)勢(shì)。
1、原生云的歷史
2013年，Pivotal公司的Matt Stine于首次提出原生云（CloudNative）的概念，用于區(qū)分為云而設(shè)計(jì)的應(yīng)用和云上部屬傳統(tǒng)應(yīng)用。
2015年，Matt Stine在《遷移到云原生架構(gòu)》一書中定義了符合原生云架構(gòu)的幾個(gè)特征：12因素、微服務(wù)、自敏捷架構(gòu)、基于API協(xié)作、抗脆弱性；
2015年云原生計(jì)算基金會(huì)（CNCF）成立,CNCF作為一個(gè)廠商中立的基金會(huì)，致力于云原生應(yīng)用推廣和普及。
2017年，Matt Stine將原生云架構(gòu)歸納為模塊化、可觀察、可部署、可測(cè)試、可替換、可處理6特質(zhì)；而Pivotal最新官網(wǎng)對(duì)云原生概括為4個(gè)要點(diǎn)：DevOps+持續(xù)交付+微服務(wù)+容器。
2、CNCF對(duì)云原生的定義
CNCF(Cloud Native Computing Foundation)于2015年7月成立,隸屬于Linux基金會(huì),初衷圍繞“云原生”服務(wù)云計(jì)算。CNCF作為一個(gè)廠商中立的基金會(huì)，致力于Github上的快速成長(zhǎng)的開源技術(shù)的推廣，如Kubernetes、Prometheus、Envoy等，幫助開發(fā)人員更快更好的構(gòu)建出色的產(chǎn)品。
原生計(jì)算基金會(huì)（CNCF）成立，是云計(jì)算的一個(gè)里程碑，標(biāo)志著云計(jì)算的建設(shè)關(guān)注點(diǎn)從基礎(chǔ)設(shè)施的建設(shè)向應(yīng)用的云架構(gòu)轉(zhuǎn)變。CNCF對(duì)云原生的定義是個(gè)不斷優(yōu)化的過(guò)程。目前CNCF對(duì)于原生云的定義為：
“云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。
這些技術(shù)能夠構(gòu)建容錯(cuò)性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動(dòng)化手段，云原生技術(shù)使工程師能夠輕松地對(duì)系統(tǒng)作出頻繁和可預(yù)測(cè)的重大變更。“
CNCF對(duì)云原生的描述，前半部分是給出了云原生的定義，并給出目前云原生最佳的技術(shù)實(shí)踐。后半部分指出構(gòu)建云原生應(yīng)用的目標(biāo)。
CNCF還給出了構(gòu)建云原生的相關(guān)技術(shù)棧，已經(jīng)基金會(huì)相關(guān)的孵化項(xiàng)目信息。
▲CNCF云原生全景圖（Cloud Native Landscape）
3、云原生的關(guān)鍵技術(shù)
CNCF在定義中給出了云原生的關(guān)鍵技術(shù)，容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API，是目前云原生應(yīng)用的最佳實(shí)踐。
▲云原生技術(shù)棧
-容器
容器技術(shù)是一種輕量級(jí)的虛擬化技術(shù)。通過(guò)操作系統(tǒng)內(nèi)核的能力，對(duì)每個(gè)進(jìn)程的資源使用（包括CPU、內(nèi)存、硬盤I/O、網(wǎng)絡(luò)等）進(jìn)行隔離，達(dá)到容器里運(yùn)行的進(jìn)程與其他進(jìn)程進(jìn)行一定程度的隔離，同時(shí)避免了虛擬機(jī)（Virtual Machine）過(guò)高的額外消耗。
容器通常與容器編排系統(tǒng)一起工作，容器編排系統(tǒng)提供容器的部署和組織能力。容器編排系統(tǒng)通?？梢詫⒋罅康臋C(jī)器（物理機(jī)或虛擬機(jī)）作為一個(gè)集群進(jìn)行統(tǒng)一管理，通過(guò)設(shè)定的策略，將容器部署到這個(gè)集群的機(jī)器上；實(shí)現(xiàn)容器多實(shí)例的部署和應(yīng)用路由的自動(dòng)化配置；對(duì)基礎(chǔ)設(shè)施和容器進(jìn)行監(jiān)控。
容器和容器編排技術(shù)對(duì)于云原生的意義巨大，容器為云原生應(yīng)用提供了一個(gè)輕量級(jí)的運(yùn)行平臺(tái)，首先相對(duì)于傳統(tǒng)虛擬化技術(shù)，容器極其輕量，；可以實(shí)現(xiàn)秒級(jí)部署；同時(shí)容器應(yīng)用易于移植，一次構(gòu)建，隨處部署。而容器編排技術(shù)可以將容器部署到一個(gè)很大的集群的同時(shí)，還能為應(yīng)用提供彈性伸縮，故障轉(zhuǎn)移的能力，實(shí)現(xiàn)了容器上應(yīng)用的高可用。提升應(yīng)用部署的自動(dòng)化能力和快速部署的能力。
目前常見的容器技術(shù)有Linux Container（簡(jiǎn)稱LXC）和runC等。runC是目前的被廣泛認(rèn)可的容器實(shí)現(xiàn)，他是基于根據(jù)OCI標(biāo)準(zhǔn)來(lái)創(chuàng)建和運(yùn)行容器。而OCI(Open Container Initiative)組織，旨在圍繞容器格式和運(yùn)行時(shí)制定一個(gè)開放的工業(yè)化標(biāo)準(zhǔn)。
目前最主流的容器編排實(shí)現(xiàn)就是Kubernetes了，Kubernetes是用于自動(dòng)部署，擴(kuò)展和管理容器化應(yīng)用程序的開源系統(tǒng)。它將組成應(yīng)用程序的容器組合成邏輯單元，以便于管理和服務(wù)發(fā)現(xiàn)。Kubernetes源自Google 15年生產(chǎn)環(huán)境的運(yùn)維經(jīng)驗(yàn)，同時(shí)凝聚了社區(qū)的最佳創(chuàng)意和實(shí)踐。目前商用和開源的容器平臺(tái)，基本都是基于Kubernetes的。
-不可變基礎(chǔ)設(shè)施
傳統(tǒng)運(yùn)維的基礎(chǔ)設(shè)施通常是申請(qǐng)一臺(tái)或一組服務(wù)器，運(yùn)維人員通過(guò)SSH或是Agent的方式，將軟件的二進(jìn)制包的安裝到服務(wù)器上并進(jìn)行環(huán)境的配置。如果需要進(jìn)行版本升級(jí)和參數(shù)變更等變更操作，就需要逐個(gè)服務(wù)器地調(diào)整配置文件，以及將新代碼直接部署到現(xiàn)有服務(wù)器上。這些服務(wù)器承載的應(yīng)用和參數(shù)是可以改變的，所以是可變基礎(chǔ)設(shè)施。這種運(yùn)維方式也被稱為“雪花服務(wù)器（Snowflake Server）”，服務(wù)器像雪花一樣，每一片都獨(dú)特的與眾不同。
不可變基礎(chǔ)設(shè)施不同于傳統(tǒng)的運(yùn)維，服務(wù)器在部署后永遠(yuǎn)不會(huì)被修改。如果需要以任何方式更新，如版本升級(jí)或是參數(shù)配置，需要構(gòu)建新服務(wù)器以替換舊服務(wù)器。在不可變基礎(chǔ)設(shè)施中，服務(wù)器的構(gòu)建通常是以鏡像（Image）的方式提供的，任何一個(gè)更改都對(duì)應(yīng)一個(gè)鏡像。不可變基礎(chǔ)設(shè)施又被稱為“鳳凰服務(wù)器（Phoenix Server）”，服務(wù)器應(yīng)該像鳳凰，能夠從灰燼中重生。
不可變基礎(chǔ)架構(gòu)的好處包括基礎(chǔ)架構(gòu)中更高的一致性和可靠性，以及更簡(jiǎn)單，更可預(yù)測(cè)的部署過(guò)程。它可以減少或完全杜絕可變基礎(chǔ)架構(gòu)中常見的問(wèn)題，例如配置漂移、集群配置一致性和環(huán)境復(fù)制問(wèn)題。
不可變基礎(chǔ)設(shè)施的一個(gè)實(shí)現(xiàn)方式就是被我們熟知的Docker。Docker通常被作為容器技術(shù)被人熟知，實(shí)際上Docker提供的是一種容器打包的技術(shù)。Docker的核心理念就是不可變基礎(chǔ)設(shè)施，Docker通過(guò)鏡像（Docker Images）或是Dockerfile來(lái)交付軟件。每一次新的版本的發(fā)布都對(duì)整個(gè)運(yùn)行環(huán)境進(jìn)行重建，每一次更新都是一個(gè)新版本的Image。Docker利用容器的輕量化部署，可以達(dá)到最高的收益。
-微服務(wù)
隨著需求不斷增加，單體應(yīng)用可能會(huì)出現(xiàn)的諸多問(wèn)題，比如每個(gè)小的變更都需要重新部署整個(gè)應(yīng)用，一個(gè)小模塊的代碼缺陷可能導(dǎo)致所有業(yè)務(wù)不可用等問(wèn)題。微服務(wù)是為解決這些問(wèn)題的一種架構(gòu)模式，微服務(wù)通過(guò)將業(yè)務(wù)應(yīng)用由通過(guò)明確定義的API進(jìn)行通信的小型獨(dú)立服務(wù)組成。這些服務(wù)由各個(gè)小型獨(dú)立團(tuán)隊(duì)負(fù)責(zé)。微服務(wù)架構(gòu)使應(yīng)用程序更易于擴(kuò)展和更快地開發(fā)，從而加速創(chuàng)新并縮短新功能的上市時(shí)間。
微服務(wù)將應(yīng)用拆分為小的獨(dú)立部署的服務(wù)的方式，和容器存在著天然的契合。云上的應(yīng)用要求可以故障轉(zhuǎn)移，彈性伸縮和快速啟停，這些也是微服務(wù)應(yīng)用的設(shè)計(jì)要求?？梢哉f(shuō)容器和容器編排技術(shù)的發(fā)展，大大的推動(dòng)了微服務(wù)的發(fā)展；反過(guò)來(lái)，微服務(wù)應(yīng)用的發(fā)展，也推動(dòng)了容器技術(shù)的推廣。
由于微服務(wù)是一種分布式系統(tǒng)，分布式系統(tǒng)設(shè)計(jì)的復(fù)雜性。為解決微服務(wù)系統(tǒng)設(shè)計(jì)復(fù)雜性，各種微服務(wù)治理框架層出不窮。比較流行的有Spring Cloud，Dubbo和Istio等。
Spring Cloud是基于微服務(wù)優(yōu)秀開源項(xiàng)目的一個(gè)微服務(wù)治理全家桶。可以選擇不同的解決方案和開源組件，比較完備的解決方案有Spirng cloud Neflix。Spring Cloud是目前全球用的最多的微服務(wù)治理框架，可以利用現(xiàn)有Spring的完整生態(tài)，和SpringBoot無(wú)縫寫作文。
Dubbo是國(guó)內(nèi)阿里巴巴提供的服務(wù)治理開源項(xiàng)目，同樣和Spring整合。國(guó)內(nèi)很多互聯(lián)網(wǎng)公司選用Dubbo作為微服務(wù)框架。
Istio是一個(gè)服務(wù)網(wǎng)格的開源項(xiàng)目，我們會(huì)在下章介紹。
-服務(wù)網(wǎng)格
前面我們講了，Docker和Kubernetes已經(jīng)解決了應(yīng)用部署，調(diào)度和更新的問(wèn)題。但是微服務(wù)應(yīng)用作為一種分布式系統(tǒng)，運(yùn)行時(shí)的很多問(wèn)題都需要應(yīng)用去處理，比如服務(wù)的發(fā)現(xiàn)、故障熔斷和負(fù)載均衡等。為了解決這些問(wèn)題，業(yè)界逐漸發(fā)展出了微服務(wù)治理框架。初期的微服務(wù)治理都是基于開發(fā)框架的，如Spring Cloud和Dubbo。這些開發(fā)框架很好的解決了微服務(wù)運(yùn)行時(shí)的問(wèn)題，但是存在開發(fā)語(yǔ)言鎖定，對(duì)應(yīng)用存在侵入性、開發(fā)運(yùn)維職責(zé)不清等弊端。服務(wù)網(wǎng)格（ServiceMesh）就是在這種環(huán)境下出現(xiàn)的。
服務(wù)網(wǎng)格是最近很火的一個(gè)概念，服務(wù)網(wǎng)格是用于控制和監(jiān)控微服務(wù)應(yīng)用程序中的內(nèi)部服務(wù)到服務(wù)流量的軟件基礎(chǔ)結(jié)構(gòu)層。它通常采取與應(yīng)用程序代碼一起部署，作為網(wǎng)絡(luò)代理的"數(shù)據(jù)平面"和與這些代理交互的"控制平面"的形式。在此模型中，服務(wù)網(wǎng)格對(duì)于業(yè)務(wù)開發(fā)人員是透明的，而平臺(tái)運(yùn)維人員也可以在不關(guān)心業(yè)務(wù)的情況下，有效的運(yùn)維應(yīng)用，確保應(yīng)用的可靠性、安全性和可見性。而且服務(wù)網(wǎng)格對(duì)對(duì)業(yè)務(wù)應(yīng)用開發(fā)過(guò)程的侵入性降到最低，對(duì)所有語(yǔ)言友好。
服務(wù)網(wǎng)格目前最主要的開源項(xiàng)目是Istio。Istio基于Kubernetes環(huán)境提供的一個(gè)完整的解決方案來(lái)滿足微服務(wù)應(yīng)用程序的各種需求。通過(guò)Kubernetes的Pod，Istio為每一個(gè)微服務(wù)實(shí)例注入一個(gè)Sidecar，代理（Proxy）業(yè)務(wù)實(shí)例的所有外部流量，從而實(shí)現(xiàn)微服務(wù)治理框架所需要的行為洞察和操作控制的能力，如服務(wù)注冊(cè)發(fā)現(xiàn)、配置管理、熔斷和鏈路追蹤等。還可以提供靈活的灰度發(fā)布策略配置。
-聲明式API
和聲明式相對(duì)的是命令式的API。命令式的API是給出每一個(gè)操作步驟，目標(biāo)系統(tǒng)只需要按照步驟進(jìn)行執(zhí)行，目標(biāo)系統(tǒng)將結(jié)果返回給調(diào)用者，調(diào)用者對(duì)結(jié)果進(jìn)行處理；聲明式API是給出一個(gè)最終的狀態(tài)，目標(biāo)系統(tǒng)對(duì)資源進(jìn)行操作，以到達(dá)要求，調(diào)用者不需要進(jìn)行干預(yù)。
聲明式API的優(yōu)勢(shì)在于讓分布式系統(tǒng)之間的交付變的簡(jiǎn)單。我們不需要關(guān)心任何過(guò)程細(xì)節(jié)。聲明式的方式能夠大量地減少使用者的工作量，極大地增加開發(fā)的效率，這是因?yàn)槁暶魇侥軌蚝?jiǎn)化需要的代碼，減少開發(fā)人員的工作，如果我們使用命令式的方式進(jìn)行開發(fā)，雖然在配置上比較靈活，但是帶來(lái)了更多的工作。
聲明式API的一個(gè)最好實(shí)例就是Kubernetes。用于操作K8s的yml文件都是聲明式的。另外還有一些用于部署的聲明式API開源項(xiàng)目，如Terraform。
二．云原生的發(fā)展趨勢(shì)
1、運(yùn)維繼續(xù)下沉，服務(wù)網(wǎng)格將成為主流，Serverless逐步推廣
云計(jì)算的一個(gè)發(fā)展方向就是運(yùn)維下沉，將和業(yè)務(wù)無(wú)關(guān)的管理功能和運(yùn)維工作盡量下沉到基礎(chǔ)設(shè)施中，應(yīng)用可以聚焦在業(yè)務(wù)能力的開發(fā)和運(yùn)營(yíng)。這個(gè)趨勢(shì)演化的過(guò)程，影響了云計(jì)算的發(fā)展方向。從一開始的虛擬化，到IaaS，到PaaS都是將應(yīng)用系統(tǒng)的部分運(yùn)維職責(zé)交給平臺(tái)運(yùn)維的過(guò)程。
▲運(yùn)維職能下移
PaaS為云應(yīng)用提供了運(yùn)行容器，解決了應(yīng)用部署的問(wèn)題和運(yùn)行時(shí)管理的問(wèn)題，但是應(yīng)用仍然有大量的運(yùn)維工作，特別是對(duì)于微服務(wù)應(yīng)用，需要解決諸多的問(wèn)題，如服務(wù)的發(fā)布和感知，多實(shí)例應(yīng)用的負(fù)載均衡，服務(wù)故障檢測(cè)和隔離，已經(jīng)應(yīng)用灰度發(fā)布的策略等。這些在PaaS層面是無(wú)法解決的，通常是由開發(fā)框架解決，就是我們前面提到的微服務(wù)治理框架。
因?yàn)闃I(yè)務(wù)功能的提供才是業(yè)務(wù)開發(fā)團(tuán)隊(duì)的價(jià)值體現(xiàn)，業(yè)務(wù)開發(fā)團(tuán)隊(duì)?wèi)?yīng)該聚焦于業(yè)務(wù)功能的實(shí)現(xiàn)，非功能的需求應(yīng)該交給平臺(tái)處理?；谶@個(gè)訴求服務(wù)網(wǎng)格出現(xiàn)了，微服務(wù)治理的問(wèn)題可以有服務(wù)網(wǎng)格統(tǒng)一運(yùn)維管理，業(yè)務(wù)應(yīng)用只需關(guān)注業(yè)務(wù)能力的實(shí)現(xiàn)。
服務(wù)網(wǎng)格出現(xiàn)后，業(yè)務(wù)應(yīng)用本身的生命周期還是需要應(yīng)用來(lái)運(yùn)維保障。這就逐步演化出了Serverless的概念，Serverless并非沒有Server，而是對(duì)于開發(fā)團(tuán)隊(duì)來(lái)說(shuō)根本不在意Server是什么樣的。開發(fā)團(tuán)隊(duì)只需要提交業(yè)務(wù)代碼，就可以得到需要的運(yùn)行實(shí)例，對(duì)應(yīng)用開發(fā)團(tuán)隊(duì)來(lái)說(shuō)，Server是不存在的。
從目前業(yè)界的技術(shù)趨勢(shì)來(lái)看，ServiceMesh的概念已經(jīng)被大部分的大型云上企業(yè)接受，ServiceMesh被詬病的性能問(wèn)題也在被逐步解決中，可以預(yù)測(cè)今年將有更多的微服務(wù)應(yīng)用采用這一基礎(chǔ)能力。Serverless目前發(fā)展還比較初期，包括了全托管的服務(wù)和FaaS（函數(shù)即服務(wù)），全托管服務(wù)在公有云已經(jīng)逐步成熟，隨著混合云的普及，全托管服務(wù)會(huì)逐步發(fā)展。FaaS由于涉及開發(fā)模式的轉(zhuǎn)變，目前要取代現(xiàn)有的開發(fā)模式還需要時(shí)日，不過(guò)有些合適的應(yīng)用場(chǎng)景應(yīng)該會(huì)有越來(lái)越多的應(yīng)用。
2、軟硬結(jié)合，解決虛擬化性能問(wèn)題的利器
隨著云計(jì)算的發(fā)展，虛擬化技術(shù)越來(lái)越多的被使用，從計(jì)算虛擬化到存儲(chǔ)虛擬化到網(wǎng)絡(luò)虛擬化。虛擬化技術(shù)帶來(lái)了很多的好處，虛擬化是基礎(chǔ)設(shè)施服務(wù)化的基礎(chǔ)，通過(guò)虛擬化，可以實(shí)現(xiàn)基礎(chǔ)設(shè)施即代碼，大大提升了資源的可管理性和自動(dòng)化程度。但是虛擬化帶來(lái)了另外一個(gè)問(wèn)題，就是性能的損耗和軟件進(jìn)程之間的相互影響問(wèn)題。
對(duì)于性能損耗，會(huì)導(dǎo)致需要的資源比實(shí)際業(yè)務(wù)耗費(fèi)的資源更多，提升了服務(wù)器資源的成本；進(jìn)程之間的相互影響則會(huì)導(dǎo)致云平臺(tái)的整體性能問(wèn)題，網(wǎng)絡(luò)虛擬化和存儲(chǔ)虛擬化都需要通過(guò)軟件進(jìn)程的方式，來(lái)處理網(wǎng)絡(luò)流量和IO。為了實(shí)現(xiàn)分布式高可用和減少數(shù)據(jù)包轉(zhuǎn)發(fā)，基礎(chǔ)的SDN，SDS的進(jìn)程通常是和應(yīng)用進(jìn)程部署在同一套集群上。這就導(dǎo)致了有可能部分的SDN和SDS的管理進(jìn)程所在服務(wù)由于各種原因，CPU或是內(nèi)存占用過(guò)大，導(dǎo)致無(wú)法及時(shí)處理網(wǎng)絡(luò)和IO請(qǐng)求，導(dǎo)致云平臺(tái)整體性能下降。
為了解決這兩個(gè)問(wèn)題，目前一個(gè)解決思路就是軟硬結(jié)合，講云平臺(tái)的管理進(jìn)程，如調(diào)度管理，網(wǎng)絡(luò)的虛擬交換機(jī)，存儲(chǔ)的虛擬存儲(chǔ)網(wǎng)關(guān)從操作系統(tǒng)進(jìn)程中剝離出來(lái)，讓這些進(jìn)程跑在專門設(shè)計(jì)的服務(wù)器板卡上，這些板卡專門設(shè)計(jì)的，通常含有定制化的芯片（FPGA），可以進(jìn)行編程，從而可以保持虛擬化話的優(yōu)勢(shì)的同時(shí)，使的管理進(jìn)程和業(yè)務(wù)進(jìn)程隔離，避免相互影響；同時(shí)由于通過(guò)定制芯片（如FPGA）來(lái)處理，性能會(huì)有很大提升，大大降低了虛擬化的損耗。
目前大的公有云廠商都有相關(guān)的產(chǎn)品在自身的公有云應(yīng)用。
3、容器虛擬機(jī)進(jìn)一步融合
容器和虛擬機(jī)的優(yōu)勢(shì)和劣勢(shì)，從容器技術(shù)誕生的那天起就一直在爭(zhēng)論。容器輕量化，良好的封裝能力和部署簡(jiǎn)便的特點(diǎn)，特別是在Kubernetes出現(xiàn)后，大有取代虛擬機(jī)的氣勢(shì)。但是在處理重應(yīng)用（如關(guān)系型數(shù)據(jù)庫(kù)，大數(shù)據(jù)等）的這點(diǎn)上，容器技術(shù)顯得有些力不從心。另外容器技術(shù)在資源隔離和安全性上，還達(dá)不到虛擬機(jī)的水準(zhǔn)，所以在很多場(chǎng)景，仍然是虛擬機(jī)的用武之地。
在這種情況下，如何實(shí)現(xiàn)容器技術(shù)和虛擬化技術(shù)的融合，發(fā)揮兩者的長(zhǎng)處，成為云計(jì)算的一個(gè)發(fā)展課題。目前的技術(shù)主要有三種，一種是容器虛擬機(jī)的混布；一種是輕量級(jí)虛擬機(jī)；最后是安全容器。
容器虛擬機(jī)的混布。通過(guò)修改容器或是虛擬機(jī)的編排引擎，使得可以通過(guò)一套API，支持容器和虛擬機(jī)的部署，同時(shí)打通虛擬化層和容器的網(wǎng)絡(luò)，使之更高效率的進(jìn)行互訪。這是一些傳統(tǒng)的虛擬化廠商目前的做法。目前比較成熟的實(shí)現(xiàn)有Redhad的Kubevirt。
輕量級(jí)虛擬機(jī)。解決虛擬機(jī)鏡像過(guò)于龐大，啟動(dòng)慢，耗費(fèi)資源大的問(wèn)題，業(yè)界提出了輕量級(jí)虛擬機(jī)的解決方案。輕量級(jí)虛擬機(jī)使用精簡(jiǎn)專屬的庫(kù)操作系統(tǒng)(LibraryOS)，它能夠使用高級(jí)語(yǔ)言編譯并直接運(yùn)行在商用云平臺(tái)虛擬機(jī)管理程序之上。相比于容器技術(shù)它們有很多的優(yōu)點(diǎn)，不僅僅有著媲美虛擬機(jī)的隔離能力，而且有更快的啟動(dòng)時(shí)間和更小的攻擊面。輕量級(jí)虛擬機(jī)的由于使用了專屬的操作系統(tǒng)，在語(yǔ)言支持和兼容性上都不如其他解決方案。目前輕量級(jí)虛擬機(jī)的技術(shù)有很多，例如Unikernel，Drawbridge,MirageOS和HaLVM等。
安全容器，或是叫沙箱容器。為了解決容器的隔離性上的弱點(diǎn)，安全容器為容器的運(yùn)行提供了一層沙箱（Sandbox），容器在沙箱中運(yùn)行的應(yīng)用程序有自己的內(nèi)核和虛擬設(shè)備，與主機(jī)和其它沙箱區(qū)分開來(lái)。安全容器的優(yōu)點(diǎn)是可以兼容目前的容器鏡像，不需要對(duì)容器編排Kubernetes做出大的修改就可以直接應(yīng)用，缺點(diǎn)是犧牲了部分的性能和靈活度。目前安全容器的開源項(xiàng)目有Kata container，Google的gVisor等。
安全容器和輕量級(jí)虛擬機(jī)的實(shí)現(xiàn)上，可能會(huì)有一些重疊，但是不管哪一個(gè)方向，都是向著虛擬機(jī)和容器融合這個(gè)大的方向發(fā)展。目標(biāo)都是在發(fā)揮容器的輕量級(jí)，快速交付和靈活調(diào)度能力的同時(shí)，提升業(yè)務(wù)應(yīng)用的隔離性和安全性。
三．綜述
云原生技術(shù)是目前技術(shù)階段，企業(yè)IT系統(tǒng)的最優(yōu)模式的集合。企業(yè)通過(guò)遵循云原生的技術(shù)和設(shè)計(jì)模式，可以充分發(fā)揮云計(jì)算平臺(tái)的優(yōu)勢(shì)的同時(shí)，可以最大限度的減少對(duì)開發(fā)效率的影響，實(shí)現(xiàn)穩(wěn)定而高效的系統(tǒng)。技術(shù)是不斷發(fā)展的，云原生技術(shù)也是一個(gè)不斷更新迭代的過(guò)程，相應(yīng)的開發(fā)習(xí)慣和方法也會(huì)跟著改變。
