1.1.3　云原生的設(shè)計(jì)原則

顧名思義，云原生是面向“云”而設(shè)計(jì)的應(yīng)用，但要給云原生下一個(gè)明確的定義很難，所有的架構(gòu)的目標(biāo)都是解決特定的業(yè)務(wù)場(chǎng)景。一方面，業(yè)務(wù)場(chǎng)景千變?nèi)f化，而每個(gè)人的技術(shù)背景不同，站的角度不同，所理解和設(shè)計(jì)的系統(tǒng)架構(gòu)也就各不相同。另一方面，架構(gòu)總是不斷演進(jìn)的，新的技術(shù)層出不窮，因此云原生的落地形式與能力邊界也在不斷演進(jìn)中。

換一個(gè)思路，云原生所倡導(dǎo)的思想與設(shè)計(jì)原則，或許能更好地讓大家理解什么是云原生，云原生具體解決哪一類問題。

1．去中心化原則

中心化意味著單點(diǎn)，為了具備良好的線性擴(kuò)展能力，分布式系統(tǒng)要求去中心化，避免單點(diǎn)故障。對(duì)于系統(tǒng)的服務(wù)能力，隨著資源加入，微服務(wù)的性能和容量能夠呈線性擴(kuò)展。在微服務(wù)場(chǎng)景下，每個(gè)服務(wù)可以獨(dú)立采用自己的技術(shù)方案或技術(shù)棧，每個(gè)微服務(wù)應(yīng)用獨(dú)立部署，服務(wù)之間進(jìn)程隔離，每個(gè)服務(wù)都有獨(dú)立的數(shù)據(jù)庫(kù)，一個(gè)服務(wù)實(shí)例的失效不會(huì)導(dǎo)致大規(guī)模的故障。這也是微服務(wù)架構(gòu)和SOA非常重要的區(qū)別之一。SOA一般有一個(gè)中心化的企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）負(fù)責(zé)所有服務(wù)的注冊(cè)發(fā)現(xiàn)以及調(diào)用路由；微服務(wù)架構(gòu)雖然也有一個(gè)服務(wù)注冊(cè)中心，但服務(wù)注冊(cè)中心只負(fù)責(zé)應(yīng)用啟動(dòng)或者狀態(tài)變更時(shí)做服務(wù)推送，真正在運(yùn)行過程中微服務(wù)之間的相互調(diào)用都是點(diǎn)對(duì)點(diǎn)直接調(diào)用，即運(yùn)行時(shí)是去中心化的。

另外，從研發(fā)流程的角度來說，去中心化意味著關(guān)注點(diǎn)分離。云原生對(duì)開發(fā)團(tuán)隊(duì)一個(gè)很重要的要求是獨(dú)立自主，每個(gè)服務(wù)由獨(dú)立的團(tuán)隊(duì)負(fù)責(zé)開發(fā)運(yùn)維，所有者的團(tuán)隊(duì)對(duì)服務(wù)具有決策權(quán)，可以自主選擇技術(shù)棧以及研發(fā)進(jìn)度，服務(wù)之間只要接口不變，外部就不必對(duì)其過度關(guān)注，更容易實(shí)現(xiàn)關(guān)注點(diǎn)分離。

2．松耦合原則

（1）實(shí)現(xiàn)的松耦合：這是基本的松耦合，即服務(wù)消費(fèi)端不需要依賴服務(wù)契約的某個(gè)特定實(shí)現(xiàn)，這樣服務(wù)提供端的內(nèi)部變更就不會(huì)影響消費(fèi)端，而且消費(fèi)端未來還可以自由切換到該契約的其他服務(wù)提供方。

（2）時(shí)間的松耦合：典型的是異步消息隊(duì)列系統(tǒng)，由于有中介者（broker），因此生產(chǎn)者和消費(fèi)者不必在同一時(shí)間都保持可用性以及相同的吞吐量，而且生產(chǎn)者也不需要馬上等到回復(fù)。

（3）位置的松耦合：典型的是服務(wù)注冊(cè)中心，消費(fèi)端完全不需要直接知道提供服務(wù)端的具體位置，而都通過注冊(cè)中心查找服務(wù)來訪問。

（4）版本的松耦合：消費(fèi)端不需要依賴服務(wù)契約的某個(gè)特定版本來工作，這就要求服務(wù)的契約在升級(jí)時(shí)要盡可能地提供向下兼容性。

3．面向失敗設(shè)計(jì)原則

為了保證系統(tǒng)的健壯性，軟件設(shè)計(jì)領(lǐng)域中一個(gè)很重要的原則是，所有的外部輸入和外部依賴都是不可信的，系統(tǒng)間依賴的調(diào)用隨時(shí)可能會(huì)失敗，也包括硬件基礎(chǔ)設(shè)施服務(wù)隨時(shí)可能死機(jī)，還有后端有狀態(tài)服務(wù)的系統(tǒng)能力可能有瓶頸?？傊诎l(fā)生異常時(shí)能夠快速失敗，然后快速恢復(fù)，以保證業(yè)務(wù)永遠(yuǎn)在線，不能讓業(yè)務(wù)半死不活地僵持著。

面向失敗設(shè)計(jì)（design for failure），意味著所有的外部調(diào)用都有容錯(cuò)處理，我們希望失敗的結(jié)果是我們可預(yù)期的、經(jīng)過設(shè)計(jì)的。在微服務(wù)架構(gòu)場(chǎng)景中，當(dāng)服務(wù)數(shù)量越來越多，依賴越來越復(fù)雜時(shí)，出現(xiàn)問題的概率也就越大，問題定位也會(huì)越來越困難，這時(shí)再用傳統(tǒng)的解決辦法將是一個(gè)災(zāi)難。傳統(tǒng)的方法通常是通過重試、補(bǔ)償?shù)仁侄伪M可能避免失敗，微服務(wù)架構(gòu)下由于存在更多的遠(yuǎn)程調(diào)用，任何外部依賴都有可能失效或延遲，這是潛在的故障和瓶頸。故障總是無法避免的，設(shè)計(jì)的目標(biāo)是預(yù)測(cè)和解決這些故障。因此在設(shè)計(jì)服務(wù)時(shí)，應(yīng)充分考慮異常情況，從使用者的角度出發(fā)，能夠容忍故障的發(fā)生，最小化故障的影響范圍。系統(tǒng)架構(gòu)設(shè)計(jì)時(shí)需要考慮到應(yīng)用系統(tǒng)的每一個(gè)層面，包括硬件和軟件是可能出現(xiàn)故障的，并據(jù)此在應(yīng)用系統(tǒng)架構(gòu)設(shè)計(jì)上消除單一故障點(diǎn)，從而實(shí)現(xiàn)高可用性（High Availability，HA）的系統(tǒng)架構(gòu)。

4．無狀態(tài)化原則

云原生的應(yīng)用服務(wù)設(shè)計(jì)盡可能是無狀態(tài)的，使得業(yè)務(wù)天生具有擴(kuò)展性，在業(yè)務(wù)流量高峰和低峰時(shí)期，依賴云的特性自動(dòng)彈性擴(kuò)容、縮容，滿足業(yè)務(wù)需求。無狀態(tài)指的是服務(wù)在處理請(qǐng)求時(shí)，不依賴除請(qǐng)求本身以外的其他內(nèi)容，也不會(huì)有除響應(yīng)請(qǐng)求之外的額外操作。這樣如果要實(shí)現(xiàn)無狀態(tài)服務(wù)的并行橫向擴(kuò)展，只需要對(duì)服務(wù)節(jié)點(diǎn)進(jìn)行并行擴(kuò)展，在服務(wù)之上添加一個(gè)負(fù)載均衡。

將“有狀態(tài)”的業(yè)務(wù)處理過程改造成“無狀態(tài)”的過程，思路比較簡(jiǎn)單，主要有以下兩種手段。

（1）狀態(tài)分離：服務(wù)端所有的狀態(tài)信息統(tǒng)一保存在外部獨(dú)立的分布式存儲(chǔ)中（如緩存、消息隊(duì)列、數(shù)據(jù)庫(kù)）。

（2）請(qǐng)求附帶全部狀態(tài)信息：將狀態(tài)信息前置，豐富請(qǐng)求的入?yún)?，將需要處理的?shù)據(jù)盡可能都通過上游的客戶端放到入?yún)⒅袀鬟^來。

5．不變性原則

容器技術(shù)帶來的最大優(yōu)勢(shì)，是通過鏡像實(shí)現(xiàn)了可編程式的運(yùn)行環(huán)境定義，從而實(shí)現(xiàn)了應(yīng)用與運(yùn)行環(huán)境的解耦。作為一種服務(wù)（IaaS），云原生基礎(chǔ)設(shè)施提供可編程式的需求描述，并實(shí)現(xiàn)記錄版本變更，保證環(huán)境的一致性。使用軟件工程中的原則、實(shí)踐和工具來加強(qiáng)基礎(chǔ)設(shè)施服務(wù)的生命周期管理，這意味著開發(fā)人員可以更頻繁地構(gòu)建更強(qiáng)可控或更穩(wěn)定的基礎(chǔ)設(shè)施。對(duì)資源調(diào)度而言，我們希望所有的服務(wù)（包括環(huán)境）無差異化配置，實(shí)現(xiàn)標(biāo)準(zhǔn)化可遷移，而不希望在部署任何服務(wù)的過程中還需要手動(dòng)操作，因?yàn)槭謩?dòng)操作是無法批量化、自動(dòng)化執(zhí)行的，也是不容易回溯的。

實(shí)現(xiàn)不變性原則的前提是，基礎(chǔ)設(shè)施中的每個(gè)服務(wù)、組件都可以自動(dòng)安裝、部署，不需要人工干預(yù)。所有的資源都可以隨時(shí)拉起、隨時(shí)釋放，同時(shí)以API的方式提供彈性、按需的計(jì)算、存儲(chǔ)能力。每個(gè)服務(wù)或者組件在安裝部署完成后將不會(huì)發(fā)生更改，如果要更改，就丟棄老的服務(wù)或組件，并重新部署一個(gè)服務(wù)或組件。另外，為了提升可用性，我們應(yīng)該盡量減少故障修復(fù)時(shí)間，要知道替換的速度遠(yuǎn)遠(yuǎn)快于修復(fù)的速度。

6．自動(dòng)化驅(qū)動(dòng)原則

為了滿足業(yè)務(wù)需求的頻繁變動(dòng)，通過快速迭代，產(chǎn)品能做到隨時(shí)可發(fā)布，這是一系列開發(fā)實(shí)踐方法。自動(dòng)化驅(qū)動(dòng)分為持續(xù)集成、持續(xù)部署、持續(xù)交付等階段，用來確保需求的提出、設(shè)計(jì)開發(fā)測(cè)試，再到代碼快速、安全地部署到生產(chǎn)環(huán)境中。持續(xù)集成是指每當(dāng)開發(fā)人員提交了一次改動(dòng)，就立刻進(jìn)行構(gòu)建、自動(dòng)化測(cè)試，確保業(yè)務(wù)應(yīng)用和服務(wù)均能符合預(yù)期，從而可以確定新代碼和原有代碼能否正確地集成在一起。持續(xù)部署是指使用完全的自動(dòng)化過程把每個(gè)變更自動(dòng)提交到測(cè)試環(huán)境中，觸發(fā)自動(dòng)化測(cè)試用例，測(cè)試驗(yàn)證通過后將應(yīng)用安全地部署到生產(chǎn)環(huán)境中，打通開發(fā)、測(cè)試、生產(chǎn)等各個(gè)環(huán)節(jié)。持續(xù)交付是軟件發(fā)布的能力，在持續(xù)集成完成后，能夠提供到預(yù)發(fā)布之類的環(huán)境上，滿足生產(chǎn)環(huán)境的條件。

應(yīng)用系統(tǒng)的部署與運(yùn)維的成本會(huì)隨著服務(wù)的增多呈指數(shù)級(jí)增長(zhǎng)，每個(gè)服務(wù)都需要部署、監(jiān)控、日志分析等運(yùn)維工作，成本會(huì)顯著升高。在服務(wù)劃分之前，應(yīng)該首先構(gòu)建自動(dòng)化的工具及環(huán)境，開發(fā)、測(cè)試人員應(yīng)該以自動(dòng)化為驅(qū)動(dòng)力，簡(jiǎn)化服務(wù)在創(chuàng)建、開發(fā)、測(cè)試、部署、運(yùn)維上的重復(fù)性工作，盡可能通過自動(dòng)化工具完成所有重復(fù)的工作。當(dāng)提交代碼后，自動(dòng)化的工具鏈自動(dòng)編譯、構(gòu)建、測(cè)試、集成。開發(fā)人員持續(xù)優(yōu)化代碼，當(dāng)滿足上線要求時(shí)，自動(dòng)化部署到生產(chǎn)環(huán)境中。這種自動(dòng)化的方式能夠?qū)崿F(xiàn)更可靠的操作，既避免了人為失誤，又避免了微服務(wù)數(shù)量增多帶來的開發(fā)、運(yùn)維、管理的復(fù)雜化。