這篇文章主要講解了“SOA架構和微服務架構的區別是什么”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“SOA架構和微服務架構的區別是什么”吧!
首先SOA和微服務架構一個層面的東西,而對于ESB和微服務網關是一個層面的東西,一個談到是架構風格和方法,一個談的是實現工具或組件。
2.微服務架構:其實和 SOA 架構類似,微服務是在 SOA 上做的升華,微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”,原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。
微服務架構 = 美團即時物流的分布式系統架構設計80%的SOA服務架構思想 + 100%的組件化架構思想 + 80%的領域建模思想
1.ESB(企業服務總線):簡單 來說 ESB 就是一根管道,用來連接各個服務節點。為了集 成不同系統,不同協議的服務,ESB 做了消息的轉化解釋和路由工作,讓不同的服務互聯互通;
2.API網關:API網關是一個服務器,是系統的唯一入口。從面向對象設計的角度看,它與外觀模式類似。
API網關封裝了系統內部架構,為每個客戶端提供一個定制的API。它可能還具有其它職責,如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。為什么微服務一定要有網關?這篇推薦你看下。
API網關方式的核心要點是,所有的客戶端和消費端都通過統一的網關接入微服務,在網關層處理所有的非業務功能。通常,網關也是提供REST/HTTP的訪問API。服務端通過API-GW注冊和管理服務。
系統集成:站在系統的角度,解決企業系統間的通信問 題,把原先散亂、無規劃的系統間的網狀結構,梳理成 規整、可治理的系統間星形結構,這一步往往需要引入一些產品,比如 ESB、以及技術規范、服務管理規范;這一步解決的核心問題是【有序】
系統的服務化:站在功能的角度,把業務邏輯抽象成 可復用、可組裝的服務,通過服務的編排實現業務的 快速再生,目的:把原先固有的業務功能轉變為通用 的業務服務,實現業務邏輯的快速復用;這一步解決 的核心問題是【復用】
業務的服務化:站在企業的角度,把企業職能抽象成 可復用、可組裝的服務;把原先職能化的企業架構轉變為服務化的企業架構,進一步提升企業的對外服務能力;“前面兩步都是從技術層面來解決系統調用、系統功能復用的問題”。第三步,則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】
開發者不再需要協調其它服務部署對本服務的影響。
開發者可以自由選擇開發技術,提供 API 服務
每個微服務有自己私有的數據庫持久化業務數據
每個微服務只能訪問自己的數據庫,而不能訪問其它服務的數據庫
某些業務場景下,需要在一個事務中更新多個數據庫。這種情況也不能直接訪問其它微服務的數據庫,而是通過對于微服務進行操作。
數據的去中心化,進一步降低了微服務之間的耦合度,不同服務可以采用不同的數據庫技術(SQL、NoSQL等)。在復雜的業務場景下,如果包含多個微服務,通常在客戶端或者中間層(網關)處理。
Java EE部署架構,通過展現層打包WARs,業務層劃分到JARs最后部署為EAR一個大包,而微服務則打開了這個黑盒子,把應用拆分成為一個一個的單個服務,應用Docker技術,不依賴任何服務器和數據模型,是一個全棧應用,可以通過自動化方式獨立部署。
每個服務運行在自己的進程中,通過輕量的通訊機制聯系,經常是基于HTTP資源API,這些服務基于業務能力構建,能實現集中化管理(因為服務太多啦,不集中管理就無法DevOps啦)。
感謝各位的閱讀,以上就是“SOA架構和微服務架構的區別是什么”的內容了,經過本文的學習后,相信大家對SOA架構和微服務架構的區別是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。