微服務(wù)架構(gòu)的思想已經(jīng)被廣泛接受，各種最佳實(shí)踐也層出不窮。雖然有各種方法論的指導(dǎo)，但到了具體實(shí)踐的過程中，還是會(huì)有諸多的困惑。本文試圖剖析從單體架構(gòu)到微服務(wù)架構(gòu)演化背后的深刻原因，從而更好地理解微服務(wù)的精髓。

從服務(wù)化談起

軟件的協(xié)作方式并不是憑空而來，而是依據(jù)很多我們實(shí)際生活中的既有規(guī)則來設(shè)計(jì)的。理解軟件架構(gòu)模式演化背后的動(dòng)機(jī)，可以從我們實(shí)際生活中的場景尋找答案。傳統(tǒng)的農(nóng)耕社會(huì)，大家的協(xié)作方式是以物換物。很容易出現(xiàn)需要一張羊皮，卻換回來一只羊的情況，如果這只羊攜帶了某種病毒，那問題就麻煩了。依賴軟件包進(jìn)行開發(fā)就非常類似這種情形，某個(gè)軟件包有n個(gè)方法，而使用者通常僅需要少數(shù)幾個(gè)，一旦未被使用的部分有漏洞，則非常尷尬了。

可不可以僅僅按需使用呢？對(duì)，答案就是服務(wù)化。某個(gè)服務(wù)用或者不用，都在那里。當(dāng)然，依賴軟件包還有跨語言的問題，也存在大量資源浪費(fèi)的問題。通過一種“契約式協(xié)議”，確定了輸入和輸出的邏輯關(guān)系，然后就可以按照需要進(jìn)行使用。這就像銀行的存取款業(yè)務(wù)，服務(wù)一直在那里，何時(shí)用、用哪些由您的需要決定。

服務(wù)化帶來的最大好處是可替代性增強(qiáng)。只要遵守“契約協(xié)議”，那么就可以作為服務(wù)提供者。從設(shè)計(jì)角度來說，如果需要支持提供相同標(biāo)準(zhǔn)的多個(gè)服務(wù)提供者，那么就需要考慮從需求出發(fā)，設(shè)計(jì)滿足需求的最小功能集的服務(wù)。

軟件分層架構(gòu)

早期的時(shí)候，三層架構(gòu)非常流行，展現(xiàn)層、邏輯層和數(shù)據(jù)庫層各司其職。每一層把各個(gè)功能的邏輯集中到一起，但是功能和功能之間沒有邊界。為了更好地體現(xiàn)“契約”，通常業(yè)務(wù)邏輯會(huì)由接口和實(shí)現(xiàn)接口的方法組成。但是功能邊界的問題依然沒有解決。

邊界不明確帶來的問題則是任何一個(gè)改動(dòng)，幾乎整個(gè)大的功能都必須進(jìn)行一次全面測試，因?yàn)闊o法確定這個(gè)改動(dòng)的影響范圍。軟件規(guī)模越大，帶來的潛在風(fēng)險(xiǎn)越大，事故所造成的影響也越大。分層并不能使得開發(fā)人員在業(yè)務(wù)邏輯上聚焦，反而隨著業(yè)務(wù)越來越復(fù)雜，開發(fā)人員的負(fù)擔(dān)也會(huì)越來越重。

邊界的劃分

有一種模式在較長一段時(shí)間內(nèi)被認(rèn)為是很好的解決方案，那就是 MVC。這種模式最突出的特點(diǎn)就是數(shù)據(jù)和展現(xiàn)存在某種對(duì)應(yīng)關(guān)系，控制層只做請(qǐng)求的轉(zhuǎn)發(fā)。比如某個(gè)頁面做列表展示，那么只需要通過業(yè)務(wù)邏輯層獲取數(shù)據(jù)，然后綁定到數(shù)據(jù)對(duì)象上即可，展現(xiàn)層會(huì)根據(jù)數(shù)據(jù)去渲染。

這種通過頁面功能進(jìn)行的邊界劃分，對(duì)于開發(fā)來說，通過不同的控制器可以較好地實(shí)現(xiàn)功能邊界隔離。但是，在某些場景下，某個(gè)功能的處理速度成為瓶頸，就會(huì)成為整個(gè)系統(tǒng)的瓶頸。然而，又無法針對(duì)某些場景下才用到的邏輯進(jìn)行水平擴(kuò)容。所以，必須從業(yè)務(wù)的角度去識(shí)別某些需要具備“彈性”的邏輯，然后從“物理”上進(jìn)行隔離。

上云與云原生

應(yīng)用上云是一個(gè)曾經(jīng)很熱的話題，這個(gè)問題最關(guān)鍵的不是能不能上云，而是上云之后怎么辦。如果沒有使用云的“彈性”，那么上云也就失去了意義。對(duì)既有系統(tǒng)的改造成為了重中之重，但是這個(gè)過程是非常痛苦的，涉及的方方面面太多，風(fēng)險(xiǎn)也會(huì)很大。于是，大家希望直接從設(shè)計(jì)之初就充分考慮云的特性，然后再開發(fā)適應(yīng)云環(huán)境的應(yīng)用。

當(dāng)劃分好了業(yè)務(wù)邊界之后，每一個(gè)部分的職位就會(huì)相對(duì)單一，當(dāng)然，這些部分都是服務(wù)化的。服務(wù)之間的交互采用標(biāo)準(zhǔn)的基于消息的協(xié)議，所有動(dòng)作都是基于事件驅(qū)動(dòng)。那么當(dāng)服務(wù)的職責(zé)足夠明確、單一，是否就是我們通常所說的微服務(wù)呢？其實(shí)，還不是！服務(wù)在云上，必須具備一些特定屬性。

微服務(wù)特性

能夠稱之為微服務(wù)，則需要滿足云原生的要求，這樣即使上云也是很簡單的一個(gè)步驟。作為分布式系統(tǒng)中的一個(gè)組件，必須滿足：

• 具備熔斷機(jī)制

  某個(gè)服務(wù)可能依賴另一個(gè)服務(wù)，當(dāng)被依賴的服務(wù)無法訪問時(shí)，則外部請(qǐng)求直接返回。當(dāng)被依賴的服務(wù)恢復(fù)時(shí)，服務(wù)必須能夠自動(dòng)更新熔斷狀態(tài)，外部請(qǐng)求可以直接訪問被依賴服務(wù)。

• 能夠獨(dú)立構(gòu)建、測試和部署

  微服務(wù)開發(fā)通常由某個(gè)微型團(tuán)隊(duì)負(fù)責(zé)，由于業(yè)務(wù)邊界比較清晰，業(yè)務(wù)邏輯也非常固定，所以可以按照自己的節(jié)奏進(jìn)行迭代和升級(jí)。

• 支持健康檢查 微服務(wù)啟動(dòng)后，可能是被依賴的服務(wù)，那么被其他服務(wù)調(diào)用時(shí)，熔斷器可能會(huì)通過健康檢查結(jié)果設(shè)置自身容器狀態(tài)，所以必須具備健康檢查相關(guān)的接口。

• 支持重試機(jī)制

  服務(wù)在訪問被依賴服務(wù)時(shí)，很可能由于網(wǎng)絡(luò)延遲等原因獲取不到結(jié)果，但是重試機(jī)制可以確保，在一定的時(shí)間內(nèi)獲取到結(jié)果。所以，分布式系統(tǒng)訪問的結(jié)果為：成功、失敗和超時(shí)。

• 配置注入

  微服務(wù)實(shí)例在運(yùn)行時(shí)，可能會(huì)根據(jù)負(fù)載進(jìn)行彈性伸縮，所以，依賴必須在運(yùn)行時(shí)注入，而不能在編譯打包時(shí)固定，更加不能依賴基礎(chǔ)設(shè)施信息，比如IP地址等。

Kubernetes

Kubernetes 已經(jīng)成為容器編排的事實(shí)標(biāo)準(zhǔn)，提供了很多特性來支持云原生應(yīng)用的部署。比如 Service、ReplicaSet、Deployment、ConfigMap&Secret 等等，其強(qiáng)大的社區(qū)已經(jīng)逐漸影響到了其他容器編排引擎，比如 Mesos、Swarm 等等。基于 Kubernetes 打造企業(yè)輕量級(jí) Paas 平臺(tái)已經(jīng)成為了趨勢(shì)。

總結(jié)

微服務(wù)并不是憑空而來的，更不只是規(guī)模小。了解微服務(wù)的誕生過程，理解了背后的動(dòng)機(jī)就能夠準(zhǔn)確把握微服務(wù)拆分的粒度，以及在實(shí)踐微服務(wù)過程中要把握的要點(diǎn)。

作者：付輝，JFrog 資深工程師/DockOne社區(qū)翻譯

歡迎轉(zhuǎn)載，但轉(zhuǎn)載請(qǐng)注明作者與出處。謝謝！

轉(zhuǎn)載于:https://blog.51cto.com/jfrogchina/2046145

總結(jié)

以上是生活随笔為你收集整理的微服务架构的原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。