淺談云原生—從概念到趨勢(shì)

作者：翊君xzy 2022-05-25 16:32:36

云計(jì)算

云原生 云原生（Cloud Native），從字面上理解就是云計(jì)算和土著的意思—云計(jì)算上的原住民。

創(chuàng)新互聯(lián)公司主營(yíng)淮安區(qū)網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,成都app軟件開(kāi)發(fā),淮安區(qū)h5重慶小程序開(kāi)發(fā)公司搭建,淮安區(qū)網(wǎng)站營(yíng)銷(xiāo)推廣歡迎淮安區(qū)等地區(qū)企業(yè)咨詢

??想了解更多關(guān)于開(kāi)源的內(nèi)容，請(qǐng)?jiān)L問(wèn)：??

??51CTO 開(kāi)源基礎(chǔ)軟件社區(qū)??

閱讀完本文你將會(huì)

• 學(xué)到非常實(shí)用的云原生術(shù)語(yǔ)。
• 了解云原生是什么。
• 明白云原生的關(guān)鍵因素。
• 洞察2022年云原生的趨勢(shì)。

The Cloud isn’t a place, it’s a way of doing IT.

– Michael Dell, the founder of Dell Technologies.

1、 云原生是什么?

云原生(Cloud Native)，從字面上理解就是云計(jì)算和土著的意思——云計(jì)算上的原住民。

從Cloud來(lái)看，云可以看作是一種提供穩(wěn)定計(jì)算存儲(chǔ)資源的對(duì)象。為了實(shí)現(xiàn)這一點(diǎn)，云提供了虛擬化、彈性擴(kuò)展、高可用、高容錯(cuò)性、自恢復(fù)等基本屬性。

再看Native，云原生和在云上跑的傳統(tǒng)應(yīng)用不同。一些傳統(tǒng)應(yīng)用是基于SOA(Service-Oriented Architecture,面向服務(wù)架構(gòu))架構(gòu)來(lái)搭建的，然后再被放到云上。這些傳統(tǒng)應(yīng)用沒(méi)有充分運(yùn)用到云的優(yōu)勢(shì)。

因?yàn)樵谱鳛橐环N分布式架構(gòu)，它的原住民應(yīng)該也是要符合這一特性的——就像我們常說(shuō)的一方水土養(yǎng)一方人，如果水土不服那就會(huì)很糟糕!而微服務(wù)是具有分布式設(shè)計(jì)的屬性的。

其次云作為一種PaaS(Plarform as a Service, 平臺(tái)即服務(wù))服務(wù)，云上的原住民的整個(gè)生命周期都應(yīng)該是基于云的理念來(lái)實(shí)現(xiàn)的，那么就需要一套自動(dòng)化的開(kāi)發(fā)流程來(lái)實(shí)現(xiàn)。

這些是從字面上對(duì)Cloud Native的解構(gòu)，然后我們?cè)賮?lái)看看云原生計(jì)算基金會(huì)(Cloud Native Computing Foundation, CNCF)提供的官方定義：

Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

根據(jù)官方定義，我們總結(jié)下云原生就是：

• 基于容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式 API 構(gòu)建的可彈性擴(kuò)展的應(yīng)用。
• 基于自動(dòng)化技術(shù)構(gòu)建具備高容錯(cuò)性、易管理和便于觀察的松耦合系統(tǒng)。
• 構(gòu)建一個(gè)統(tǒng)一的開(kāi)源云技術(shù)生態(tài)，能和云廠商提供的服務(wù)解耦。

云原生是關(guān)于速度和敏捷性的。企業(yè)的業(yè)務(wù)系統(tǒng)正在從實(shí)現(xiàn)業(yè)務(wù)能力演變?yōu)榧铀贅I(yè)務(wù)速度和增長(zhǎng)的戰(zhàn)略轉(zhuǎn)型武器。

同時(shí)，隨著用戶的要求更多，業(yè)務(wù)系統(tǒng)也變得越來(lái)越復(fù)雜。它們更加期望快速的反應(yīng)能力，創(chuàng)新的功能，以及零停機(jī)。

性能問(wèn)題、重復(fù)性的錯(cuò)誤和無(wú)法快速迭代已不再被接受。當(dāng)出現(xiàn)上述這些情況，你的用戶將會(huì)訪問(wèn)你的競(jìng)爭(zhēng)對(duì)手。

2、云原生的關(guān)鍵因素

云原生的速度和敏捷性來(lái)自于許多因素。

本章我們將會(huì)講述其中最主要的六大因素。

（1）云架構(gòu)(Cloud Infrastructure)

云原生系統(tǒng)充分利用了云服務(wù)模式的優(yōu)勢(shì)。這些系統(tǒng)的設(shè)計(jì)目的是為了在動(dòng)態(tài)、虛擬化的云環(huán)境中茁壯成長(zhǎng)。它們廣泛使用PaaS的計(jì)算基礎(chǔ)設(shè)施和管理服務(wù)。它們將底層基礎(chǔ)設(shè)施視為一次性的-在幾分鐘內(nèi)完成配置，并通過(guò)自動(dòng)化按需調(diào)整、擴(kuò)展或銷(xiāo)毀。

在云原生領(lǐng)域，有一個(gè)類(lèi)比的概念叫做Pets vs. Cattle，字面理解的意思就是寵物 vs. 牛。

Pets-寵物

在傳統(tǒng)的數(shù)據(jù)中心，服務(wù)器被視為寵物：一臺(tái)物理機(jī)器，被賦予一個(gè)有意義的名字，并由你照顧。你通過(guò)向同一臺(tái)機(jī)器添加更多的資源來(lái)進(jìn)行擴(kuò)展。如果服務(wù)器生病了，你要照顧它直到恢復(fù)健康。

在這種模式下，服務(wù)器被視為不可缺少的系統(tǒng)組件，永遠(yuǎn)不可能停機(jī)。一般來(lái)說(shuō)，它們是人工建立、管理和手動(dòng)"喂養(yǎng)"的。這方面的例子包括大型機(jī)、單獨(dú)的服務(wù)器、HA(Highly Available,高可用)負(fù)載均衡器/防火墻、主/從數(shù)據(jù)庫(kù)系統(tǒng)等。

Cattle-牛

而Cattle的服務(wù)模式是不同的。你把每個(gè)實(shí)例作為一個(gè)虛擬機(jī)或容器來(lái)配置。它們是相同的，并分配給一個(gè)系統(tǒng)標(biāo)識(shí)符。你通過(guò)創(chuàng)建更多的實(shí)例來(lái)進(jìn)行擴(kuò)展。當(dāng)一個(gè)實(shí)例變得不可用時(shí)，沒(méi)有人注意到。

Cattle的模式使用不可改變的基礎(chǔ)設(shè)施。服務(wù)器不會(huì)被修復(fù)或修改。如果一個(gè)服務(wù)器出現(xiàn)故障或需要更新，它就會(huì)被銷(xiāo)毀，然后配置一個(gè)新的服務(wù)器。所有這些工作都通過(guò)自動(dòng)化完成。

由兩臺(tái)以上的服務(wù)器組成的陣列，一般使用自動(dòng)化工具構(gòu)建，陣列中沒(méi)有哪個(gè)服務(wù)器是不可替代的。通常情況下，故障事件不需要人工干預(yù)，因?yàn)殛嚵斜憩F(xiàn)出 "繞過(guò)故障"的屬性，通過(guò)重新啟動(dòng)故障服務(wù)器或通過(guò)三重復(fù)制或編碼擦除等策略復(fù)制數(shù)據(jù)。

這方面的例子包括網(wǎng)絡(luò)服務(wù)器陣列，多主機(jī)數(shù)據(jù)存儲(chǔ)，如Cassandra集群，以及幾乎所有的負(fù)載平衡和多主機(jī)。

（2）現(xiàn)代設(shè)計(jì)(Modern Design)

你會(huì)如何設(shè)計(jì)一個(gè)云原生應(yīng)用程序?你的架構(gòu)會(huì)是什么樣子的?你會(huì)遵守哪些原則、模式和最佳實(shí)踐?哪些基礎(chǔ)設(shè)施和操作問(wèn)題是重要的?

十二因素

如何構(gòu)建一個(gè)云應(yīng)用?業(yè)界廣泛接受的一個(gè)準(zhǔn)則就是十二因素。

12因素是一系列云原生應(yīng)用架構(gòu)的模式集合。這些模式可以用來(lái)說(shuō)明什么樣的應(yīng)用才是云原生應(yīng)用,可以用來(lái)衡量一個(gè)后端服務(wù)是否適合上云。

本節(jié)的反例并不是指技術(shù)本身不夠好，而是指它們的一些原生特性對(duì)于開(kāi)發(fā)復(fù)雜的應(yīng)用不夠友好。

CodeBase-基準(zhǔn)代碼

One codebase tracked in revision control, many deploys。

一份基準(zhǔn)代碼可以多份部署，可通過(guò)版本控制進(jìn)行追蹤。

反例：多個(gè)無(wú)關(guān)項(xiàng)目、數(shù)百萬(wàn)行代碼全部放到一個(gè)倉(cāng)庫(kù);對(duì)于差異需求，直接復(fù)制項(xiàng)目倉(cāng)庫(kù)單獨(dú)開(kāi)發(fā)，同時(shí)維護(hù)多個(gè)倉(cāng)庫(kù)代碼。

Dependencies-顯式和隔離的依賴

Explicitly declare and isolate dependencies。

每個(gè)微服務(wù)都可以顯式聲明依賴并且互不干擾，擁抱變化而不影響整個(gè)系統(tǒng)。

反例：Node.js之父Ryan Dahl另起爐灶創(chuàng)造了Deno，Deno的import遠(yuǎn)程代碼就是Node世界的npm反向極端，造成了隱式依賴;Golang在1.13之前沒(méi)有g(shù)o module的時(shí)候，也是違反這條原則的。且不說(shuō)不清晰的第三方依賴容易導(dǎo)致"投毒"，這對(duì)代碼的問(wèn)題定位、維護(hù)、交接都是很大的負(fù)擔(dān)。

Config-配置分離至環(huán)境

Store config in the environment。

配置數(shù)據(jù)和構(gòu)建產(chǎn)物完全分離，配置數(shù)據(jù)單獨(dú)管理，只在運(yùn)行環(huán)境中出現(xiàn)。

反例：環(huán)境相關(guān)的配置，混在容器鏡像、甚至代碼包中，每個(gè)環(huán)境需要單獨(dú)構(gòu)建打包一個(gè)版本。這種做法在傳統(tǒng)的開(kāi)發(fā)模式中很常見(jiàn)。

Backing Services-分離后端服務(wù)

Treat backing services as attached resources。

把后端服務(wù)當(dāng)作附加資源。后端服務(wù)是指程序運(yùn)行所需要的通過(guò)網(wǎng)絡(luò)調(diào)用的各種服務(wù)，包括數(shù)據(jù)庫(kù)，緩存，消息隊(duì)列等。

反例：把緩存服務(wù)和應(yīng)用服務(wù)打包到同一個(gè)容器鏡像，通過(guò)/var/redis.sock這樣的Domain Socket形式訪問(wèn);或者把第三方應(yīng)用服務(wù)的源碼直接復(fù)制到自己的代碼中，在一個(gè)進(jìn)程中互相調(diào)用。

Build, release, run-分離構(gòu)建、發(fā)布、運(yùn)行

Strictly separate build and run stages。

每個(gè)版本必須在構(gòu)建、發(fā)布和運(yùn)行階段實(shí)行嚴(yán)格的分離。每個(gè)版本都應(yīng)該被標(biāo)記為唯一的ID，并支持回滾的能力。CI/CD系統(tǒng)有助于實(shí)現(xiàn)這一原則。

反例：開(kāi)發(fā)改完代碼，本地打個(gè)Patch發(fā)給運(yùn)維，也不告知產(chǎn)品經(jīng)理改了什么，直接口頭告訴運(yùn)維批量更換某些文件。

Processes-無(wú)狀態(tài)的服務(wù)進(jìn)程

Execute the app as one or more stateless processes。

每個(gè)微服務(wù)應(yīng)該在自己的進(jìn)程中執(zhí)行，與其他正在運(yùn)行的服務(wù)隔離。如果存在狀態(tài)，應(yīng)該將狀態(tài)外置到后端服務(wù)中，例如數(shù)據(jù)庫(kù)、緩存等。

反例：應(yīng)用服務(wù)的多個(gè)實(shí)例之間互相通信，共享一些內(nèi)存數(shù)據(jù);或者開(kāi)發(fā)自治的集群選主、任務(wù)分發(fā)等功能。

Port Binding-端口綁定

Export services via port binding。

每個(gè)微服務(wù)都應(yīng)該是獨(dú)立的，其接口和功能都暴露在自己的端口上。這樣做提供了與其他微服務(wù)的隔離。

反例：提供出去部署的包的是放到Tomcat的war、放到IIS的dll，自己本身沒(méi)有描述通信協(xié)議，也沒(méi)有指定綁定的端口，完全依賴Tomcat/IIS的配置。

Concurrency-并發(fā)能力

Scale out via the process model。

通過(guò)進(jìn)程模型進(jìn)行擴(kuò)展，擴(kuò)展方式有進(jìn)程和線程兩種。進(jìn)程的方式使擴(kuò)展性更好，架構(gòu)更簡(jiǎn)單，隔離性更好。線程擴(kuò)展使編程更復(fù)雜，但是更節(jié)省資源。

反例：把Session放到內(nèi)存中。

Disposability-快速啟動(dòng)和優(yōu)雅終止的易處理

Maximize robustness with fast startup and graceful shutdown。

快速啟動(dòng)和優(yōu)雅終止可最大化健壯性，只有滿足快速啟動(dòng)和優(yōu)雅終止，才能使服務(wù)更健壯。

反例：很重的Java服務(wù)啟動(dòng)耗時(shí)十幾分鐘;縮容靠kill -9強(qiáng)殺進(jìn)程;服務(wù)也沒(méi)有實(shí)現(xiàn)收到SIGTERM信號(hào)進(jìn)入"跛腳鴨狀態(tài)"，也沒(méi)有等待請(qǐng)求處理完再關(guān)閉進(jìn)程。

Dev/prod parity-環(huán)境等同

Keep development, staging, and production as similar as possible。

盡可能地保持整個(gè)應(yīng)用生命周期的環(huán)境相似，包括開(kāi)發(fā)環(huán)境、預(yù)發(fā)布環(huán)境、線上環(huán)境等。

反例：開(kāi)發(fā)環(huán)境不容器化，產(chǎn)線容器化;開(kāi)發(fā)環(huán)境用的MariaDB，產(chǎn)線用的MySQL;開(kāi)發(fā)環(huán)境數(shù)據(jù)庫(kù)沒(méi)主從，產(chǎn)線配置了主從同步。這樣在MySQL讀寫(xiě)分離時(shí)，主從同步那幾毫秒的延遲導(dǎo)致各種奇怪Bug，在開(kāi)發(fā)環(huán)境也許永遠(yuǎn)都重現(xiàn)不出來(lái)。

Logs-作為事件流的日志

Treat logs as event streams。

將微服務(wù)產(chǎn)生的日志視為事件流。微服務(wù)架構(gòu)中服務(wù)數(shù)量的爆發(fā)需要具備調(diào)用鏈分析能力，快速定位故障。

反例：項(xiàng)目中寫(xiě)了一堆log4xx的復(fù)雜配置，日志文件存哪個(gè)路徑、多長(zhǎng)時(shí)間輪滾、保留多久刪除。傳統(tǒng)的軟件這是必備的，但云原生應(yīng)用，請(qǐng)僅保留打印到標(biāo)準(zhǔn)輸出/標(biāo)準(zhǔn)錯(cuò)誤。還有一個(gè)反模式的例子，在應(yīng)用內(nèi)就通過(guò)代碼把日志拋到Kafka這類(lèi)Broker中，無(wú)形中也讓?xiě)?yīng)用服務(wù)和Kafka耦合到了一起。

很多人不相信日志打印到stdout/stderr就完事了，是因?yàn)椴粔蛄私庠圃澜缰?，各?lèi)日志收集和處理組件的強(qiáng)大。我們對(duì)傳統(tǒng)的做法習(xí)以為常，卻忘記了"單一職責(zé)原則"。

Admin processes-分離管理類(lèi)任務(wù)

Run admin/management tasks as one-off processes。

把后臺(tái)管理任務(wù)當(dāng)作一次性進(jìn)程運(yùn)行，一些工具類(lèi)在生產(chǎn)環(huán)境上的操作可能是一次性的，因此最好把它們放在生產(chǎn)環(huán)境中執(zhí)行，而不是本地。

反例：在應(yīng)用服務(wù)運(yùn)行環(huán)境中安裝一個(gè)數(shù)據(jù)庫(kù)客戶端，運(yùn)維人員手動(dòng)跑一堆修改數(shù)據(jù)庫(kù)的SQL;或者安裝一些運(yùn)維腳本，放到機(jī)器的cron table定期執(zhí)行一些腳本。

3、微服務(wù)(MicroServices)

（1）微服務(wù)是什么?

微服務(wù)架構(gòu)是以開(kāi)發(fā)一組小型服務(wù)的方式來(lái)開(kāi)發(fā)一個(gè)獨(dú)立的應(yīng)用系統(tǒng)，每個(gè)服務(wù)都以一個(gè)獨(dú)立進(jìn)程的方式運(yùn)行，每個(gè)服務(wù)與其他服務(wù)使用輕量級(jí)(通常是 HTTP API)通信機(jī)制。

這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過(guò)全自動(dòng)部署機(jī)制獨(dú)立部署，同時(shí)服務(wù)會(huì)使用最小規(guī)模的集中管理(例如 Docker)能力，也可以采用不同的編程語(yǔ)言和數(shù)據(jù)庫(kù)。

如何確定微服務(wù)的顆粒度(Service granularity)，即如何定義這個(gè)"微"字?

對(duì)于這種問(wèn)題的沒(méi)有共識(shí)，因?yàn)檎_的答案取決于業(yè)務(wù)和組織背景。

把服務(wù)做得太小被認(rèn)為是不好的做法，因?yàn)槟菢拥脑?，運(yùn)行時(shí)的開(kāi)銷(xiāo)和操作的復(fù)雜性就會(huì)壓倒微服務(wù)的好處了。當(dāng)服務(wù)變得過(guò)于精細(xì)時(shí)，必須考慮其他的方法-比如將功能打包成一個(gè)庫(kù)，將功能轉(zhuǎn)移到其他微服務(wù)中。

所以微服務(wù)的"微"不能簡(jiǎn)單認(rèn)為是"小"的意思，我們可以理解為"合適"。

（2）微服務(wù)的優(yōu)勢(shì)

1. 云原生系統(tǒng)包含了微服務(wù)，微服務(wù)具有以下優(yōu)勢(shì)。
2. 由于組成服務(wù)的規(guī)模較小，它們可以從一開(kāi)始就由一個(gè)或多個(gè)小團(tuán)隊(duì)來(lái)構(gòu)建，并且劃分好服務(wù)邊界。這使得在需要時(shí)更容易擴(kuò)大開(kāi)發(fā)力度。
3. 一旦開(kāi)發(fā)完成，這些服務(wù)可以獨(dú)立部署，也很容易識(shí)別熱門(mén)服務(wù)，并將它們獨(dú)立于整個(gè)應(yīng)用進(jìn)行擴(kuò)展。
4. 微服務(wù)還提供了更好的故障隔離，在一個(gè)服務(wù)出錯(cuò)的情況下，整個(gè)應(yīng)用程序不一定會(huì)停止運(yùn)行。當(dāng)錯(cuò)誤被修復(fù)后，可以只為相應(yīng)的服務(wù)進(jìn)行部署，而不是重新部署整個(gè)應(yīng)用程序。
5. 微服務(wù)架構(gòu)帶來(lái)的另一個(gè)優(yōu)勢(shì)是更容易選擇最適合所需功能的技術(shù)棧(編程語(yǔ)言、數(shù)據(jù)庫(kù)等)，而不是被要求采取更標(biāo)準(zhǔn)化的、一刀切的方法。

下表展示了單體架構(gòu)和微服務(wù)架構(gòu)的對(duì)比：

（3）微服務(wù)的劣勢(shì)

事物都有兩面性，雖然微服務(wù)具有諸多的優(yōu)勢(shì)，但是我們也需要正視使用它帶來(lái)的挑戰(zhàn)。

復(fù)雜性

首先，服務(wù)之間的通信可能很復(fù)雜。一個(gè)應(yīng)用程序可能包括幾十個(gè)甚至幾百個(gè)不同的服務(wù)，而它們都需要安全地進(jìn)行通信。

其次，微服務(wù)的調(diào)試變得更具挑戰(zhàn)性。一個(gè)應(yīng)用程序由多個(gè)微服務(wù)組成，每個(gè)微服務(wù)都有自己的日志，追蹤問(wèn)題的來(lái)源可能很困難。

最后，微服務(wù)的設(shè)計(jì)、開(kāi)發(fā)、部署、測(cè)試會(huì)更加復(fù)雜。

接口控制

每個(gè)微服務(wù)都有自己的API，應(yīng)用程序依靠它來(lái)實(shí)現(xiàn)一致性。雖然你可以很容易地對(duì)一個(gè)微服務(wù)進(jìn)行修改而不影響與之交互的外部系統(tǒng)，但如果你改變了API(接口)，如果改變后不能向后兼容，任何使用該微服務(wù)的應(yīng)用程序都會(huì)受到影響。

微服務(wù)架構(gòu)模型導(dǎo)致了大量的API，這些API對(duì)企業(yè)的運(yùn)作都是至關(guān)重要的。因此接口控制變得至關(guān)重要。

成本上升

要使微服務(wù)架構(gòu)在企業(yè)中發(fā)揮作用，你需要有足夠的托管基礎(chǔ)設(shè)施，并有安全和維護(hù)支持，你還需要有熟練的開(kāi)發(fā)團(tuán)隊(duì)來(lái)理解和管理所有的服務(wù)。

如果你已經(jīng)有了這些東西，轉(zhuǎn)移到微服務(wù)所涉及的成本可能會(huì)更低。但大多數(shù)目前正在運(yùn)行單體架構(gòu)的企業(yè)將需要投資于新的基礎(chǔ)設(shè)施和開(kāi)發(fā)人員資源，以便進(jìn)行轉(zhuǎn)移。

4、容器(Containers)

（1）容器是什么

Containers are a great enabler of cloud-native software.

《Cloud Native Patterns》的作者Cornelia Davis說(shuō)，“容器是一個(gè)偉大的云原生推動(dòng)者”。

而云原生計(jì)算基金會(huì)也將微服務(wù)容器化作為指導(dǎo)企業(yè)實(shí)現(xiàn)云原生藍(lán)圖的第一步。

容器是一種操作系統(tǒng)虛擬化形式?？梢允褂靡粋€(gè)容器來(lái)運(yùn)行從小型微服務(wù)或軟件進(jìn)程到大型應(yīng)用程序的所有內(nèi)容。

容器包含所有必要的可執(zhí)行文件、二進(jìn)制代碼、庫(kù)和配置文件。但是，與服務(wù)器或計(jì)算機(jī)虛擬化方法不同，容器不包含操作系統(tǒng)映像。因此，它們更輕便且可移植，其開(kāi)銷(xiāo)很小。

容器化一個(gè)微服務(wù)并不難，你只需要將軟件代碼和所需要的所有組件(例如庫(kù)、框架和其他依賴項(xiàng))打包成一個(gè)二進(jìn)制文件——容器鏡像。鏡像存儲(chǔ)在容器的注冊(cè)表中，而注冊(cè)表可以位于你的計(jì)算機(jī)上，在你的數(shù)據(jù)中心，或在一個(gè)公共云上。

當(dāng)一個(gè)應(yīng)用程序啟動(dòng)或擴(kuò)展時(shí)，你會(huì)將容器鏡像轉(zhuǎn)化為一個(gè)正在運(yùn)行的容器實(shí)例。該實(shí)例在任何安裝了容器運(yùn)行時(shí)引擎的計(jì)算機(jī)上運(yùn)行。你可以根據(jù)需要決定擁有多少個(gè)容器化服務(wù)的實(shí)例。

下圖顯示了三個(gè)不同的微服務(wù)，每個(gè)微服務(wù)都在自己的容器中，并且都在同一臺(tái)主機(jī)上運(yùn)行。

圖.容器

每個(gè)容器是單獨(dú)維護(hù)自己的依賴關(guān)系和運(yùn)行時(shí)間集的，它們可能彼此不同。從圖上我們可以看出，不同版本的產(chǎn)品微服務(wù)是在同一個(gè)主機(jī)上運(yùn)行的。

每個(gè)容器共享主機(jī)操作系統(tǒng)、內(nèi)存和處理器，但是彼此是隔離的。這里很好地體現(xiàn)了上文中12因素的依賴性原則。

（2）容器的優(yōu)勢(shì)

輕量級(jí)、可移植性

在容器中運(yùn)行的應(yīng)用程序可以輕松部署到多個(gè)不同的操作系統(tǒng)和硬件平臺(tái)。它們能夠共享主機(jī)的操作系統(tǒng)內(nèi)核，不需要為每個(gè)容器提供單獨(dú)的操作系統(tǒng)，且允許應(yīng)用在任何基礎(chǔ)架構(gòu)(裸機(jī)、云)上運(yùn)行相同的操作系統(tǒng)，甚至在虛擬機(jī)(VM)中。

成本降低

與傳統(tǒng)或硬件虛擬機(jī)環(huán)境相比，容器所需的系統(tǒng)資源更少，因?yàn)樗鼈儾话僮飨到y(tǒng)映像。

改善了應(yīng)用程序的開(kāi)發(fā)

開(kāi)發(fā)人員在一個(gè)主機(jī)環(huán)境中使用容器時(shí)，可以像在另一個(gè)主機(jī)環(huán)境中一樣使用相同的工具，如此，在各個(gè)操作系統(tǒng)間開(kāi)發(fā)和部署容器化應(yīng)用就變得更加簡(jiǎn)單。而且容器支持敏捷的 DevOps工作，以加速開(kāi)發(fā)測(cè)試并縮短生產(chǎn)周期。

容器 vs 虛擬機(jī)

虛擬機(jī)(VM)是一種創(chuàng)建于物理硬件系統(tǒng)(位于外部或內(nèi)部)、充當(dāng)虛擬計(jì)算機(jī)系統(tǒng)的虛擬環(huán)境，它模擬出了自己的整套硬件，包括 CPU、內(nèi)存、網(wǎng)絡(luò)接口和存儲(chǔ)器。

容器化和虛擬化的相似之處在于它們都允許應(yīng)用完全隔離，以便在多個(gè)環(huán)境中運(yùn)行。而它們的主要區(qū)別在于尺寸大小和可移植性。

虛擬機(jī)在兩者中尺寸較大，通常以千兆字節(jié)為度量單位，且包含它們自己的操作系統(tǒng)，所以可以同時(shí)執(zhí)行多個(gè)資源密集型功能。由于虛擬機(jī)的可用資源大大增加，因此它們可以抽象、分離、復(fù)制和模擬整個(gè)服務(wù)器、操作系統(tǒng)、臺(tái)式機(jī)、數(shù)據(jù)庫(kù)和網(wǎng)絡(luò)。

容器則要小得多，通常以兆字節(jié)為度量單位，且其中僅包含應(yīng)用及其運(yùn)行環(huán)境。

虛擬機(jī)高度兼容傳統(tǒng)的單體式 IT 架構(gòu)，容器則兼容更新的新興技術(shù)，例如云、CI/CD(Continuous Delivery,持續(xù)交付;Continuous Deployment，持續(xù)部署) 和 DevOps。

由于容器的特性，微服務(wù)和容器可以很好地協(xié)同工作，因?yàn)槿萜髦械奈⒎?wù)具有容器的所有的可移植性、兼容性和可擴(kuò)展性。

（3）容器編排(Container orchestration)

雖然像Docker這樣的工具可以創(chuàng)建鏡像和運(yùn)行容器，但是你也需要工具來(lái)管理它們。我們可以使用容器編排工具來(lái)完成容器的部署、管理、擴(kuò)展以及聯(lián)網(wǎng)。容器編排可以為需要部署和管理成百上千個(gè)容器和主機(jī)的企業(yè)提供便利。

那么容器編排到底做了什么呢?

• Scheduling-任務(wù)安排。

自動(dòng)提供容器實(shí)例：

• Affinity/anti-affinity-親和/反親和。
• Health monitorinh-健康檢測(cè)。

自動(dòng)檢測(cè)和糾正故障。

• Failover-故障轉(zhuǎn)移。

自動(dòng)將一個(gè)失敗的實(shí)例重置到一個(gè)健康的機(jī)器上。

• Scaling-自動(dòng)擴(kuò)展。

自動(dòng)添加或刪除一個(gè)容器實(shí)例以滿足需求。

• Networking-聯(lián)網(wǎng)。

管理用于容器通信的網(wǎng)絡(luò)層。

• Service Discovery-服務(wù)發(fā)現(xiàn)。

使容器能夠相互定位。

• Rolling Upgrades-滾動(dòng)更新。

協(xié)調(diào)增量升級(jí)，實(shí)現(xiàn)零停機(jī)部署，自動(dòng)回滾有問(wèn)題的更新。

我們可以發(fā)現(xiàn)容器編排體現(xiàn)了12因素中的易處理原則和并發(fā)性原則。

5、后端服務(wù)-Backing services

圖.后端服務(wù)

App在運(yùn)行過(guò)程中通過(guò)網(wǎng)絡(luò)消費(fèi)的任何服務(wù)都可以稱為后端服務(wù)。在傳統(tǒng)的操作系統(tǒng)中，這些服務(wù)可以通過(guò)網(wǎng)絡(luò)、UNIX套接字訪問(wèn)，甚至可以是一個(gè)子進(jìn)程。例子包括并不限于：

• 數(shù)據(jù)庫(kù)(MySQL，PostgreSQL)。
• 消息隊(duì)列(Kafka, RabbitMQ)。
• 文件存儲(chǔ)(NFS，F(xiàn)TP)。
• 日志服務(wù)。
• 緩存系統(tǒng)。
• SMTP服務(wù)。

你可以管理自己的后端服務(wù)，也可以讓云廠商代管。云廠商提供豐富的后端服務(wù)，你無(wú)需擁有該服務(wù)，而是可以直接消費(fèi)。

云廠商操作大規(guī)模的資源，并承擔(dān)性能、安全和維護(hù)的責(zé)任。云原生系統(tǒng)傾向于云廠商提供的后端服務(wù)。在這方面，我們可以在時(shí)間和勞動(dòng)力上節(jié)約很多。如果是自己托管，那么遇到的運(yùn)行風(fēng)險(xiǎn)會(huì)比較麻煩。

最佳實(shí)踐是將后端服務(wù)視為附加資源，動(dòng)態(tài)地與微服務(wù)綁定，而配置信息存儲(chǔ)在外部配置中。這一原則在上文的12因素中得到了闡述。

12因素中的因素4規(guī)定，后端服務(wù)應(yīng)該通過(guò)一個(gè)URL暴露，這樣做可以使資源和應(yīng)用脫鉤，使其可以互換。

因素3規(guī)定，配置信息應(yīng)該被移出微服務(wù)，并通過(guò)代碼外的配置管理工具實(shí)現(xiàn)外部化。

后端服務(wù)也體現(xiàn)了12因素中"無(wú)狀態(tài)的服務(wù)進(jìn)程"原則，把依賴的服務(wù)分離出去，一些應(yīng)用服務(wù)已經(jīng)可以實(shí)現(xiàn)"無(wú)狀態(tài)"了。

但有時(shí)候，還需要對(duì)應(yīng)用內(nèi)部做一些改造才能實(shí)現(xiàn)無(wú)狀態(tài)。無(wú)狀態(tài)是水平擴(kuò)展的前提，對(duì)于Serverless應(yīng)用更是必要條件。

6、自動(dòng)化(Automation)

如你所見(jiàn)，云原生采用微服務(wù)以及容器化技術(shù)以實(shí)現(xiàn)它的速度和敏捷性。但是這還遠(yuǎn)遠(yuǎn)不夠，你如何配置這些系統(tǒng)所運(yùn)行的云環(huán)境?如何快速部署應(yīng)用程序的功能和更新?

我們先來(lái)了解下IaC(Infrastructure as Code,基礎(chǔ)設(shè)施即代碼)的概念。

基礎(chǔ)設(shè)施即代碼 (IaC) 指的是通過(guò)代碼而不是手動(dòng)流程來(lái)管理和配置基礎(chǔ)設(shè)施。IaC 有時(shí)也稱為"可編程基礎(chǔ)設(shè)施"，可將基礎(chǔ)設(shè)施配置完全當(dāng)作軟件編程來(lái)進(jìn)行。

IaC 協(xié)助將基礎(chǔ)設(shè)施管理從數(shù)據(jù)中心內(nèi)的物理硬件過(guò)渡到虛擬化、容器和云計(jì)算。對(duì)于 IaC、網(wǎng)絡(luò)、虛擬機(jī)、負(fù)載平衡器和連接拓?fù)涠际褂酶呒?jí)語(yǔ)言進(jìn)行編碼，將應(yīng)用開(kāi)發(fā)所依靠的環(huán)境標(biāo)準(zhǔn)化。

完成編碼后，DevOps 能夠啟動(dòng)、拆解和擴(kuò)展基礎(chǔ)設(shè)施，以響應(yīng)不斷波動(dòng)的需求。這樣的敏捷性能夠造就更快、更簡(jiǎn)單的軟件開(kāi)發(fā)、測(cè)試和部署。

（1）基礎(chǔ)設(shè)施自動(dòng)化(Infrastructure Automation)

我們可以使用特定的工具(比如Azure Bicep)來(lái)對(duì)所需要的云基礎(chǔ)設(shè)施進(jìn)行聲明性的編寫(xiě)。資源的名稱、位置、容量都是參數(shù)化和動(dòng)態(tài)的。你編寫(xiě)的腳本會(huì)受到版本控制。調(diào)用該腳本即可在不同的系統(tǒng)環(huán)境中配置一致的，重復(fù)性的基礎(chǔ)設(shè)施。

你可以重復(fù)運(yùn)行同一個(gè)腳本而不產(chǎn)生副作用。如果團(tuán)隊(duì)想更新資源，他們可以編輯并重新運(yùn)行腳本。

在《什么是基礎(chǔ)設(shè)施即代碼》一文中，作者Sam Guckenheimer描述道：“實(shí)施IaC的團(tuán)隊(duì)可以快速、大規(guī)模地交付穩(wěn)定的環(huán)境。他們避免手動(dòng)配置環(huán)境，并通過(guò)代碼來(lái)保證理想環(huán)境的一致性。采用IaC的基礎(chǔ)設(shè)施部署是可重復(fù)的，可以防止因配置漂移(Configuration Drift)或依賴性缺失而導(dǎo)致的運(yùn)行問(wèn)題。DevOps團(tuán)隊(duì)可以使用一套統(tǒng)一的實(shí)踐和工具來(lái)快速、可靠和大規(guī)模地交付應(yīng)用程序及其支持的基礎(chǔ)設(shè)施。”

（2）部署自動(dòng)化(Deployment Automation)

前面的12因素中的因素5提到，每個(gè)版本必須在構(gòu)建、發(fā)布和運(yùn)行階段實(shí)行嚴(yán)格的分離。每個(gè)版本都應(yīng)該被標(biāo)記為唯一的ID，并支持回滾的能力。

為什么要強(qiáng)調(diào)"構(gòu)建、發(fā)布、運(yùn)行"三個(gè)階段一定要分離開(kāi)來(lái)呢?

有兩個(gè)好處：

職責(zé)和關(guān)注點(diǎn)的分離。構(gòu)建是開(kāi)發(fā)測(cè)試人員更關(guān)注的、發(fā)布是產(chǎn)品經(jīng)理更關(guān)注的、運(yùn)行是運(yùn)維更關(guān)注的;

流水線模式帶來(lái)的效率提升，以及各階段之間的緩沖空間，每個(gè)階段有專門(mén)的工具和方法論。

怎么做到這三個(gè)階段的分離呢?流水線的運(yùn)行不是靠人力保障的，自動(dòng)化系統(tǒng)很重要。

CI/CD系統(tǒng)有助于實(shí)現(xiàn)這一原則。它們提供獨(dú)立的構(gòu)建和交付步驟，幫助確保一致的、高質(zhì)量的代碼，并可隨時(shí)提供給用戶。

1. 開(kāi)發(fā)者在開(kāi)發(fā)環(huán)境中開(kāi)發(fā)了一個(gè)功能，通過(guò)代碼、運(yùn)行和調(diào)試的"內(nèi)循環(huán)"進(jìn)行迭代。
2. 完成后，這些代碼被推送到代碼庫(kù)中，如GitHub或BitBucket。
3. 然后CI自動(dòng)構(gòu)建、測(cè)試和打包應(yīng)用程序。
4. 到了發(fā)布階段，CD系統(tǒng)將打好的包，外部應(yīng)用和環(huán)境配置信息合成一個(gè)不可變的版本。該版本被部署到一個(gè)指定的環(huán)境中。每個(gè)版本都應(yīng)該是可識(shí)別的。
5. 最后，發(fā)布的功能在生產(chǎn)環(huán)境中運(yùn)行。

使用這些技術(shù)，企業(yè)已經(jīng)從根本上改變了他們發(fā)布軟件的方式。許多企業(yè)已經(jīng)從每季度一次的發(fā)布轉(zhuǎn)變?yōu)榘葱韪隆?/p>

以上就是云原生的六大關(guān)鍵因素了，下面讓我們來(lái)看看云原生在2022年的新趨勢(shì)。

3、云原生的趨勢(shì)

在過(guò)去幾年中，IT行業(yè)見(jiàn)證了云原生技術(shù)的指數(shù)級(jí)增長(zhǎng)。當(dāng)我們來(lái)到2022年，我們需要關(guān)注以下五個(gè)關(guān)鍵的云原生趨勢(shì)。

1、WebAssembly在云原生環(huán)境中的崛起

WebAssembly已經(jīng)發(fā)展成為一個(gè)高性能、跨平臺(tái)、多語(yǔ)言的軟件沙盒環(huán)境，可用于云原生軟件的組件。鑒于容器運(yùn)行時(shí)和WebAssembly(WASM)之間驚人的相似性，Kubernetes可用于協(xié)調(diào)WASM組件。

WasmCloud、WasmEdge、KubeEdge和Krustlet等項(xiàng)目使WASM成為云原生宇宙的一等公民。

將打包成WebAssembly的軟件與容器化軟件一起運(yùn)行是極有可能的。Kubernetes可以無(wú)縫地協(xié)調(diào)這兩種組件。

2、云原生安全

隨著網(wǎng)絡(luò)安全越來(lái)越被重視，云原生安全在2022年也會(huì)受到更多的關(guān)注。

有兩個(gè)領(lǐng)域會(huì)獲得更多的關(guān)注——軟件供應(yīng)鏈和eBPF(Extended Berkeley Packet Filter)

軟件供應(yīng)鏈

軟件供應(yīng)鏈類(lèi)似于現(xiàn)實(shí)世界中的商業(yè)供應(yīng)鏈。資源被消耗，然后通過(guò)一系列的步驟和過(guò)程進(jìn)行轉(zhuǎn)化，最后提供給客戶。

現(xiàn)代的軟件開(kāi)發(fā)是將公共領(lǐng)域中的各種組件作為開(kāi)放源碼項(xiàng)目進(jìn)行組裝和整合。在復(fù)雜的軟件供應(yīng)鏈中，一個(gè)被破壞的軟件會(huì)對(duì)多個(gè)部署造成嚴(yán)重?fù)p害。所以務(wù)必要保證軟件供應(yīng)鏈的安全性。

eBPF

另一個(gè)令人興奮的趨勢(shì)是eBPF，它使云原生開(kāi)發(fā)人員能夠構(gòu)建安全的網(wǎng)絡(luò)、服務(wù)網(wǎng)和可觀察性組件。

3、Kubevirt走向主流

Kubevirt是一個(gè)開(kāi)源項(xiàng)目，它使得Kubernetes能夠像容器一樣協(xié)調(diào)虛擬機(jī)。

通過(guò)運(yùn)行虛擬機(jī)和容器，我們可以輕松地將傳統(tǒng)的工作負(fù)載與基于微服務(wù)的應(yīng)用程序整合起來(lái)。

2022年，我們將看到Kubevirt與Kubernetes的應(yīng)用整合急劇上升。

4、GitOps成為持續(xù)部署的標(biāo)準(zhǔn)

GitOps為云原生工作負(fù)載的發(fā)布管理帶來(lái)了熟悉的基于Git的工作流程。通過(guò)將Git作為單一可信來(lái)源來(lái)控制狀態(tài)，加上快速回滾的能力，使GitOps成為一個(gè)強(qiáng)大的機(jī)制。

2022年，GitOps將發(fā)展到支持多租戶和多集群部署，使其能夠輕松管理數(shù)萬(wàn)個(gè)Kubernetes集群。也許GitOps將成為持續(xù)部署的黃金標(biāo)準(zhǔn)。

5、混合云和多云的架構(gòu)

混合云服務(wù)可以將各方的優(yōu)勢(shì)結(jié)合在一起。需要快速和頻繁訪問(wèn)的數(shù)據(jù)可以保存在公共服務(wù)器上，而更敏感的數(shù)據(jù)可以保存在有監(jiān)控訪問(wèn)的私人服務(wù)器上。一個(gè)良好的整合和平衡的混合云戰(zhàn)略給企業(yè)帶來(lái)了兩個(gè)世界的最佳效果。

而多云模式可以幫助企業(yè)選擇最適合其個(gè)人應(yīng)用環(huán)境、業(yè)務(wù)要求和可用性需求的不同云產(chǎn)品。展望未來(lái)，更多的企業(yè)將需要開(kāi)發(fā)完全云原生的應(yīng)用程序，幾乎沒(méi)有架構(gòu)上對(duì)任何特定云廠商的依賴。

盡管很多大型企業(yè)已經(jīng)采用混合云和多云戰(zhàn)略作為標(biāo)準(zhǔn)，但2022年將見(jiàn)證更多企業(yè)認(rèn)識(shí)到這些模式的優(yōu)勢(shì)，并接受它們，以享受云的彈性和敏捷性。

新聞標(biāo)題：淺談云原生—從概念到趨勢(shì)
文章URL：http://m.fisionsoft.com.cn/article/cdcoesj.html