面試:SOA架構和微服務架構的區別是什麼?

2022-01-01 Java知音

技術文章第一時間送達！

作者：zpoison

blog.csdn.net/zpoison/article/details/80729052

1.SOA架構和微服務架構的區別

首先SOA和微服務架構一個層面的東西，而對於ESB和微服務網關是一個層面的東西，一個談到是架構風格和方法，一個談的是實現工具或組件。

1.SOA（Service Oriented Architecture）「面向服務的架構」:他是一種設計方法，其中包含多個服務， 服務之間通過相互依賴最終提供一系列的功能。一個服務 通常以獨立的形式存在於作業系統進程中。各個服務之間 通過網絡調用。

2.微服務架構:其實和 SOA 架構類似，微服務是在 SOA 上做的升華，微服務架構強調的一個重點是「業務需要徹底的組件化和服務化」，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。

微服務架構 = 80%的SOA服務架構思想 + 100%的組件化架構思想 + 80%的領域建模思想

2.ESB和微服務API網關。

1.ESB（企業服務總線），簡單 來說 ESB 就是一根管道，用來連接各個服務節點。為了集 成不同系統，不同協議的服務，ESB 做了消息的轉化解釋和路由工作，讓不同的服務互聯互通；

2.API網關:API網關是一個伺服器，是系統的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統內部架構，為每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。


3.SOA架構特點：

系統集成：站在系統的角度，解決企業系統間的通信問 題，把原先散亂、無規劃的系統間的網狀結構，梳理成 規整、可治理的系統間星形結構，這一步往往需要引入 一些產品，比如 ESB、以及技術規範、服務管理規範；這一步解決的核心問題是【有序】

系統的服務化：站在功能的角度，把業務邏輯抽象成 可復用、可組裝的服務，通過服務的編排實現業務的 快速再生，目的：把原先固有的業務功能轉變為通用 的業務服務，實現業務邏輯的快速復用；這一步解決 的核心問題是【復用】

業務的服務化：站在企業的角度，把企業職能抽象成 可復用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；「前面兩步都是從技術層面來解決系統調用、系統功能復用的問題」。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】

4.微服務架構特點：1.通過服務實現組件化2.按業務能力來劃分服務和開發團隊3.去中心化

每個微服務有自己私有的資料庫持久化業務數據

每個微服務只能訪問自己的資料庫，而不能訪問其它服務的資料庫

某些業務場景下，需要在一個事務中更新多個資料庫。這種情況也不能直接訪問其它微服務的資料庫，而是通過對於微服務進行操作。

數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以採用不同的資料庫技術（SQL、NoSQL等）。在複雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。

4.基礎設施自動化（devops、自動化部署）

Java EE部署架構，通過展現層打包WARs，業務層劃分到JARs最後部署為EAR一個大包，而微服務則打開了這個黑盒子，把應用拆分成為一個一個的單個服務，應用Docker技術，不依賴任何伺服器和數據模型，是一個全棧應用，可以通過自動化方式獨立部署，每個服務運行在自己的進程中，通過輕量的通訊機制聯繫，經常是基於HTTP資源API，這些服務基於業務能力構建，能實現集中化管理（因為服務太多啦，不集中管理就無法DevOps啦）。

5.主要區別：

6.Dubbo服務的最佳實踐分包粒度

儘可能把接口設置成粗粒度，每個服務方法代表一個獨立的功能，而不是某個功能的步驟。否則就會涉及到分布式事務

服務接口建議以業務場景為單位劃分。並對相近業務做抽象，防止接口暴增

不建議使用過於抽象的通用接口 T T<泛型>，接口沒有明確的語義，帶來後期的維護

版本

每個接口都應該定義版本，為後續的兼容性提供前瞻性的考慮 version （maven -snapshot）

建議使用兩位版本號，因為第三位版本號表示的兼容性升級，只有不兼容時才需要變更服務版本

當接口做到不兼容升級的時候，先升級一半或者一臺提供者為新版本，再將消費全部升級新版本，然後再將剩下的一半提供者升級新版本

預發布環境

推薦用法

配置管理員信息

配置dubbo緩存文件

參考文獻：

http://www.uml.org.cn/zjjs/201708083.asp
https://zhidao.baidu.com/question/1899225333752310100.html
http://blog.sina.com.cn/s/blog_493a84550102wq50.html

推薦閱讀(點擊即可跳轉閱讀)

1.SpringBoot內容聚合

2.面試題內容聚合

3.設計模式內容聚合

4.Mybatis內容聚合

5.多線程內容聚合

覺得不錯？歡迎轉發分享給更多人

我知道你 「在看」

相關焦點

  • 微服務與SOA架構有什麼本質區別?
    21CTO導讀：了解微服務和SOA架構之間的真正差異，本文講解兩者區別以及開發中不同的用法。
  • 微服務與SOA架構(一)
    微服務和SOA都被認為是基於服務的架構，這意味著這兩種架構模式都非常強調將「服務」作為其架構中的首要組件，用於實現各種功能（包括業務層面和非業務層面）。微服務和SOA是兩種差異很大的架構模式，但是他們仍有一些相同的特徵。
  • 微服務架構談系列(3):SOA VS 微服務
    2014年：James Lewis和 Martin Fowler合寫了關於微服務的一篇學術性的文章，詳細闡述了微服務。由於微服務的理念中也包含了「服務」的概念，而SOA中也有「服務」的概念，我們自然而言地會提出疑問：微服務與SOA是什麼關係，有什麼區別，為何有了SOA還要提微服務？
  • 淺談微服務架構設計
    當你想單拎出一個服務時，發現幾乎不可能，因為每一個微服務都依賴於其他微服務，同時又被其他微服務所依賴。微服務架構的設計一定是與時俱進的，因此我們也不可能在第一次設計時就設計出一個完美的架構體系。因此，在最初構建粗顆粒度的服務要優於過細的微服務，因為粗粒度的微服務會隨著系統升級而逐漸細化形成粒度合適的微服務，而過細的微服務在構建和管理上非常複雜，也難以重構、合併成合適的大小。
  • Spring Cloud 微服務架構的五臟六腑!
    本文將從 Spring Cloud 出發，分兩小節講述微服務框架的「五臟六腑」：第一小節「服務架構」旨在說明的包括兩點，一服務架構是什麼及其必要性；二是服務架構的基本組成。為什麼第一節寫服務架構而不是微服務架構呢？原因主要是微服務架構本身與服務架構有著千絲萬縷的關係，服務架構是微服務架構的根基。
  • 微服務架構體系
    微服務關注的是服務拆分力度，即：一個服務要拆分到多大的維度合適Spring Cloud 和 Dubbo說到微服務，兩大框架的討論肯定跑不了區別Spring Cloud 和 K8s微服務關注什麼差不多一半關注點是和運維相關的。
  • 一文看懂Java微服務架構,WEB2.0,垂直架構,分布式架構,微服務架構
    Java微服務架構目錄：了解開發環境&生成環境WEB1.0 & WEB2.0垂直架構
  • 微服務架構-設計總結
    三、傳統開發模式和微服務的區別四、微服務的具體特徵五、SOA和微服務的區別六、如何具體實踐微服務七、常見的微服務設計模式和應用八、微服務的優點和缺點九、思考：意識的轉變十、參考資料和推薦閱讀一、微服務架構介紹微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦
  • Medium 的微服務架構
    我們已經建立了幾個附屬服務，但我們還沒有制定採用微服架構系統的戰略。隨著系統變得更加複雜和團隊的壯大，我們在 2018年初遷移到了微服務架構。在這篇文章中，我們希望分享我們的經驗，有效地做到這一點，避免微服務症候群。微服務架構是什麼？
  • 微服務架構談系列(2):微服務到底是什麼鬼?
    導語：微服務架構如何與更廣泛的軟體架構概念相結合？什麼是服務？服務的規模有多重要？為了回答這些問題，我們需要退後一步，看看軟體架構的含義。軟體的架構是一種抽象的結構，它由軟體的各個組成部分和這些部分之間的依賴關係構成。正如你將在本文中看到的，軟體的架構是多維的，因此有多種方法可以對其進行描述。架構很重要的原因是它決定了應用程式的質量屬性或能力。
  • 微服務架構最強講解,通俗易懂,寫得太好了!
    ———— 百度百科三、傳統開發模式和微服務的區別先來看看傳統的web開發方式，通過對比比較容易理解什麼是Microservice Architecture。和Microservice相對應的，這種方式一般被稱為Monolithic（單體式開發）。
  • 分布式微服務架構竟然可以這麼玩?我知道的太晚了
    優秀的開發人員和架構師成為了這個變革節點上最「炙手可熱」的人才，但在這其中，有人致力於將原理運用到實踐中，逐漸培養了自己高效解決問題的思維；卻還有一部分人仍舊缺乏應對不斷變革和發展的環境的能力。微服務架構作為一種架構模式，近幾年間備受關注，它提倡將單一應用程式劃分成一組小的服務，互相協調、互相配合，為用戶提供最終價值。
  • 微服務架構-從理想到現實
    ，而是結合我們自己所做的一些微服務架構實踐情況做一些總結和復盤。也就是說微服務架構實際是傳統組件化架構設計思想的進一步強化，強化的核心就是獨立和解耦。微服務架構思想的一個重點就是單體應用的拆分。即使對於常說的高可用性，也僅僅是高可用性和彈性擴展能力增加，但是對於高可靠性反而是降低。那麼一個企業或團隊是什麼原因實踐微服務？僅僅是微服務是一種架構發展趨勢，是技術熱點，是網際網路大廠都在用嗎？而實際對於很多企業應用微服務可以看到，更多是團隊裡面總有一些技術狂熱份子，熱衷於新架構，新技術，但是對於這些技術究竟解決了哪些業務場景下的問題並不關心。
  • 微服務架構設計
    這種運行和部署方式能夠賦予系統靈活的代碼組織方式和發布節奏，使得快速交付和應對變化成為可能。·獨立開發和演化技術選型靈活，不受遺留系統技術約束。合適的業務問題選擇合適的技術可以獨立演化。服務與服務之間採取與語言無關的API進行集成。相對單體架構，微服務架構是更面向業務創新的一種架構模式。
  • 微服務架構(Microservice Architecture)
    ———— 百度百科三、傳統開發模式和微服務的區別先來看看傳統的web開發方式，通過對比比較容易理解什麼是Microservice Architecture
  • 放棄微服務,我們為什麼重回單體架構?
    InVision 公司的技術架構經歷了從微服務合併回單體架構的過程，本文具體分析了這種架構遷移的技術原因和組織原因。
  • Medium的微服務架構解析
    何為微服務架構首先，我們來思考微服務之架構是什麼，不是什麼。微服務是拯救那些過載和混亂軟體工程的技術趨勢之一。在Medium團隊，我們認為它是：「在微服務架構中，多個鬆散耦合的服務協同工作。這是實現微服務架構全部潛力的唯一途徑，錯失任何一個都會成為反模式。如果不是單一的目標，每個微服務慢慢就會做越來越多的事情，成長為多個「單片」服務。我們不會從微服務架構中獲得所有的好處，它會增加我們的運維成本。如果沒有做到鬆耦合，對一項目服務的更改就會波及到其它服務，因此我們無法快速並安全的發布更新，這便是微服務架構的核心優勢。
  • 組件化、模塊化、集中式、分布式、服務化、面向服務的架構、微服務架構
    模塊化和組件化的區別從上面的定義中可以看出，組件化和模塊化的意思差不多，主要思想都是分而治之。只是一個把拆分之後的每個片段叫做組件、另一個把拆分之後的片段叫做模塊。那麼這兩種拆分在拆分方式上是不是有什麼不同的？關於組件化和模塊化的區別，我在網上看了好多資料，也沒有人能給出準確的回答。其實沒有準確回答的原因也比較明顯，那就是大多數時候我們真的不需要嚴格的區分這兩個名字。
  • 微服務架構雲端應用
    擁有超過12年網際網路產品開發和管理經驗，專注於網際網路技術架構設計，對產品設計、敏捷開發、安全、OKRs、大數據等領域有深入研究。現推崇反應式編程（http://www.reactivemanifesto.org/），並在多個產品中成功應用。劉總在這次分享中主要為大家介紹了什麼是徽服務，實現微服務有哪些架構模式以及微服務在實際中的應用情況。
  • 微服務下的數據架構
    ，對微服務的討論大多集中在容器或其他技術是否能很好的實施微服務，而本文將從以下幾個角度來和大家分享在微服務架構下進行數據設計需要關注的地方，旨在幫助大家在構建微服務架構時，提供一個從數據方面的視角：微服務定義微服務的優勢及架構特點微服務架構下的數據設計選擇一個合適的資料庫按照 Martin Fowler 的定義，微服務是一個軟體架構模式