如何理解微服務(wù)

這篇文章主要講解了“如何理解微服務(wù)”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“如何理解微服務(wù)”吧！

前言

當(dāng)組織開始構(gòu)建更復(fù)雜的應(yīng)用程序時(shí)，編寫單體應(yīng)用程序的做法變得越來越成問題，微服務(wù)就應(yīng)運(yùn)而生。

傳統(tǒng)上，應(yīng)用程序是作為單體構(gòu)建的，所有代碼都集中在一個(gè)大的代碼庫中。由于沒有明確區(qū)分不同功能，因此更新應(yīng)用程序的一部分時(shí)，可能會無意中影響到完全不相關(guān)的功能。即使進(jìn)行簡單的更改，你也必須重新部署整個(gè)應(yīng)用程序，如果出現(xiàn)問題，則所有內(nèi)容都會受到影響，而不僅僅是要被更新或擴(kuò)展的組件。

針對這個(gè)問題，我們可以通過將單體架構(gòu)拆分成模塊（半獨(dú)立組件）來解決，盡管它可能比實(shí)現(xiàn)微服務(wù)簡單得多，但它從未真正流行起來。

面向服務(wù)的體系結(jié)構(gòu)（SOA）吸引了很多人，但很大程度上失敗了，主要是因?yàn)樗粝铝嗽S多未解決的問題，例如如何正確拆分服務(wù)?；谖⒎?wù)的體系結(jié)構(gòu)是一種更具說明性的SOA類型，它源于現(xiàn)實(shí)世界的用例，并已被眾多組織成功采用。

微服務(wù)只不過是一種模塊化架構(gòu)，不同模塊間通過網(wǎng)絡(luò)進(jìn)行通信。

什么是微服務(wù)？

微服務(wù)是小型的自治應(yīng)用程序組件，它們一起構(gòu)成一個(gè)應(yīng)用程序。他們從SOA繼承了基本的操作模型，但是以一種更具說明性的方式對其進(jìn)行了擴(kuò)展。微服務(wù)通常被認(rèn)為是一個(gè)獨(dú)立部分，由一個(gè)團(tuán)隊(duì)維護(hù)。

微服務(wù)為什么重要？由上文可知，要更新應(yīng)用程序，我們可以獨(dú)立更新和部署微服務(wù)，而不必重新部署整個(gè)應(yīng)用程序。它們還允許單個(gè)微服務(wù)團(tuán)隊(duì)完全專注于單個(gè)業(yè)務(wù)流程，而無需了解整個(gè)應(yīng)用程序。

為此，微服務(wù)具有以下屬性：

• 松耦合：每個(gè)服務(wù)都是自治的，只能松散地連接到系統(tǒng)的其余部分。這意味著它具有自己的生命周期，并且可以獨(dú)立部署，更新，擴(kuò)展和刪除。

• 高內(nèi)聚性：具有相關(guān)行為的代碼組合在一起。通過將所有相關(guān)行為分組在一起，工程師僅在需要更改特定行為時(shí)才在一個(gè)地方更新代碼。

• 信息隱藏：每個(gè)微服務(wù)僅共享其他服務(wù)所需的數(shù)據(jù)，并僅隱藏與其自己的流程相關(guān)的數(shù)據(jù)。數(shù)據(jù)共享可能會無意間導(dǎo)致耦合，因此應(yīng)始終謹(jǐn)慎。

為了充當(dāng)一個(gè)有凝聚力的應(yīng)用程序，所有這些不同的自治服務(wù)都通過網(wǎng)絡(luò)接口進(jìn)行通信。這為大量通信帶來了新的挑戰(zhàn)。順便說一下，這就是服務(wù)網(wǎng)格發(fā)揮作用的地方。

現(xiàn)在我們知道什么是微服務(wù)，讓我們探究組織為什么采用微服務(wù)。

微服務(wù)的好處

無論是通過使服務(wù)與團(tuán)隊(duì)保持一致來解決“開發(fā)人員問題”，還是降低采用新技術(shù)的風(fēng)險(xiǎn)，或是減輕部署的復(fù)雜度和提高可伸縮性，采用微服務(wù)都會帶來很多好處。讓我們仔細(xì)看看：

• 自治團(tuán)隊(duì)：微服務(wù)允許小型團(tuán)隊(duì)完全擁有服務(wù)的整個(gè)生命周期。這樣可以提高責(zé)任心，代碼質(zhì)量和工作滿意度。對于大多數(shù)大型組織而言，這種“人員分配”是采用微服務(wù)方法的主要原因之一。

• 技術(shù)的異構(gòu)性：開發(fā)人員理論上可以使用不同的語言和不同的技術(shù)來構(gòu)建每個(gè)服務(wù)。這使開發(fā)人員能夠?yàn)樵撎囟ǚ?wù)選擇最佳技術(shù)，而不是采用更為傳統(tǒng)的標(biāo)準(zhǔn)化，一刀切的方法。

• 降低采用新技術(shù)的風(fēng)險(xiǎn)：開發(fā)人員還可以在低風(fēng)險(xiǎn)服務(wù)中試驗(yàn)新技術(shù)，因?yàn)橹莱隽它c(diǎn)問題，不會影響系統(tǒng)的其余部分。由于風(fēng)險(xiǎn)是采用新技術(shù)的最大障礙，因此這是一個(gè)巨大的優(yōu)勢。

• 彈性：當(dāng)組件發(fā)生故障時(shí)，它不一定會影響到系統(tǒng)的其他部分。但請注意，應(yīng)用程序僅在其體系結(jié)構(gòu)允許的范圍內(nèi)具有彈性。如果沒有良好的代碼慣例（例如跟蹤，可觀察性和熔斷機(jī)智），那么小故障仍然可以在復(fù)雜的系統(tǒng)中級聯(lián)。

• 可擴(kuò)展性：要擴(kuò)展任何一項(xiàng)功能，你只需擴(kuò)展該微服務(wù)，而不是擴(kuò)展整個(gè)單體應(yīng)用程序即可。

• 易于部署：如果更新一行代碼，只需更新和重新部署該特定的微服務(wù)，而不是重新部署整個(gè)單體應(yīng)用程序。相反，回滾服務(wù)比回滾整個(gè)應(yīng)用程序容易得多。Docker和Kubernetes之類的工具已大大降低了部署和回滾的成本。

• 可替換性：替換應(yīng)用程序中的微服務(wù)比替換單體應(yīng)用中的組件要容易得多。

微服務(wù)的最佳實(shí)踐

如上所述，SOA實(shí)現(xiàn)之所以困難，原因之一是它們?nèi)狈Χx服務(wù)邊界的指導(dǎo)。讓我們看看微服務(wù)如何解決這個(gè)問題。

定義服務(wù)邊界

每個(gè)微服務(wù)都具有圍繞業(yè)務(wù)域建模的特定功能，業(yè)務(wù)域解決了特定的業(yè)務(wù)問題。例如，使用Gmail，其業(yè)務(wù)領(lǐng)域包括使世界各地的人們能夠通過電子郵件進(jìn)行通信的所有功能。

業(yè)務(wù)域由多個(gè)有限上下文組成：與同一應(yīng)用行為相關(guān)的代碼。Gmail具有多種功能，包括文本編輯，發(fā)送和接收，存檔，搜索等，所有這些功能都可能形成這樣的上下文。

但請注意，相關(guān)行為不一定與功能一一對應(yīng)。

高度自治

解耦系統(tǒng)就是要能夠獨(dú)立更改系統(tǒng)的各個(gè)部分而不會影響系統(tǒng)的其他部分。

服務(wù)間彼此了解越少，它們就越自治。更大的自主權(quán)帶來更大的彈性。理想情況下，如果一項(xiàng)服務(wù)崩潰，則其他服務(wù)仍將能夠提供該應(yīng)用程序的降級版本。

雖然解耦系統(tǒng)是最終目標(biāo)，但并非總是能夠?qū)崿F(xiàn)100％解耦。

網(wǎng)絡(luò)通訊

微服務(wù)通過其應(yīng)用程序編程接口（API）在網(wǎng)絡(luò)上進(jìn)行通信。要發(fā)送和接收消息，他們必須就網(wǎng)絡(luò)通信規(guī)則達(dá)成一致。你可能熟悉HTTP，還有更多這樣的協(xié)議。

根據(jù)網(wǎng)絡(luò)通訊的方式，可以將它們大致分為同步或異步通信。

• 同步模式：客戶端請求需要服務(wù)端即時(shí)響應(yīng)，甚至可能由于等待而阻塞。

• 異步模式：客戶端請求不會阻塞進(jìn)程，服務(wù)端的響應(yīng)可以是非即時(shí)的

同步有點(diǎn)像座機(jī)。建立連接并交換信息，并且在連接時(shí)無法接聽其他電話。此類通信通常與請求/響應(yīng)消息一起使用，其中一個(gè)服務(wù)發(fā)送請求并等待另一服務(wù)響應(yīng)。等待時(shí)，兩個(gè)服務(wù)都被阻止?？梢韵胂?，這僅在連接速度很快的情況下才可行。

異步通信更像電子郵件。你向某人發(fā)送電子郵件，通常可以繼續(xù)其他工作。收到回復(fù)后，你將再次參與。這就是異步通信的本質(zhì)：服務(wù)發(fā)送一條消息，并繼續(xù)執(zhí)行它的所有操作，直到收到響應(yīng)為止。當(dāng)網(wǎng)絡(luò)不可靠或物理距離較遠(yuǎn)時(shí)，通常使用這種通信方式。它通常與發(fā)布-訂閱（或pub-sub）模式一起使用，在該模式中，一項(xiàng)服務(wù)將發(fā)布事件，而訂閱該事件的人將得到通知。

采用那種網(wǎng)絡(luò)通訊方式，要根據(jù)實(shí)際的業(yè)務(wù)場景而定。

什么時(shí)候應(yīng)該使用微服務(wù)？

開發(fā)和維護(hù)微服務(wù)比處理單體應(yīng)用要耗費(fèi)大量精力。我們已經(jīng)看到微服務(wù)具有許多強(qiáng)大的優(yōu)勢，但這是否總是最好的方法？不，開發(fā)者應(yīng)該首選單體，除非他們有令人信服的理由不得不這樣做。

根據(jù)經(jīng)驗(yàn)，小型團(tuán)隊(duì)的小型應(yīng)用程序最好采用單體架構(gòu)，而由多個(gè)團(tuán)隊(duì)同時(shí)開發(fā)維護(hù)的大型應(yīng)用程序最好采用微服務(wù)方法。組織應(yīng)該從單體應(yīng)用程序開始，當(dāng)在需要伸縮性，性能或彈性優(yōu)勢時(shí)，可以將其細(xì)分為微服務(wù)。何時(shí)需要拆分，將在很大程度上取決于你的用例。沒有靈丹妙藥，你必須在仔細(xì)考慮后做出決定。

你可以盡早做的是保持一個(gè)干凈且模塊化良好的代碼庫。當(dāng)你開始運(yùn)行和擴(kuò)展應(yīng)用程序時(shí)，這將使構(gòu)建和擴(kuò)展變得更容易，并且當(dāng)你將單體應(yīng)用細(xì)分為微服務(wù)時(shí)，它將減少你的成本和工作量。

結(jié)合容器和Kubernetes

如上圖所述，每個(gè)微服務(wù)都放置在一個(gè)容器中，這是一種新穎的包裝機(jī)制，其概念類似于超輕量級虛擬機(jī)（VM），有助于將微服務(wù)分隔開（請注意，盡管容器在概念上類似于VM，但它們并未提供相同的隔離性或安全性保證）。盡管微服務(wù)早于容器，但容器使微服務(wù)更加簡單和更具成本效益。

Kubernetes管理你的容器化服務(wù)，以確保它們具有足夠的資源并且可以正常運(yùn)行。它充當(dāng)容器的某種數(shù)據(jù)中心操作系統(tǒng)。

簡而言之，微服務(wù)包含業(yè)務(wù)邏輯，該代碼提供業(yè)務(wù)價(jià)值。容器幫助打包微服務(wù)，以便它們與系統(tǒng)的其余部分分離。容器和Kubernetes簡化了微服務(wù)的打包和管理，并且是微服務(wù)如此流行的原因之一。

結(jié)論

盡管微服務(wù)提供了比單體架構(gòu)更大的靈活性并提供了令人難以置信的強(qiáng)大功能，但這些好處是以犧牲復(fù)雜性為代價(jià)的。組織必須仔細(xì)考慮采用微服務(wù)方法是否適合他們。

在微服務(wù)中，你越來越會聽到很多有關(guān)容器和Kubernetes的信息。這是因?yàn)樗鼈兪侵匾募夹g(shù)創(chuàng)新，可為微服務(wù)提供巨大價(jià)值。如今，大多數(shù)使用微服務(wù)的組織都會采用容器和Kubernetes來管理它。

感謝各位的閱讀，以上就是“如何理解微服務(wù)”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對如何理解微服務(wù)這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！