在本文中，我將討論什么是微服務(wù)，它們?yōu)楹稳绱酥匾?。我們將從微服?wù)歷史以及它們與單體架構(gòu)的比較開始。然后，我們將討論微服務(wù)架構(gòu)的一些原理，其潛在的缺點，以及如何與容器和Kubernetes等現(xiàn)代工具結(jié)合使用。

射洪網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)建站于2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。

前言

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

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

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

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

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

什么是微服務(wù)？

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

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

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

• 松耦合：每個服務(wù)都是自治的，只能松散地連接到系統(tǒng)的其余部分。這意味著它具有自己的生命周期，并且可以獨立部署，更新，擴展和刪除。
• 高內(nèi)聚性：具有相關(guān)行為的代碼組合在一起。通過將所有相關(guān)行為分組在一起，工程師僅在需要更改特定行為時才在一個地方更新代碼。
• 信息隱藏：每個微服務(wù)僅共享其他服務(wù)所需的數(shù)據(jù)，并僅隱藏與其自己的流程相關(guān)的數(shù)據(jù)。數(shù)據(jù)共享可能會無意間導(dǎo)致耦合，因此應(yīng)始終謹慎。

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

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

微服務(wù)的好處

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

• 自治團隊：微服務(wù)允許小型團隊完全擁有服務(wù)的整個生命周期。這樣可以提高責(zé)任心，代碼質(zhì)量和工作滿意度。對于大多數(shù)大型組織而言，這種“人員分配”是采用微服務(wù)方法的主要原因之一。
• 技術(shù)的異構(gòu)性：開發(fā)人員理論上可以使用不同的語言和不同的技術(shù)來構(gòu)建每個服務(wù)。這使開發(fā)人員能夠為該特定服務(wù)選擇最佳技術(shù)，而不是采用更為傳統(tǒng)的標(biāo)準化，一刀切的方法。
• 降低采用新技術(shù)的風(fēng)險：開發(fā)人員還可以在低風(fēng)險服務(wù)中試驗新技術(shù)，因為知道出了點問題，不會影響系統(tǒng)的其余部分。由于風(fēng)險是采用新技術(shù)的最大障礙，因此這是一個巨大的優(yōu)勢。
• 彈性：當(dāng)組件發(fā)生故障時，它不一定會影響到系統(tǒng)的其他部分。但請注意，應(yīng)用程序僅在其體系結(jié)構(gòu)允許的范圍內(nèi)具有彈性。如果沒有良好的代碼慣例（例如跟蹤，可觀察性和熔斷機智），那么小故障仍然可以在復(fù)雜的系統(tǒng)中級聯(lián)。
• 可擴展性：要擴展任何一項功能，你只需擴展該微服務(wù)，而不是擴展整個單體應(yīng)用程序即可。
• 易于部署：如果更新一行代碼，只需更新和重新部署該特定的微服務(wù)，而不是重新部署整個單體應(yīng)用程序。相反，回滾服務(wù)比回滾整個應(yīng)用程序容易得多。Docker和Kubernetes之類的工具已大大降低了部署和回滾的成本。
• 可替換性：替換應(yīng)用程序中的微服務(wù)比替換單體應(yīng)用中的組件要容易得多。

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

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

定義服務(wù)邊界

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

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

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

高度自治

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)合容器和Kubernetes

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

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

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

結(jié)論

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

在微服務(wù)中，你越來越會聽到很多有關(guān)容器和Kubernetes的信息。這是因為它們是重要的技術(shù)創(chuàng)新，可為微服務(wù)提供巨大價值。如今，大多數(shù)使用微服務(wù)的組織都會采用容器和Kubernetes來管理它。

當(dāng)前名稱：這篇文章讓你花10分鐘讀懂微服務(wù)
URL網(wǎng)址：http://uogjgqi.cn/article/codhdjp.html