完结小说排行榜,盗墓笔记第二季

技術(shù)干貨：“單身”還是“入微”？一起聊聊微服務(wù)的二三事

2022-11-18

649

這一篇，我們來聊聊關(guān)于單體架構(gòu)與微服務(wù)架構(gòu)“相愛相殺”的故事。

微服務(wù)架構(gòu)的通俗解釋

微服務(wù)我們需要理解三個(gè)概念：

1、什么是"微"？

微，狹義來講就是體積小。

2、什么是"服務(wù)"？

服務(wù)，一定要區(qū)別于系統(tǒng)，服務(wù)一個(gè)或者一組相對較小且獨(dú)立的功能單元，是用戶可以感知最小功能集。

3、微服務(wù)架構(gòu)以外是什么樣子的架構(gòu)——單體架構(gòu)

傳統(tǒng)的單體架構(gòu)，是以整個(gè)系統(tǒng)為單位進(jìn)行部署。而微服務(wù)，則是以每一個(gè)獨(dú)立組件（例如用戶服務(wù)，商品服務(wù)）為單位進(jìn)行部署。

對于單體應(yīng)用，如果發(fā)現(xiàn)某一業(yè)務(wù)的請求量非常大，那么是無法單獨(dú)擴(kuò)展該業(yè)務(wù)的，只能拷貝整個(gè)單體應(yīng)用，再部署一套環(huán)境，來實(shí)現(xiàn)集群。

正因?yàn)閱误w應(yīng)用的缺陷，才有了微服務(wù)。

微服務(wù)架構(gòu)與單體架構(gòu)區(qū)別

有了上面的幾個(gè)基礎(chǔ)，我們再來看看微服務(wù)的定義：

微服務(wù)是指開發(fā)一個(gè)單個(gè)小型的但有業(yè)務(wù)功能的服務(wù)，每個(gè)服務(wù)都有自己的處理和輕量通訊機(jī)制，可以部署在單個(gè)或多個(gè)服務(wù)器上。微服務(wù)也指一種松耦合的、有一定的有界上下文的面向服務(wù)架構(gòu)。也就是說，如果每個(gè)服務(wù)都要同時(shí)修改，那么它們就不是微服務(wù)，因?yàn)樗鼈兙o耦合在一起；如果你需要掌握一個(gè)服務(wù)太多的上下文場景使用條件，那么它就是一個(gè)有上下文邊界的服務(wù)，這個(gè)定義來自DDD領(lǐng)域驅(qū)動設(shè)計(jì)。

簡單來說，微服務(wù)就是將原來龐大的單體架構(gòu)的各個(gè)業(yè)務(wù)模塊變?yōu)楠?dú)立的可運(yùn)行的服務(wù)，一些微服務(wù)會暴露一個(gè)供其他微服務(wù)或應(yīng)用客戶端消費(fèi)的 API，模塊與模塊之間通過API互相調(diào)用。各個(gè)業(yè)務(wù)模塊都是一個(gè)服務(wù)，整個(gè)項(xiàng)目有眾多服務(wù)組成，這就是微服務(wù)。

微服務(wù)與API

微服務(wù)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

1、它解決了復(fù)雜問題。它把可能會變得龐大的單體應(yīng)用程序分解成一套服務(wù)。雖然項(xiàng)目的功能數(shù)量不變，但是應(yīng)用程序已經(jīng)被分解成可管理的塊或者服務(wù)。每個(gè)服務(wù)都有一個(gè)明確定義邊界的方式，如遠(yuǎn)程過程調(diào)用（RPC）驅(qū)動或消息驅(qū)動 API。微服務(wù)架構(gòu)模式強(qiáng)制一定程度的模塊化，實(shí)際上，使用單體代碼來實(shí)現(xiàn)是極其困難的。因此，使用微服務(wù)架構(gòu)模式，個(gè)體服務(wù)能被更快地開發(fā)，并更容易理解與維護(hù)。

2、這種架構(gòu)使得每個(gè)服務(wù)都可以由一個(gè)團(tuán)隊(duì)獨(dú)立專注開發(fā)。開發(fā)者可以自由選擇任何符合服務(wù) API 契約的技術(shù)。當(dāng)然，更多的組織是希望通過技術(shù)選型限制來避免完全混亂的狀態(tài)。然而，這種自由意味著開發(fā)人員不再有可能在這種自由的新項(xiàng)目開始時(shí)使用過時(shí)的技術(shù)。當(dāng)編寫一個(gè)新服務(wù)時(shí)，他們可以選擇當(dāng)前的技術(shù)。此外，由于服務(wù)較小，使用當(dāng)前技術(shù)重寫舊服務(wù)將變得更加可行。

3、微服務(wù)架構(gòu)模式可以實(shí)現(xiàn)每個(gè)微服務(wù)獨(dú)立部署。開發(fā)人員根本不需要去協(xié)調(diào)部署本地變更到服務(wù)。這些變更一經(jīng)測試即可立即部署。比如，UI 團(tuán)隊(duì)可以執(zhí)行 A|B 測試，并快速迭代 UI 變更。微服務(wù)架構(gòu)模式使得持續(xù)部署成為可能。

4、微服務(wù)架構(gòu)模式使得每個(gè)服務(wù)能夠獨(dú)立擴(kuò)展。您可以僅部署滿足每個(gè)服務(wù)的容量和可用性約束的實(shí)例數(shù)目。此外，您可以使用與服務(wù)資源要求最匹配的硬件。

缺點(diǎn)

1、由于微服務(wù)是一個(gè)分布式系統(tǒng)，其使得整體變得復(fù)雜。開發(fā)者需要選擇和實(shí)現(xiàn)基于消息或者 RPC 的進(jìn)程間通信機(jī)制。此外，由于目標(biāo)請求可能很慢或者不可用，他們必須要編寫代碼來處理局部故障。雖然這些并不是很復(fù)雜、高深，但模塊間通過語言級方法/過程調(diào)用相互調(diào)用，這比單體應(yīng)用要復(fù)雜得多。

2、分區(qū)數(shù)據(jù)庫架構(gòu)。在基于微服務(wù)的應(yīng)用程序中，不同服務(wù)所用的數(shù)據(jù)庫不同，開發(fā)者需要更新某一業(yè)務(wù)服務(wù)時(shí)會變得復(fù)雜。

3、測試微服務(wù)應(yīng)用程序也將變得復(fù)雜。

4、微服務(wù)應(yīng)用程序通常由大量的服務(wù)組成，因此部署基于微服務(wù)的應(yīng)用程序也是相當(dāng)復(fù)雜的。

“單身好”還是“入微好”呢？

單體架構(gòu)和微服務(wù)各有各的優(yōu)缺點(diǎn)，并不是說誰好誰壞，更重要的是根據(jù)項(xiàng)目做架構(gòu)選型。

比如，單體架構(gòu)模式只適用于簡單、輕量級的應(yīng)用程序，如果使用它來構(gòu)建復(fù)雜應(yīng)用，最終會陷入痛苦的境地。微服務(wù)架構(gòu)模式雖然真正應(yīng)用起來復(fù)雜，但是長遠(yuǎn)來看，它是復(fù)雜、持續(xù)發(fā)展應(yīng)用的一個(gè)更好的選擇。

在云原生的時(shí)代，企業(yè)需要快速，持續(xù)，可靠，規(guī)模化地交付業(yè)務(wù)軟件，為了更好的利用云環(huán)境帶來的彈性能力，微服務(wù)架構(gòu)逐漸成為了中大型企業(yè)應(yīng)用架構(gòu)的不二選擇。

但是由于微服務(wù)架構(gòu)的復(fù)雜性，企業(yè)想要管理好基于微服務(wù)架構(gòu)的應(yīng)用，也需要具備更高的能力。單單只是進(jìn)行微服務(wù)的治理，已經(jīng)顯得有點(diǎn)單薄，無法解決企業(yè)的癥結(jié)。企業(yè)的IT管理者開始重視微服務(wù)從定義、開發(fā)、質(zhì)量到使用的全方位管理，另外由于微服務(wù)架構(gòu)具備的復(fù)用性優(yōu)勢，在企業(yè)中建立微服務(wù)的運(yùn)營能力也成為了一種訴求。

如何解決微服務(wù)的缺點(diǎn)？

以往對于微服務(wù)人們更加強(qiáng)調(diào)微服務(wù)的治理，kaiyun開云創(chuàng)新認(rèn)為一個(gè)服務(wù)涉及到創(chuàng)建、開發(fā)、發(fā)布、使用、運(yùn)營等多個(gè)階段，單單強(qiáng)調(diào)在使用階段的微服務(wù)治理是不夠全面的，因此我們提出了服務(wù)全生命周期管理模型：

· 服務(wù)的創(chuàng)建

· 服務(wù)的定義

· 服務(wù)的開發(fā)

· 服務(wù)的質(zhì)量

· 服務(wù)的上架

· 服務(wù)的使用

· 服務(wù)的監(jiān)控

· 服務(wù)的治理

· 服務(wù)的運(yùn)營

· 服務(wù)的運(yùn)用

CloudOS，讓微服務(wù)“更簡單”

CloudOS將通過全面的產(chǎn)品能力，幫助企業(yè)對一個(gè)服務(wù)的全部生命周期進(jìn)行管理，幫助企業(yè)更好的建設(shè)微服務(wù)為核心的IT架構(gòu)：