一、面向服務的架構SOA

SOA代表了面向服務的架構。 SOA是一種使用松耦合的黑盒子服務構建業務應用的體系架構，這些服務可以通過編排連接在一起以實現特定的功能。

面向服務的架構（Service-Oriented Architecture）是一種軟件體系結構，應用程序的不同組件通過網絡上的通信協議向其他組件提供服務。通信可以是簡單的數據傳遞，也可以是兩個或多個服務彼此協調連接。這些獨特的服務執行一些小功能，例如驗證付款、創建用戶帳戶或提供社交登錄等。

面向服務的架構不太關于如何對應用程序進行模塊化構建，更多的是關于如何通過分布式、單獨維護和部署的軟件組件的集成來組成應用程序。這些通過技術和標準來實現，通過技術和標準使得組件能夠更容易地通過網絡（尤其是IP網絡）進行通信和協作。

SOA架構中有兩個主要角色：服務提供者（Provider）和服務使用者（Consumer）。而軟件代理則可以扮演這兩個角色。該Consumer層是用戶（人、應用程序或第三方的其它組件）與SOA交互的點，和Provider層則由SOA架構內的所有服務所構成。

SOA首先在90年代中期得名，當時一家名為Gartner Group的公司認識到了這個軟件架構的新趨勢，并在全球推廣。通過這樣做，他們設法大大加快了這種架構模式的采用和進一步發展。然而，使用分布式服務作為軟件體系結構的最早記錄可追溯到二十世紀80年代初。

1.1 什么是合同，地址和綁定？

這是三個SOA的標準術語。每個服務都必須公開一個或多個端點，以便讓該服務提供給客戶端調用。

• 合同是兩方或多方之間的協議。它定義了一種客戶端如何與服務通信的協議。從技術上講，它有描述參數和返回值的方法。
• 地址表明在哪兒能找到這種服務。地址是一個URL，它指向服務的位置。
• 綁定是決定這個端點如何可以訪問。它決定了如何完成通信。例如，你暴露你的服務，可以使用SOAP over HTTP或通過TCP的BINARY進行訪問。因此，對于這些通信介質將被創建兩個綁定。

二、微服務架構

微服務架構在某種程度上是面向服務的架構SOA繼續發展的下一步。基本上，這種架構類型是開發軟件，網絡或移動應用程序作為獨立服務套件（又稱微服務）的一種特殊方式。這些服務的創建僅限于一個特定的業務功能，如用戶管理、用戶角色、電子商務車、搜索引擎、社交媒體登錄等。此外，它們是完全獨立的，也就是說它們可以寫入不同的編程語言并使用不同的數據庫。集中式服務管理幾乎不存在，微服務使用輕量級HTTP、REST或Thrift API進行通信。

這個詞本身起源于2011年5月在威尼斯附近舉行的軟件架構師研討會。他們第一次使用“微服務”這個術語來描述參與者看到的一個共同的架構風格，其中許多參會者都在探索相似的內容。2012年5月，同一個團隊決定將“微服務”作為最合適的名稱。然而實際上，微軟、亞馬遜、Netflix和Facebook等主要的科技公司已經在微服務架構方面工作了十多年。

乍一看，微服務架構似乎談論的是與SOA相同的事情。不過，如果引用微軟服務領域的先驅Martin Flower的話，他曾經說過，“我們應該把SOA看作微服務的超集”。

三、架構演進

技術為業務而生，架構也為業務而出現，當然SOA和微服務也是因為業務的發展而出現。出現SOA和微服務框架與業務的發展、平臺的壯大密不可分，下面借用dubbo的網站架構發展圖和說明：

• 單一應用架構
  當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
  此時，用于簡化增刪改查工作量的 數據訪問框架(ORM) 是關鍵。

• 垂直應用架構
  當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。
  此時，用于加速前端頁面開發的 Web框架(MVC) 是關鍵。

• 分布式服務架構
  當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
  此時，用于提高業務復用及整合的 分布式服務框架(RPC) 是關鍵。

• 流動計算架構
  當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基于訪問壓力實時管理集群容量，提高集群利用率。
  此時，用于提高機器利用率的 資源調度和治理中心(SOA) 是關鍵。

平臺隨著業務的發展從 All in One 環境就可以滿足業務需求（以Java來說，可能只是一兩個war包就解決了）；發展到需要拆分多個應用，并且采用MVC的方式分離前后端，加快開發效率；在發展到服務越來越多，不得不將一些核心或共用的服務拆分出來，其實發展到此階段，如果服務拆分的足夠精細，并且獨立運行，我覺得就可以將之理解為一個微服務了。

那么，SOA與微服務差異在哪里呢？可以說，兩種架構比起不同的架構有更多的相似之處，然而，它們是兩種不同類型的架構。下面會詳細分析這一點。

三、區別

下面進一步解釋上表所述的不同之處：

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

• “上下文邊界” - SOA鼓勵組件的共享，而微服務嘗試通過“上下文邊界”來最小化共享。上下文邊界是指以最小的依賴關系將組件及其數據耦合為單個單元。由于SOA依靠多個服務來完成業務請求，構建在SOA上的系統可能比微服務要慢。

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

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

• 大小Size - 最后一點但并非最不重要的一點，SOA和微服務的主要區別在于規模和范圍。微服務架構中的前綴“微”是指內部組件的粒度，意味著它們必須比SOA架構的服務往往要小得多。微服務中的服務組件通常有一個單一的目的，他們做得很好。另一方面，在SOA服務中通??常包含更多的業務功能，并且通常將它們實現為完整的子系統。

四、總結

我們不能簡單地說一種架構比另一種架構更好。這主要取決于您正在構建的應用程序的目的。SOA更適合需要與許多其他應用程序集成的大型復雜企業應用程序環境。這就是說，小型應用程序不適合SOA架構，因為它們不需要消息中間件組件。而微服務架構，在另一方面，是更適合于較小和良好的分割，基于Web的系統。另外，如果您正在開發移動或Web應用程序，那么微服務作為開發人員可以為您提供更大的控制權。最后，我們可以得出結論，因為它們服務于不同的目的，微服務和SOA確實是不同類型的體系結構。

總結

以上是生活随笔為你收集整理的SOA和微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。