什么是微服務(wù)體系架構(gòu)

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

微服務(wù)體系結(jié)構(gòu)描述了一種使用松散耦合服務(wù)集合開發(fā)應(yīng)用程序的方法。以前，應(yīng)用程序是基于集中式多層體系結(jié)構(gòu)的。在大型機(jī)和臺式機(jī)的時代，這種方法很有效。但在云計(jì)算和移動設(shè)備中，后端必須隨時可用于各種設(shè)備。Bug修復(fù)和特性必須在不停機(jī)或不部署整個應(yīng)用程序的情況下快速交付。

微服務(wù)是獨(dú)立部署的，通過webapi或消息隊(duì)列進(jìn)行通信以響應(yīng)傳入事件。它們協(xié)同工作以提供各種功能，如用戶界面前端、推薦、物流、計(jì)費(fèi)等。

微服務(wù)通常在容器中運(yùn)行。容器簡化了微服務(wù)的部署，但即使沒有容器，微服務(wù)也可以運(yùn)行。

微服務(wù)是封裝業(yè)務(wù)場景的自主獨(dú)立服務(wù)。它包含 代碼 和 狀態(tài) 。通常，微服務(wù)甚至包含自己的數(shù)據(jù)存儲。這使得它具有獨(dú)立的可版本性、可擴(kuò)展性和可部署性。微服務(wù)是松散耦合的，通過使用http等協(xié)議的定義良好的接口與其他微服務(wù)交互。它們在出現(xiàn)故障時 保持一致和可用 。微服務(wù)是可獨(dú)立發(fā)布的。每個微服務(wù)都可以自己擴(kuò)展，而不必?cái)U(kuò)展整個應(yīng)用程序。

微服務(wù)有哪些類型？

大體上，有兩種類型的微服務(wù)：

無狀態(tài)：沒有狀態(tài)或者可以從外部存儲（緩存/數(shù)據(jù)庫）檢索。它可以擴(kuò)展而不影響狀態(tài)?？梢杂蠳個實(shí)例。示例：web前端、協(xié)議網(wǎng)關(guān)等。無狀態(tài)服務(wù)不是緩存或數(shù)據(jù)庫。它經(jīng)常訪問元數(shù)據(jù)，沒有實(shí)例關(guān)聯(lián)，節(jié)點(diǎn)丟失不明顯。

有狀態(tài)：保持一個強(qiáng)硬、權(quán)威的狀態(tài)。對于大型超規(guī)模應(yīng)用程序，狀態(tài)保持在接近計(jì)算的狀態(tài)。N通過復(fù)制和本地持久性實(shí)現(xiàn)一致的拷貝。示例：數(shù)據(jù)庫、文檔、工作流、用戶配置文件、購物車等。有狀態(tài)服務(wù)由數(shù)據(jù)庫和緩存組成，節(jié)點(diǎn)丟失是一個值得注意的事件。它有時是一個保存大量數(shù)據(jù)的自定義應(yīng)用程序。

作為一種變體，一位作者確定了三種類型：無狀態(tài)（計(jì)算）、持久性（存儲）、聚合（編排）。聚合微服務(wù)依賴于其他微服務(wù)，因此具有網(wǎng)絡(luò)和磁盤I/O依賴性。

當(dāng)我們將微服務(wù)視為分層體系結(jié)構(gòu)時，我們可以確定以下類型：

• 核心/原子服務(wù) ：細(xì)粒度的自包含服務(wù)。沒有外部服務(wù)依賴項(xiàng)。主要是業(yè)務(wù)邏輯。通常沒有網(wǎng)絡(luò)電話。

• 復(fù)合/集成服務(wù) ：由多個核心服務(wù)組成的業(yè)務(wù)功能。包括業(yè)務(wù)邏輯和網(wǎng)絡(luò)調(diào)用。實(shí)現(xiàn)路由、轉(zhuǎn)換、編排、彈性和穩(wěn)定性模式。通常與遺留或?qū)Ｓ邢到y(tǒng)接口。

• API/Edge服務(wù) ：一組選定的集成服務(wù)和核心服務(wù)，作為用戶的托管API提供。實(shí)現(xiàn)路由、API版本控制、API安全和限制。

微服務(wù)與API有何不同？

API不是微服務(wù)，微服務(wù)也不是API的實(shí)現(xiàn)。API是一個接口。微服務(wù)是一個組件。術(shù)語“ micro ”指的是組件，而不是公開接口的粒度。微服務(wù)可用于公開一個或多個api。然而，并不是所有的微服務(wù)組件都公開api。

微服務(wù)架構(gòu)和面向服務(wù)架構(gòu)（SOA）之間的關(guān)系是什么？

SOA和微服務(wù)架構(gòu)涉及不同的范圍。SOA與企業(yè)服務(wù)公開相關(guān)，而微服務(wù)體系結(jié)構(gòu)與應(yīng)用程序體系結(jié)構(gòu)相關(guān)。兩者都試圖實(shí)現(xiàn)許多相同的事情（將業(yè)務(wù)功能創(chuàng)建為獨(dú)立組件），但規(guī)模不同。它們在可維護(hù)性、粒度、敏捷性等方面有所不同。SOA是一個非常寬泛的術(shù)語，微服務(wù)是該用法的一個子集。Netflix指出，微服務(wù)是“細(xì)粒度SOA”。微服務(wù)被認(rèn)為是“SOA做得對”。

一些微服務(wù)原則與SOA有很大的不同：

1. 重用不是目標(biāo) ：由于通用組件所創(chuàng)建的依賴關(guān)系，不鼓勵重用通用組件。最好通過復(fù)制重復(fù)使用。

2. 同步是不好的 ：進(jìn)行諸如API或web服務(wù)之類的同步調(diào)用會創(chuàng)建實(shí)時依賴關(guān)系。微服務(wù)之間盡可能使用消息傳遞。

3. 運(yùn)行時服務(wù)發(fā)現(xiàn) ：假定組件是易失性的。因此，客戶機(jī)通常有責(zé)任在實(shí)例之間找到甚至負(fù)載平衡。

4. 采用了數(shù)據(jù)復(fù)制技術(shù) ：事件源等技術(shù)可以產(chǎn)生多個獨(dú)立的數(shù)據(jù)“視圖”，確保微服務(wù)真正解耦。

在設(shè)計(jì)微服務(wù)架構(gòu)時，需要牢記哪些重要原則？

一般來說，在設(shè)計(jì)微服務(wù)體系結(jié)構(gòu)時，以下原則是很好的：圍繞業(yè)務(wù)領(lǐng)域建模、自動化文化、隱藏實(shí)現(xiàn)細(xì)節(jié)、高度可觀察、分散所有內(nèi)容、隔離故障、消費(fèi)者優(yōu)先、獨(dú)立部署。

使用微服務(wù)架構(gòu)有什么好處？

優(yōu)勢跨越開發(fā)和運(yùn)營。簡單地說，我們注意到以下優(yōu)勢：大規(guī)模構(gòu)建和運(yùn)營服務(wù)，提高資源利用率以降低成本，故障隔離，持續(xù)創(chuàng)新，小型專注團(tuán)隊(duì)，使用任何語言或框架。

可伸縮性來自于微服務(wù)支持的模塊化。由于容器的存在，微服務(wù)在各種環(huán)境中的部署變得更加容易。由于服務(wù)的隔離，還有一個安全優(yōu)勢：對一個服務(wù)的攻擊不會影響其他服務(wù)。

微服務(wù)是關(guān)于代碼和開發(fā)的。容器是關(guān)于部署的。容器支持微服務(wù)。容器提供了隔離的環(huán)境，因此是部署微服務(wù)的理想選擇。但是，可以在沒有容器的情況下部署微服務(wù)。例如，可以在amazonec2上獨(dú)立部署微服務(wù)。每個微服務(wù)都可以在自己的自動縮放組中獨(dú)立縮放。

為什么我不應(yīng)該為我的應(yīng)用程序采用微服務(wù)呢？

由于應(yīng)用程序是跨微服務(wù)分布的，這樣的分布式系統(tǒng)更難管理和監(jiān)視。操作復(fù)雜性隨著微服務(wù)及其實(shí)例數(shù)量的增加而增加，特別是當(dāng)它們被動態(tài)創(chuàng)建和銷毀時。網(wǎng)絡(luò)呼叫可能很慢，有時甚至?xí)　?nbsp;由于是分布式的，很難保持強(qiáng)一致性，應(yīng)用程序必須確保最終的一致性。

微服務(wù)需要更多的時間來規(guī)劃和劃分應(yīng)用程序。它們的設(shè)計(jì)應(yīng)該考慮到失敗。當(dāng)您正在構(gòu)建一個最小可行產(chǎn)品（MVP）或嘗試評估什么是有效的或可以為業(yè)務(wù)增加價值的，那么單一的方法會更快更容易。只有當(dāng)你的想法和商業(yè)價值被證明后需要擴(kuò)展時，才采用微服務(wù)。

如果您管理的是一個遺留應(yīng)用程序，那么遷移到微服務(wù)的工作可能需要相當(dāng)大的成本。技術(shù)堆?？赡鼙葐我粦?yīng)用程序大得多。應(yīng)用程序?qū)W(wǎng)絡(luò)及其性能有很大的依賴性。微服務(wù)可以獨(dú)立測試，但要測試整個應(yīng)用程序更為困難。

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