谷歌：云原生架構(gòu)的 5 條原則

在 Google Cloud 中，我們經(jīng)常把“云原生架構(gòu)”這一術(shù)語作為遷移或構(gòu)建在 Google Cloud Platform（GCP）上的應(yīng)用程序所期望的最終目標(biāo)。但云原生究竟是什么意思呢？更重要的是，你如何著手設(shè)計這樣一個系統(tǒng)？

從高層次來看，與傳統(tǒng)的本地基礎(chǔ)設(shè)施相比， 云原生架構(gòu)意味著要適應(yīng)云提供的許多新的可能性，但架構(gòu)約束有著很大的不同。以下是我們作為軟件架構(gòu)師應(yīng)該考慮到的高層次元素：

• 系統(tǒng)的功能需求（它應(yīng)該做什么，例如“以這種格式處理訂單…”）；

• 非功能性要求（如“每分鐘至少處理 200 個訂單”）；

• 約束（超出變更范圍的內(nèi)容，例如“訂單必須在我們現(xiàn)有的大型機(jī)系統(tǒng)上更新”）。

雖然功能方面不會發(fā)生太大變化，但云提供（有時需要）的用來滿足非功能性需求的方式差別很大，對架構(gòu)的約束也有很大的差別。如果架構(gòu)師未能使他們的方法適應(yīng)這些不同的約束，他們設(shè)計的系統(tǒng)通常就會脆弱而昂貴，并且難以維護(hù)。另一方面，架構(gòu)良好的云原生系統(tǒng)應(yīng)該在很大程度上是自修復(fù)、經(jīng)濟(jì)高效的，并且可以通過持續(xù)集成 / 持續(xù)交付（CI / CD）輕松進(jìn)行更新和維護(hù)。

好消息是，構(gòu)成云的服務(wù)器、磁盤和網(wǎng)絡(luò)與傳統(tǒng)基礎(chǔ)設(shè)施相同。這意味著幾乎所有優(yōu)秀的架構(gòu)設(shè)計原則仍然適用于云原生架構(gòu)。但是在云中時，關(guān)于這種結(jié)構(gòu)如何執(zhí)行的一些基本假設(shè)會發(fā)生變化。例如，在傳統(tǒng)環(huán)境中配置替換服務(wù)器可能需要數(shù)周時間，而在云環(huán)境中則需要幾秒鐘，應(yīng)用程序架構(gòu)要把這點(diǎn)考慮在內(nèi)。

在本文中，我們列出了云原生架構(gòu)的五個原則，這些原則將有助于確保設(shè)計充分利用云，同時避免將舊的方法引入新平臺的陷阱。

云原生架構(gòu)的原則

云架構(gòu)（即云原生架構(gòu)）的構(gòu)建原則，側(cè)重于如何針對云的獨(dú)特功能優(yōu)化系統(tǒng)架構(gòu)。傳統(tǒng)的架構(gòu)傾向于為固定的、高成本的基礎(chǔ)設(shè)施進(jìn)行優(yōu)化，需要大量手動的修改。因此，傳統(tǒng)架構(gòu)側(cè)重于相對固定且數(shù)量較少的組件的彈性和性能。然而，在云中，這樣一個固定的基礎(chǔ)設(shè)施沒有多大意義，因?yàn)樵剖歉鶕?jù)使用量進(jìn)行收費(fèi)的（這樣可以通過減少空間占用來節(jié)省資金），而且自動化也更容易（自動放大和縮小要容易得多）。因此，云原生架構(gòu)的重點(diǎn)是通過橫向擴(kuò)展、分布式處理，以及自動更換故障組件來實(shí)現(xiàn)彈性和擴(kuò)展。

原則 1：自動化設(shè)計

自動化一直是軟件系統(tǒng)的最佳實(shí)踐，但云技術(shù)使得基礎(chǔ)設(shè)施以及位于其上的組件自動化變得前所未有的簡單。盡管前期投資通常會更高，但從中期來看，無論從投入的角度，還是在系統(tǒng)的彈性和性能方面，幾乎總能獲得回報。自動化流程可以比人更快地修復(fù)、擴(kuò)展和部署系統(tǒng)。正如我們稍后會討論的那樣，云上的架構(gòu)并不是一次性的，自動化也不例外，因?yàn)闀业叫碌南到y(tǒng)操作方法，所以將發(fā)現(xiàn)新的東西可以自動化。

自動化云原生系統(tǒng)的一些常見領(lǐng)域是：

• 基礎(chǔ)設(shè)施：使用 Google Cloud Deployment Manager 或 Terraform 之類的工具，自動創(chuàng)建基礎(chǔ)設(shè)施并對其進(jìn)行更新；

• 持續(xù)集成 / 持續(xù)交付（CI/CD）：使用 Google Cloud Build、Jenkins 和 Spinnaker 等工具自動構(gòu)建、測試和部署構(gòu)成系統(tǒng)的軟件包。不僅應(yīng)該自動部署，還應(yīng)該努力實(shí)現(xiàn)金絲雀測試和回滾等過程的自動化；

• 伸縮性（Scale Up/Down）：除非系統(tǒng)負(fù)載幾乎從未發(fā)生變化，否則應(yīng)該根據(jù)負(fù)載的增加自動擴(kuò)展系統(tǒng)，并根據(jù)負(fù)載的持續(xù)下降進(jìn)行收縮。通過擴(kuò)展，可以確保服務(wù)仍然可用，并通過按比例收縮來降低成本。這對于大型應(yīng)用程序（如公共網(wǎng)站）以及具有不規(guī)則負(fù)載的較小應(yīng)用程序（例如在某些時段非常繁忙但在其他時間幾乎不使用的內(nèi)部應(yīng)用程序）來說是很有意義的。對于有時幾乎沒有流量并且可以容忍一些初始延遲的應(yīng)用程序，甚至應(yīng)該考慮將其收縮為零（刪除所有正在運(yùn)行的實(shí)例，并在下次需要時重新啟動應(yīng)用程序）；

• 監(jiān)控和自動恢復(fù)：應(yīng)該從一開始就在云原生系統(tǒng)中納入監(jiān)控和日志記錄。日志記錄和監(jiān)視的數(shù)據(jù)流可以很自然地用于監(jiān)視系統(tǒng)的運(yùn)行狀況，除此之外還可以有許多用途。例如，它們可以對系統(tǒng)的使用和用戶的行為（有多少人在使用系統(tǒng)，他們在使用什么部分，他們的平均延遲時間是多少等）提供有價值的見解。其次，它們可以通過匯總來衡量整個系統(tǒng)的健康狀況（例如，磁盤又快滿了，它的填寫速度比平時快嗎？磁盤使用量和服務(wù)占用之間的關(guān)系是什么？等等）。最后，它們是添加自動化理想的地方，當(dāng)磁盤要填滿時，可以自動調(diào)整磁盤大小以保持系統(tǒng)正常運(yùn)行，而不僅僅只記錄錯誤。

原則 2：善用狀態(tài)

存儲的“狀態(tài)”，可以是用戶的數(shù)據(jù)（例如，用戶購物車中的條目，或他們的員工編號）或者是系統(tǒng)的狀態(tài)（例如，作業(yè)中運(yùn)行的實(shí)例數(shù)量，運(yùn)行中的代碼版本），這是構(gòu)建分布式、云原生架構(gòu)最難的方面。因此，設(shè)計系統(tǒng)時應(yīng)該有意地去了解何時以及如何存儲狀態(tài)，并盡可能設(shè)計無狀態(tài)的組件。

無狀態(tài)的組件可以很容易實(shí)現(xiàn)以下功能：

• 伸縮：要擴(kuò)展，只需添加更多的副本。要收縮，可以引導(dǎo)實(shí)例在完成當(dāng)前任務(wù)后終止；

• 修復(fù)：要“修復(fù)”一個失敗的組件實(shí)例，只需盡可能優(yōu)雅地終止它并啟動一個替換；

• 回滾：如果部署得不好，無狀態(tài)的組件更容易回滾，因?yàn)榭梢越K止它們并啟動舊版本的實(shí)例；

• 負(fù)載均衡：當(dāng)組件處于無狀態(tài)時，負(fù)載均衡要簡單得多，因?yàn)槿魏螌?shí)例都可以處理任何請求。有狀態(tài)組件的負(fù)載均衡要困難得多，因?yàn)橛脩魰挼臓顟B(tài)通常駐留在實(shí)例上，這迫使該實(shí)例處理來自給定用戶的所有請求。

原則 3：支持托管服務(wù)

云不僅僅是基礎(chǔ)設(shè)施，大多數(shù)的云提供商都提供豐富的托管服務(wù)，提供各種各樣的功能，讓我們輕松管理后端軟件或基礎(chǔ)設(shè)施。但是，許多組織對利用這些服務(wù)持謹(jǐn)慎態(tài)度，因?yàn)樗麄儞?dān)心被某個供應(yīng)商給“綁定”。這是一個合理的擔(dān)心，但托管服務(wù)通?？梢詷O大地節(jié)省組織的時間和運(yùn)營開銷。

廣義上講，從資金和技能兩方面來看，是否采用托管服務(wù)取決于可移植性與運(yùn)營開銷。粗略地說，今天可能會考慮的托管服務(wù)分為三大類：

• 托管開源或開源兼容服務(wù)：托管開源（例如 Cloud SQL）或提供開源兼容的接口（例如 Cloud Bigtable）的服務(wù)。這應(yīng)該是一個簡單的選擇，因?yàn)槭褂猛泄芊?wù)有很多好處，而且風(fēng)險很小；

• 節(jié)省高運(yùn)營成本的托管服務(wù)：某些服務(wù)不能直接與開源兼容，或者沒有直接的開源替代方案，但是比替代方案更容易使用，它們值得承擔(dān)風(fēng)險。例如，BigQuery 因?yàn)橐子诓僮鞫?jīng)常被組織所采用；

• 其他情況：然后是困難的情況，沒有容易的遷移途徑可以離開服務(wù)，它提供了不太明顯的運(yùn)營效益。需要逐個分析這些問題，考慮到服務(wù)的戰(zhàn)略意義、自己運(yùn)行它的運(yùn)營開銷以及遷移所需的工作。

但是，實(shí)踐經(jīng)驗(yàn)表明，大多數(shù)云原生架構(gòu)都偏愛托管服務(wù)，但必須讓遷移的潛在風(fēng)險，低于云提供商大規(guī)模管理服務(wù)所帶來的時間、精力和運(yùn)營風(fēng)險方面的巨大節(jié)省。

原則 4：深入實(shí)踐防御

傳統(tǒng)的體系架構(gòu)非常重視周邊安全，粗略地說，它建立了一個強(qiáng)化的網(wǎng)絡(luò)邊界，內(nèi)部有“可信賴的東西”，外部有“不受信任的東西”。不幸的是，這種方法總是容易受到內(nèi)部的攻擊，以及魚叉式網(wǎng)絡(luò)釣魚（spear phishing）之類的外部威脅。此外，提供靈活的移動辦公的壓力越來越大，進(jìn)一步破壞了網(wǎng)絡(luò)邊界。

云原生架構(gòu)起源于面向互聯(lián)網(wǎng)的服務(wù)，因此始終需要處理外部的攻擊。因此，它們通過在每個組件之間應(yīng)用身份驗(yàn)證，并通過最小化這些組件之間的信任（即使它們是“內(nèi)部的”）來實(shí)施深度防御。因此，沒有“內(nèi)部”和“外部”之分。

云原生架構(gòu)應(yīng)該將此想法擴(kuò)展到身份驗(yàn)證之外，包括速率限制和腳本注入等內(nèi)容。設(shè)計中的每個組件都應(yīng)該設(shè)法保護(hù)自己免受其他組件的影響。這不僅使體系架構(gòu)具有很強(qiáng)的彈性，而且使產(chǎn)生的服務(wù)更容易部署在云環(huán)境中，在云環(huán)境中，服務(wù)與其用戶之間可能沒有可信任的網(wǎng)絡(luò)。

原則 5：架構(gòu)不止

云原生系統(tǒng)的核心特征之一是它總是在進(jìn)化，這同樣適用于架構(gòu)。作為一個云原生架構(gòu)師，隨著組織需求的變化、IT 系統(tǒng)環(huán)境的變化以及云提供商自身的能力的變化，您應(yīng)該始終尋求優(yōu)化、簡化和改進(jìn)系統(tǒng)的架構(gòu)。盡管這無疑需要不斷的投資，但過去的教訓(xùn)是顯而易見的：要發(fā)展、增長和響應(yīng)，IT 系統(tǒng)需要生存、呼吸和改變。過時的、僵化的 IT 系統(tǒng)會迅速使組織陷入停頓，無法應(yīng)對新的威脅和機(jī)遇。

唯一不變的是變化

在動物界，生存有利于那些適應(yīng)環(huán)境的個體。這不是從“壞”到“最佳”或從“原始”到“進(jìn)化”的線性旅程，而是所有事物都在不斷變化。隨著環(huán)境的變化，對物種施加壓力以進(jìn)化和適應(yīng)。同樣，云原生架構(gòu)并不能取代傳統(tǒng)架構(gòu)，但它們更適合于非常不同的云環(huán)境。云正日益成為我們大多數(shù)人工作的環(huán)境，許多物種都證明，不能發(fā)展和適應(yīng)的都不是長期的選擇。

上面描述的原則并不是創(chuàng)建云原生架構(gòu)的神奇公式，但希望能為如何充分利用云提供強(qiáng)有力的指導(dǎo)。作為額外的一個好處，云架構(gòu)的變化和調(diào)整給了我們以其他方式改進(jìn)和調(diào)整的機(jī)會，并使它們能夠更好地適應(yīng)下一次環(huán)境的變化。改變可能是困難的，正如十幾億年的進(jìn)化所展示的那樣，不必是生存得最好的，只需要能夠去適應(yīng)。