微服務與SOA架構有什麼本質區別?

2022-01-01 21CTO

21CTO導讀：了解微服務和SOA架構之間的真正差異，本文講解兩者區別以及開發中不同的用法。

最近，關於這兩種架構之間的差異，或者兩者是否在差異，已經有很多人在討論。

為了深入研究引發了數百個爭論的這個問題，我們首先簡要地定義SOA和微服務架構及其它的起源，之後我們將對它們進行比較，看看如何更好地區分它們。

面向服務的架構體系（SOA）

面向服務的架構是一種軟體體系架構，其中應用程式的不同組件通過網絡通信協議向其它組件提供服務。通信可以涉及簡單的數據傳遞，或者涉及彼此協調連接服務的兩個或更多個服務。這些不同的服務執行一些小功能，例如驗證付款，創建用戶帳戶或提供社交帳號登錄等。

面向服務的架構不是關於如何模塊化應用程式，而是關於如何通過集成分布式，單獨維護和部署的軟體組件來組合應用程式。它通過技術和標準實現，使組件更容易通過網絡進行通信與協作。

SOA中有兩個主要角色：服務提供者和服務使用者。軟體代理可以扮演兩種角色。消費者（Consumer）層是用戶（人，應用程式的其他組件或第三方）與SOA交互的點，提供者（Provider）層由SOA中的所有服務組成。

SOA在90年代中期得名，當時一家名為Gartner Group的公司認識到軟體架構中的這一新興趨勢，採用它並在全球範圍內推廣。通過這樣實施，人們成功地加快了這種架構模式的採用和進一步發展。使用分布式服務作為軟體架構的第一個記錄可以追溯到80年代早期。

微服務（MicroService）

從某種程度上講，微服務是面向服務架構發展的下一步。基本上，這種架構類型是開發軟體，Web或行動應用程式作為獨立服務套件的一種特殊方式 - a.k.a微服務。創建這些服務僅用於一個特定的業務功能，例如用戶管理，用戶角色，電子商務購物車，商品展示 ，搜尋引擎，社交帳號登錄等。此外，它們之間完全相互獨立，這意味著它們可以用不同的程式語言並使用不同的資料庫，集中式服務管理幾乎不存在，微服務使用輕量級HTTP，REST或Thrift API互相進行通信。

微服務這個詞本身源於2011年5月在威尼斯附近舉辦的軟體架構師研討會。他們首次使用「微服務」這一術語來描述參與者最近在探索的共同架構風格。

2012年5月，這個小組決定將「微服務」作為最合適的名稱。事實上，微軟，亞馬遜，Netflix和Facebook等主要科技公司已經使用微服務超過十年了。在提出普遍接受的名稱之前，其他人稱他們為「微網絡服務」或「細顆粒度SOA」。

是的，乍一看我們似乎在談論與SOA相同的事情。但是，我引用微軟服務領域的先驅Martin Flower的話，他說我們應該將SOA視為微服務的超集。

那麼，它們之間真正的差異在哪裡？

我們可以說兩種架構都有相似之處而不是差異，但是，最終它們是兩種不同類型的架構。首先，我將以表格的形式介紹將架構的特定的區分部分。接下來，我將詳細闡述其中的一些內容。

我們把在上表中顯示的一些內容來進一步詳細說明，為大家解釋其中之差異：

開發 - 在這兩種體系結構中，可以使用不同的程式語言和工具開發服務，從而為開發團隊帶來技術的多樣性。可以在多個團隊中組織開發，但是，在SOA架構中，每個團隊都需要了解常見的通信機制。另一方面，通過微服務，服務可以獨立於其它服務運行和部署。因此，可以更頻繁地部署新版本的微服務或獨立擴展服務。

「有界上下文」 

SOA架構鼓勵共享組件，而微服務試圖通過「有界上下文」來最小化共享。有界上下文指的是將組件及其數據作為單個單元耦合，具有最小的依賴性。由於SOA依賴於多種服務來滿足業務請求，因此基於SOA構建的系統可能比微服務慢。

通信 - 在SOA中，ESB的單點故障可能成為影響整個系統的瓶頸。由於每個服務都通過ESB進行通信，如果其中一個服務速度變慢，可能會阻塞ESB請求該服務。而另一方面，微服務在容錯方面就要好得多。例如，如果一個微服務有內存故障，那麼只有那個微服務會受到影響，其他的微服務將繼續定期處理請求。

互操作性 - SOA通過其消息傳遞中間件組件促進多個異構協議的使用。而微服務試圖通過減少集成選擇的數量來簡化架構模式。因此，如果要在異構環境中使用不同協議併集成多個系統，則需要考慮SOA。如果可以通過相同的遠程訪問協議訪問所有服務，那麼微服務對開發團隊來說是更好的選擇。

大小 - 最後但並非不重要的是，SOA和微服務之間的主要區別在於大小和範圍。微服務中的前綴「微」指的是內部組件的顆粒度，這意味著它們必須比SOA要小得多。微服務中的服務組件通常只有一個目的，他們能做得很好。另一方面，在SOA中，服務通常包含更多業務功能，並且它們通常作為完整的子系統來實現。

小結

我們不能簡單地說一個架構比另一個架構好。它主要取決於你正在構建的應用程式之目的。SOA更適合需要與許多其它應用程式集成，用於大型複雜企業應用程式環境。較小的應用程式不適合SOA，因為它們不需要消息傳遞中間件組件。 另一方面，微服務更適合於較小且分區良好的基於Web的系統。 此外，如果你正在開發移動或Web應用程式，那麼微服務可以讓作為開發人員的你獲得更大的控制權。

最後，我們得出一個結論：兩個架構用於不同的目的 - 微服務和SOA是兩種不同類型的體系架構。

作者：Rade Despodovski

譯者：洛逸

來源：https://dzone.com/articles/microservices-vs-soa-is-there-any-difference-at-al

 

相關焦點

  • 面試:SOA架構和微服務架構的區別是什麼?
    作者：zpoisonblog.csdn.net/zpoison/article/details/807290521.SOA架構和微服務架構的區別首先SOA和微服務架構一個層面的東西，而對於ESB和微服務網關是一個層面的東西，一個談到是架構風格和方法，一個談的是實現工具或組件。
  • 微服務與SOA架構(一)
    在微服務架構中，這是非常重要的區別，因為基礎服務並不對外開放而僅作為供內部使用的私有共享服務，對其它服務可用。功能服務則提供外部訪問能力，而且不對其它服務共享。從服務角度來看微服務和SOA的最大區別在於服務粒度。如名字所示，微服務是規模較小的、細粒度的服務。更確切地說，微服務架構中的服務組件一般都是單一目的/用途的服務，只做一件事且做到極致。而對於SOA而言，服務組件規模相差可以很大，可能是很小的應用服務，也可以是很大的企業服務。實際上，很常見的一種情況是SOA架構中的某個服務組件是由一個很大規模的產品或者一個子系統來提供。
  • 微服務架構談系列(3):SOA VS 微服務
    2014年：James Lewis和 Martin Fowler合寫了關於微服務的一篇學術性的文章，詳細闡述了微服務。由於微服務的理念中也包含了「服務」的概念，而SOA中也有「服務」的概念，我們自然而言地會提出疑問：微服務與SOA是什麼關係，有什麼區別，為何有了SOA還要提微服務？
  • 微服務 yyds
    Spring Cloud 和 Dubbo 有哪些區別 ?本質區別：服務之間的通信機制的不同，Dubbo是基於RPC，Spring Cloud 是基於 HTTP 的 Restful API。6.  Spring Boot 和 Spring Cloud，請你談談對他們的理解8. 微服務的優缺點分別是什麼？說一下你在項目開發中碰到的坑10.
  • 微服務架構-設計總結
    三、傳統開發模式和微服務的區別四、微服務的具體特徵五、SOA和微服務的區別六、如何具體實踐微服務七、常見的微服務設計模式和應用本質： 用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。———— 百度百科三、傳統開發模式和微服務的區別先來看看傳統的web開發方式，通過對比比較容易理解什麼是Microservice Architecture。和Microservice相對應的，這種方式一般被稱為Monolithic（單體式開發）。
  • 微服務架構體系
    微服務關注的是服務拆分力度，即：一個服務要拆分到多大的維度合適Spring Cloud 和 Dubbo說到微服務，兩大框架的討論肯定跑不了區別Spirng Cloud 更是一個微服務架構生態。服務發現對於服務發現而言，可用性比數據一致性更加重要，AP 勝過 CP，而 Eureka 設計則遵循 AP 原則。
  • Spring Cloud 微服務架構的五臟六腑!
    本文將從 Spring Cloud 出發，分兩小節講述微服務框架的「五臟六腑」：第一小節「服務架構」旨在說明的包括兩點，一服務架構是什麼及其必要性；二是服務架構的基本組成。為什麼第一節寫服務架構而不是微服務架構呢？原因主要是微服務架構本身與服務架構有著千絲萬縷的關係，服務架構是微服務架構的根基。
  • 微服務架構談系列(2):微服務到底是什麼鬼?
    導語：微服務架構如何與更廣泛的軟體架構概念相結合？什麼是服務？服務的規模有多重要？為了回答這些問題，我們需要退後一步，看看軟體架構的含義。軟體的架構是一種抽象的結構，它由軟體的各個組成部分和這些部分之間的依賴關係構成。正如你將在本文中看到的，軟體的架構是多維的，因此有多種方法可以對其進行描述。架構很重要的原因是它決定了應用程式的質量屬性或能力。
  • 微服務架構(Microservice Architecture)
    本質：用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。                                                                                              ———— 百度百科三、傳統開發模式和微服務的區別先來看看傳統的web開發方式，通過對比比較容易理解什麼是Microservice Architecture
  • 組件化、模塊化、集中式、分布式、服務化、面向服務的架構、微服務架構
    模塊化和組件化的區別從上面的定義中可以看出，組件化和模塊化的意思差不多，主要思想都是分而治之。只是一個把拆分之後的每個片段叫做組件、另一個把拆分之後的片段叫做模塊。那麼這兩種拆分在拆分方式上是不是有什麼不同的？關於組件化和模塊化的區別，我在網上看了好多資料，也沒有人能給出準確的回答。其實沒有準確回答的原因也比較明顯，那就是大多數時候我們真的不需要嚴格的區分這兩個名字。
  • 下一代的微服務架構基礎是ServiceMesh?
    今年，ServiceMesh(服務網格) 概念在社區裡頭非常火，有人提出 2018 年是 ServiceMesh 年，還有人提出 ServiceMesh 是下一代的微服務架構基礎。作為架構師，如果你現在還不了解 ServiceMesh 的話，是否感覺有點落伍了？那麼到底什麼是 ServiceMesh？它的誕生是為了解決什麼問題？
  • DDD到底適不適合微服務架構?
    從初期的單體架構，到豎井式架構、RPC架構，再到大放異彩的微服務架構，可以說架構演進，本質上就是基於業務，對現有架構的抽象過程。一名架構師，最怕缺少全局意識和長線思維。如果架構師設計架構的出發點，只是緩解燃眉之急，那麼在未來，這套系統的迭代會越來越困難，很可能陷入推翻、重建，再推翻、再重建的「鬼打牆」。
  • Medium 的微服務架構
    我們已經建立了幾個附屬服務，但我們還沒有制定採用微服架構系統的戰略。隨著系統變得更加複雜和團隊的壯大，我們在 2018年初遷移到了微服務架構。在這篇文章中，我們希望分享我們的經驗，有效地做到這一點，避免微服務症候群。微服務架構是什麼？
  • 微服務架構-從理想到現實
    那麼一個企業或團隊是什麼原因實踐微服務？僅僅是微服務是一種架構發展趨勢，是技術熱點，是網際網路大廠都在用嗎？而實際對於很多企業應用微服務可以看到，更多是團隊裡面總有一些技術狂熱份子，熱衷於新架構，新技術，但是對於這些技術究竟解決了哪些業務場景下的問題並不關心。這直接就導致了大量技術在不恰當的時候被應用。
  • 圓桌論壇:微服務在下一代企業架構中的實戰
    針對微服務出現的本質原因，微服務架構比傳統單體架構設計的優勢，從單體架構逐漸演變為微服務架構的痛點，傳統行業對於微服務的接受程度等話題進行了全方位的探討。圓桌論壇現場以下為現場文字實錄：主持人：感謝黃希彤先生的精彩演講，下面是圓桌論壇時間，我把這個時間段交給我們的同事譚茂。
  • 微服務是什麼?
    網際網路的快速發展，越來越多的公司開始由單體架構轉向微服務架構。因此，微服務的學習需要被我們這些奮鬥者們所掌握，在學習微服務之前，我們有必要盤點下所謂的微服務是什麼，包含什麼，解決了什麼樣的業務場景。與此同時，微服務架構不僅是單純的拆分，拆分之後的各個微服務之間還要進行通信，否則就無法協同完成需求。不同的微服務之間可以通過某種協議進行通信，相互調用、協同完成功能，並且各服務之間只需要制定統一的協議即可，至於每個微服務是用什麼技術框架來實現的，統統不需要關心。
  • 微服務架構設計
    微服務是指開發一個單個小型的但有業務功能的服務，每個服務都有自己的處理和輕量通訊機制，可以部署在單個或多個伺服器上。微服務也指一種種鬆耦合的、有一定的有界上下文的面向服務架構。也就是說，如果每個服務都要同時修改，那麼它們就不是微服務，因為它們緊耦合在一起；如果你需要掌握一個服務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。
  • Medium的微服務架構解析
    何為微服務架構首先，我們來思考微服務之架構是什麼，不是什麼。微服務是拯救那些過載和混亂軟體工程的技術趨勢之一。在Medium團隊，我們認為它是：「在微服務架構中，多個鬆散耦合的服務協同工作。我們不會從微服務架構中獲得所有的好處，它會增加我們的運維成本。如果沒有做到鬆耦合，對一項目服務的更改就會波及到其它服務，因此我們無法快速並安全的發布更新，這便是微服務架構的核心優勢。另外一個更重要的事情是，緊耦合引發的問題將是災難性的，比如數據不一致，甚至導致數據丟失。
  • Serverless:微服務架構的終極模式
    然而，微服務遠沒有達到完美，它在架構、開發、基礎設施方面仍然面臨新的挑戰。微服務面臨的挑戰微服務的粒度影響服務的交付速度及擴展性，微服務的開發引入治理組件，增加了開發的難度，以容器為基礎的微服務基礎設施在彈性等方面仍有不足，而微服務增加帶來的基礎設施成本也是微服務實施的新挑戰。
  • 微服務架構雲端應用
    擁有超過12年網際網路產品開發和管理經驗，專注於網際網路技術架構設計，對產品設計、敏捷開發、安全、OKRs、大數據等領域有深入研究。現推崇反應式編程（http://www.reactivemanifesto.org/），並在多個產品中成功應用。劉總在這次分享中主要為大家介紹了什麼是徽服務，實現微服務有哪些架構模式以及微服務在實際中的應用情況。