风凌天下,魔天记忘语小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

淺談創(chuàng)新互聯(lián)—從概念到趨勢

??想了解更多關(guān)于開源的內(nèi)容，請訪問：??

?? 開源基礎(chǔ)軟件社區(qū)??

??https://ost.??

閱讀完本文你將會

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

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)上述這些情況，你的用戶將會訪問你的競爭對手。

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

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

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

（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. 牛。

Pets-寵物

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

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

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）現(xiàn)代設(shè)計(Modern Design)

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

十二因素

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

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

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

CodeBase-基準代碼

One codebase tracked in revision control, many deploys。

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

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

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)致"投毒"，這對代碼的問題定位、維護、交接都是很大的負擔。

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ā)模式中很常見。

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)用。

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)理改了什么，直接口頭告訴運維批量更換某些文件。

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ā)等功能。

Port Binding-端口綁定

Export services via port binding。

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

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

Concurrency-并發(fā)能力

Scale out via the process model。

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

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

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)閉進程。

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)不出來。

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)的做法習(xí)以為常，卻忘記了"單一職責原則"。

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í)行一些腳本。

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

（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）微服務(wù)的優(yōu)勢

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

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

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

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

復(fù)雜性

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

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

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

接口控制

每個微服務(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)重要。

成本上升

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

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

4、容器(Containers)

（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ù)都在自己的容器中，并且都在同一臺主機上運行。

圖.容器

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

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

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

輕量級、可移植性

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

成本降低

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

改善了應(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ù)具有容器的所有的可移植性、兼容性和可擴展性。

（3）容器編排(Container orchestration)

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

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

Scheduling-任務(wù)安排。

自動提供容器實例：

Affinity/anti-affinity-親和/反親和。
Health monitorinh-健康檢測。

自動檢測和糾正故障。

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

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

Scaling-自動擴展。

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

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

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

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

使容器能夠相互定位。

Rolling Upgrades-滾動更新。

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

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

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

圖.后端服務(wù)

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é)約很多。如果是自己托管，那么遇到的運行風(fēng)險會比較麻煩。

最佳實踐是將后端服務(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)用更是必要條件。

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ā)、測試和部署。

（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è)施?！?/p>

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

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

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

有兩個好處：

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

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

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

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

開發(fā)者在開發(fā)環(huán)境中開發(fā)了一個功能，通過代碼、運行和調(diào)試的"內(nèi)循環(huán)"進行迭代。
完成后，這些代碼被推送到代碼庫中，如GitHub或BitBucket。
然后CI自動構(gòu)建、測試和打包應(yīng)用程序。
到了發(fā)布階段，CD系統(tǒng)將打好的包，外部應(yīng)用和環(huán)境配置信息合成一個不可變的版本。該版本被部署到一個指定的環(huán)境中。每個版本都應(yīng)該是可識別的。
最后，發(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)鍵的云原生趨勢。

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)這兩種組件。

2、云原生安全

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

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

軟件供應(yīng)鏈

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

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

eBPF

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

3、Kubevirt走向主流

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

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

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

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

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

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

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)勢，并接受它們，以享受云的彈性和敏捷性。