image

0. 閱讀完本文你將學到

• 非常實用的云原生術(shù)語
• 云原生是什么
• 云原生的關(guān)鍵因素
• 2022年云原生的趨勢

本文大概1W字颜说，閱讀時長大概30分鐘。來一首

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

-- Michael Dell, the founder of Dell Technologies.

1. 云原生的定義

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

從Cloud來看丹弱，云可以看作是一種提供穩(wěn)定計算存儲資源的對象。為了實現(xiàn)這一點贡翘，云提供了虛擬化蹈矮、彈性擴展砰逻、高可用鸣驱、高容錯性、自恢復(fù)等基本屬性蝠咆。

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

因為云作為一種分布式架構(gòu)，它的原住民應(yīng)該也是要符合這一特性的——就像我們常說的一方水土養(yǎng)一方人坚冀，如果水土不服那就會很糟糕济赎！而微服務(wù)是具有分布式設(shè)計的屬性的。

其次云作為一種PaaS（Plarform as a Service, 平臺即服務(wù)）服務(wù)记某，云上的原住民的整個生命周期都應(yīng)該是基于云的理念來實現(xiàn)的司训，那么就需要一套自動化的開發(fā)流程來實現(xiàn)。

這些是從字面上對Cloud Native的解構(gòu)液南，然后我們再來看看云原生計算基金會(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)建的可彈性擴展的應(yīng)用。

• 基于自動化技術(shù)構(gòu)建具備高容錯性畅姊、易管理和便于觀察的松耦合系統(tǒng)咒钟。

• 構(gòu)建一個統(tǒng)一的開源云技術(shù)生態(tài)，能和云廠商提供的服務(wù)解耦涡匀。

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

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

性能問題甚淡、重復(fù)性的錯誤和無法快速迭代已不再被接受大诸。當出現(xiàn)上述這些情況，你的用戶將會訪問你的競爭對手贯卦。

image

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

云原生的速度和敏捷性來自于許多因素。

本章我們將會講述其中最主要的六大因素撵割。

image

圖2.云原生的六大關(guān)鍵因素

其中贿堰，很明顯的最重要的就是云架構(gòu)。

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

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

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

image

1. Pets-寵物

在傳統(tǒng)的數(shù)據(jù)中心利职，服務(wù)器被視為寵物：一臺物理機器惑灵，被賦予一個有意義的名字，并由你照顧眼耀。你通過向同一臺機器添加更多的資源來進行擴展英支。如果服務(wù)器生病了，你要照顧它直到恢復(fù)健康哮伟。

在這種模式下干花，服務(wù)器被視為不可缺少的系統(tǒng)組件，永遠不可能停機楞黄。一般來說池凄，它們是人工建立、管理和手動"喂養(yǎng)"的鬼廓。這方面的例子包括大型機肿仑、單獨的服務(wù)器、HA（Highly Available,高可用）負載均衡器/防火墻碎税、主/從數(shù)據(jù)庫系統(tǒng)等尤慰。

2. Cattle-牛

而Cattle的服務(wù)模式是不同的。你把每個實例作為一個虛擬機或容器來配置雷蹂。它們是相同的伟端，并分配給一個系統(tǒng)標識符。你通過創(chuàng)建更多的實例來進行擴展匪煌。當一個實例變得不可用時责蝠，沒有人注意到。

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

由兩臺以上的服務(wù)器組成的陣列达舒，一般使用自動化工具構(gòu)建值朋，陣列中沒有哪個服務(wù)器是不可替代的。通常情況下巩搏，故障事件不需要人工干預(yù)昨登，因為陣列表現(xiàn)出 "繞過故障"的屬性，通過重新啟動故障服務(wù)器或通過三重復(fù)制或編碼擦除等策略復(fù)制數(shù)據(jù)贯底。

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

2.2 現(xiàn)代設(shè)計（Modern Design）

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

帶著這些疑問來看看本節(jié)统屈。

2.2.1 十二因素

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

image

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

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

1. CodeBase-基準代碼

One codebase tracked in revision control, many deploys

一份基準代碼可以多份部署，可通過版本控制進行追蹤脓恕。

反例：多個無關(guān)項目膜宋、數(shù)百萬行代碼全部放到一個倉庫；對于差異需求炼幔，直接復(fù)制項目倉庫單獨開發(fā)激蹲，同時維護多個倉庫代碼。

2. Dependencies-顯式和隔離的依賴

Explicitly declare and isolate dependencies

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

反例：Node.js之父Ryan Dahl另起爐灶創(chuàng)造了Deno，Deno的import遠程代碼就是Node世界的npm反向極端环形，造成了隱式依賴策泣；Golang在1.13之前沒有g(shù)o module的時候，也是違反這條原則的抬吟。且不說不清晰的第三方依賴容易導(dǎo)致"投毒"萨咕，這對代碼的問題定位、維護火本、交接都是很大的負擔危队。

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

Store config in the environment

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

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

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

Treat backing services as attached resources

把后端服務(wù)當作附加資源桨醋。后端服務(wù)是指程序運行所需要的通過網(wǎng)絡(luò)調(diào)用的各種服務(wù)棚瘟，包括數(shù)據(jù)庫，緩存喜最，消息隊列等偎蘸。

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

5. Build, release, run-分離構(gòu)建遂鹊、發(fā)布振乏、運行

Strictly separate build and run stages

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

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

6. Processes-無狀態(tài)的服務(wù)進程

Execute the app as one or more stateless processes

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

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

7. Port Binding-端口綁定

Export services via port binding

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

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

8. Concurrency-并發(fā)能力

Scale out via the process model

通過進程模型進行擴展，擴展方式有進程和線程兩種蔬浙。進程的方式使擴展性更好猪落，架構(gòu)更簡單，隔離性更好畴博。線程擴展使編程更復(fù)雜笨忌，但是更節(jié)省資源。

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

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

Maximize robustness with fast startup and graceful shutdown

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

反例：很重的Java服務(wù)啟動耗時十幾分鐘途凫；縮容靠kill -9強殺進程；服務(wù)也沒有實現(xiàn)收到SIGTERM信號進入"跛腳鴨狀態(tài)"溢吻，也沒有等待請求處理完再關(guān)閉進程维费。

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

Keep development, staging, and production as similar as possible

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

反例：開發(fā)環(huán)境不容器化蝇狼，產(chǎn)線容器化阅畴；開發(fā)環(huán)境用的MariaDB，產(chǎn)線用的MySQL迅耘；開發(fā)環(huán)境數(shù)據(jù)庫沒主從贱枣，產(chǎn)線配置了主從同步。這樣在MySQL讀寫分離時颤专，主從同步那幾毫秒的延遲導(dǎo)致各種奇怪Bug冯事，在開發(fā)環(huán)境也許永遠都重現(xiàn)不出來。

11. Logs-作為事件流的日志

Treat logs as event streams

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

反例：項目中寫了一堆log4xx的復(fù)雜配置，日志文件存哪個路徑摔笤、多長時間輪滾够滑、保留多久刪除。傳統(tǒng)的軟件這是必備的吕世，但云原生應(yīng)用彰触，請僅保留打印到標準輸出/標準錯誤。還有一個反模式的例子命辖，在應(yīng)用內(nèi)就通過代碼把日志拋到Kafka這類Broker中况毅，無形中也讓應(yīng)用服務(wù)和Kafka耦合到了一起。

很多人不相信日志打印到stdout/stderr就完事了尔艇，是因為不夠了解云原生世界中尔许，各類日志收集和處理組件的強大。我們對傳統(tǒng)的做法習以為常终娃，卻忘記了"單一職責原則"味廊。

12. Admin processes-分離管理類任務(wù)

Run admin/management tasks as one-off processes

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

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

當然红氯，國外也有作者提出除了這十二個因素之外，云應(yīng)用設(shè)計還應(yīng)該受到下面三個額外因素影響咕痛。

13. API First-API優(yōu)先

讓一切成為服務(wù)痢甘。

14. Telemetry-可預(yù)測性

確保你的設(shè)計包括監(jiān)測、特定領(lǐng)域茉贡、健康數(shù)據(jù)以及系統(tǒng)數(shù)據(jù)的收集塞栅。

15. Authentication/Authorization-認證、授權(quán)

從一開始就進行身份識別腔丧。比如RBAC（role-based access control, 基于角色的訪問控制）功能放椰。

2.3 微服務(wù)(MicroServices)

2.3.1 微服務(wù)是什么？

微服務(wù)架構(gòu)是以開發(fā)一組小型服務(wù)的方式來開發(fā)一個獨立的應(yīng)用系統(tǒng)愉粤，每個服務(wù)都以一個獨立進程的方式運行砾医，每個服務(wù)與其他服務(wù)使用輕量級（通常是 HTTP API）通信機制。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的衣厘，可以通過全自動部署機制獨立部署如蚜，同時服務(wù)會使用最小規(guī)模的集中管理（例如 Docker）能力压恒，也可以采用不同的編程語言和數(shù)據(jù)庫。

如何確定微服務(wù)的顆粒度（Service granularity）错邦，即如何定義這個"微"字探赫？

對于這種問題的沒有共識，因為正確的答案取決于業(yè)務(wù)和組織背景撬呢。

把服務(wù)做得太小被認為是不好的做法伦吠，因為那樣的話，運行時的開銷和操作的復(fù)雜性就會壓倒微服務(wù)的好處了魂拦。當服務(wù)變得過于精細時毛仪，必須考慮其他的方法-比如將功能打包成一個庫，將功能轉(zhuǎn)移到其他微服務(wù)中芯勘。

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

2.3.2 微服務(wù)的優(yōu)勢

云原生系統(tǒng)包含了微服務(wù)借尿，微服務(wù)具有以下優(yōu)勢刨晴。

1. 由于組成服務(wù)的規(guī)模較小屉来，它們可以從一開始就由一個或多個小團隊來構(gòu)建路翻，并且劃分好服務(wù)邊界。這使得在需要時更容易擴大開發(fā)力度茄靠。

2. 一旦開發(fā)完成茂契，這些服務(wù)可以獨立部署，也很容易識別熱門服務(wù)慨绳，并將它們獨立于整個應(yīng)用進行擴展掉冶。

3. 微服務(wù)還提供了更好的故障隔離，在一個服務(wù)出錯的情況下脐雪，整個應(yīng)用程序不一定會停止運行厌小。當錯誤被修復(fù)后，可以只為相應(yīng)的服務(wù)進行部署战秋，而不是重新部署整個應(yīng)用程序璧亚。

4. 微服務(wù)架構(gòu)帶來的另一個優(yōu)勢是更容易選擇最適合所需功能的技術(shù)棧（編程語言、數(shù)據(jù)庫等）脂信，而不是被要求采取更標準化的癣蟋、一刀切的方法。

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

2.3.3 微服務(wù)的劣勢

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

1. 復(fù)雜性

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

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

最后民假，微服務(wù)的設(shè)計、開發(fā)龙优、部署羊异、測試會更加復(fù)雜。比如陋率，雖然單元測試在微服務(wù)中可能更容易球化，但集成測試則不然。這些組件是分布式的瓦糟，開發(fā)人員不能在他們各自的機器上測試整個系統(tǒng)筒愚。

2. 接口控制

每個微服務(wù)都有自己的API，應(yīng)用程序依靠它來實現(xiàn)一致性菩浙。雖然你可以很容易地對一個微服務(wù)進行修改而不影響與之交互的外部系統(tǒng)巢掺，但如果你改變了API（接口）句伶，如果改變后不能向后兼容，任何使用該微服務(wù)的應(yīng)用程序都會受到影響陆淀。

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

3. 成本上升

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

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

2.4 容器(Containers)

2.4.1 容器是什么

Containers are a great enabler of cloud-native software.

上面這句話出自于《Cloud Native Patterns》的作者Cornelia Davis雏门。

他說嘿歌，"容器是一個偉大的云原生推動者"。

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

容器是一種操作系統(tǒng)虛擬化形式宙帝。可以使用一個容器來運行從小型微服務(wù)或軟件進程到大型應(yīng)用程序的所有內(nèi)容呼胚。

容器包含所有必要的可執(zhí)行文件茄唐、二進制代碼息裸、庫和配置文件蝇更。但是，與服務(wù)器或計算機虛擬化方法不同呼盆，容器不包含操作系統(tǒng)映像年扩。因此，它們更輕便且可移植访圃，其開銷很小厨幻。

容器化一個微服務(wù)并不難，你只需要將軟件代碼和所需要的所有組件（例如庫腿时、框架和其他依賴項）打包成一個二進制文件——容器鏡像况脆。鏡像存儲在容器的注冊表中，而注冊表可以位于你的計算機上批糟，在你的數(shù)據(jù)中心格了，或在一個公共云上。

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

下圖顯示了三個不同的微服務(wù)悄但，每個微服務(wù)都在自己的容器中棠隐，并且都在同一臺主機上運行。

image

每個容器是單獨維護自己的依賴關(guān)系和運行時間集的檐嚣，它們可能彼此不同助泽。從圖上我們可以看出，不同版本的產(chǎn)品微服務(wù)是在同一個主機上運行的嚎京。

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

2.4.1 容器的優(yōu)勢

1. 輕量級、可移植性

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

2. 成本降低

與傳統(tǒng)或硬件虛擬機環(huán)境相比辟躏，容器所需的系統(tǒng)資源更少谷扣，因為它們不包含操作系統(tǒng)映像。

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

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

容器 vs 虛擬機

虛擬機（VM）是一種創(chuàng)建于物理硬件系統(tǒng)（位于外部或內(nèi)部）籽御、充當虛擬計算機系統(tǒng)的虛擬環(huán)境练慕，它模擬出了自己的整套硬件，包括 CPU技掏、內(nèi)存铃将、網(wǎng)絡(luò)接口和存儲器。

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

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

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

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

由于容器的特性垮卓，微服務(wù)和容器可以很好地協(xié)同工作，因為容器中的微服務(wù)具有容器的所有的可移植性师幕、兼容性和可擴展性粟按。

2.4.2 容器編排(Container orchestration)

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

那么容器編排到底做了什么呢愚臀？

image

1. Scheduling-任務(wù)安排

自動提供容器實例

2. Affinity/anti-affinity-親和/反親和

3. Health monitorinh-健康檢測

自動檢測和糾正故障忆蚀。

4. Failover-故障轉(zhuǎn)移

自動將一個失敗的實例重置到一個健康的機器上。

5. Scaling-自動擴展

自動添加或刪除一個容器實例以滿足需求姑裂。

6. Networking-聯(lián)網(wǎng)

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

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

使容器能夠相互定位。

8. Rolling Upgrades-滾動更新

協(xié)調(diào)增量升級舶斧，實現(xiàn)零停機部署欣鳖，自動回滾有問題的更新。

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

2.5 后端服務(wù)-Backing services

image

App在運行過程中通過網(wǎng)絡(luò)消費的任何服務(wù)都可以稱為后端服務(wù)泽台。在傳統(tǒng)的操作系統(tǒng)中什荣，這些服務(wù)可以通過網(wǎng)絡(luò)、UNIX套接字訪問怀酷，甚至可以是一個子進程稻爬。例子包括并不限于：

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

你可以管理自己的后端服務(wù)桅锄，也可以讓云廠商代管。云廠商提供豐富的后端服務(wù)样眠，你無需擁有該服務(wù)友瘤，而是可以直接消費。

云廠商操作大規(guī)模的資源檐束，并承擔性能辫秧、安全和維護的責任。云原生系統(tǒng)傾向于云廠商提供的后端服務(wù)被丧。在這方面茶没，我們可以在時間和勞動力上節(jié)約很多。如果是自己托管晚碾，那么遇到的運行風險會比較麻煩抓半。

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

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

因素3規(guī)定蜂嗽，配置信息應(yīng)該被移出微服務(wù)，并通過代碼外的配置管理工具實現(xiàn)外部化殃恒。
后端服務(wù)也體現(xiàn)了12因素中"無狀態(tài)的服務(wù)進程"原則植旧，把依賴的服務(wù)分離出去，一些應(yīng)用服務(wù)已經(jīng)可以實現(xiàn)"無狀態(tài)"了离唐。

但有時候病附，還需要對應(yīng)用內(nèi)部做一些改造才能實現(xiàn)無狀態(tài)。無狀態(tài)是水平擴展的前提亥鬓，對于Serverless應(yīng)用更是必要條件完沪。

2.6 自動化（Automation）

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

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

基礎(chǔ)設(shè)施即代碼 (IaC) 指的是通過代碼而不是手動流程來管理和配置基礎(chǔ)設(shè)施写穴。IaC 有時也稱為"可編程基礎(chǔ)設(shè)施"，可將基礎(chǔ)設(shè)施配置完全當作軟件編程來進行雌贱。

IaC 協(xié)助將基礎(chǔ)設(shè)施管理從數(shù)據(jù)中心內(nèi)的物理硬件過渡到虛擬化啊送、容器和云計算。對于 IaC欣孤、網(wǎng)絡(luò)馋没、虛擬機、負載平衡器和連接拓撲都使用高級語言進行編碼降传，將應(yīng)用開發(fā)所依靠的環(huán)境標準化篷朵。

完成編碼后，DevOps 能夠啟動婆排、拆解和擴展基礎(chǔ)設(shè)施声旺，以響應(yīng)不斷波動的需求。這樣的敏捷性能夠造就更快段只、更簡單的軟件開發(fā)腮猖、測試和部署。

2.6.1 基礎(chǔ)設(shè)施自動化（Infrastructure Automation）

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

你可以重復(fù)運行同一個腳本而不產(chǎn)生副作用项滑。如果團隊想更新資源，他們可以編輯并重新運行腳本涯贞。

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

2.6.2 部署自動化（Deployment Automation）

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

為什么要強調(diào)"構(gòu)建钾恢、發(fā)布手素、運行"三個階段一定要分離開來呢？

有兩個好處：

1. 職責和關(guān)注點的分離瘩蚪。構(gòu)建是開發(fā)測試人員更關(guān)注的泉懦、發(fā)布是產(chǎn)品經(jīng)理更關(guān)注的、運行是運維更關(guān)注的疹瘦；

2. 流水線模式帶來的效率提升崩哩，以及各階段之間的緩沖空間，每個階段有專門的工具和方法論言沐。

怎么做到這三個階段的分離呢邓嘹？流水線的運行不是靠人力保障的，自動化系統(tǒng)很重要险胰。

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

image

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

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

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

3. 云原生的趨勢

在過去幾年中绽淘，IT行業(yè)見證了云原生技術(shù)的指數(shù)級增長涵防。當我們來到2022年，我們需要關(guān)注以下五個關(guān)鍵的云原生趨勢沪铭。

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

WebAssembly已經(jīng)發(fā)展成為一個高性能壮池、跨平臺、多語言的軟件沙盒環(huán)境杀怠，可用于云原生軟件的組件椰憋。鑒于容器運行時和WebAssembly（WASM）之間驚人的相似性，Kubernetes可用于協(xié)調(diào)WASM組件驮肉。

WasmCloud熏矿、WasmEdge、KubeEdge和Krustlet等項目使WASM成為云原生宇宙的一等公民离钝。

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

3.2 云原生安全

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

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

1. 軟件供應(yīng)鏈

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

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

2. eBPF

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

3.3 Kubevirt走向主流

Kubevirt是一個開源項目吐葵，它使得Kubernetes能夠像容器一樣協(xié)調(diào)虛擬機。

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

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

3.4 GitOps成為持續(xù)部署的標準

GitOps為云原生工作負載的發(fā)布管理帶來了熟悉的基于Git的工作流程凤藏。通過將Git作為單一可信來源來控制狀態(tài)奸忽，加上快速回滾的能力，使GitOps成為一個強大的機制清笨。

2022年月杉，GitOps將發(fā)展到支持多租戶和多集群部署刃跛，使其能夠輕松管理數(shù)萬個Kubernetes集群抠艾。也許GitOps將成為持續(xù)部署的黃金標準。

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

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

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

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

參考鏈接

1. The History of Pets vs Cattle and How to Use the Analogy Properly
2. How Michael Dell Reinvented His Company
3. The What, Why, and How of a Microservices Architecture
4. Microservices
5. Microservices Advantages and Disadvantages: Everything You Need to Know
6. Containers vs. Virtual Machines (VMs): What's the Difference?
7. 淺析云原生12要素
8. What is Infrastructure Automation?