一、面向服務的架構SOA

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

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

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

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

二、微服務架構

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

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

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

微服務中的這個“微”字給很多人帶來了很多誤解。從字面意思上，“微”會讓人聯想到一個微服務就應該是功能足夠單一，甚至出現一個服務的實現可能只需要幾十或者上百行代碼的說法，這應該是最誤導人的觀點。從技術角度出發，確實可以通過簡短的代碼實現功能單一的服務，但從一個整體架構考慮，如果是以這樣的方式實現各個微服務，則在整個服務體系范疇當中包含太多功能邊界，那么對于服務運營的分工和邊界就很難界定，給服務接下來的持續運營和維護帶來困擾；另外拆分過于細化的服務，勢必將帶來大量無謂的分布式事務調用，給業務帶來額外的工作量和風險。

正因為有了“微服務”中所謂“微”服務的說法，那如何對這些微服務進行快速的部署、發布，更高效的利用服務計算資源。（Docker本身提供的核心能力還是在技術資源層面），還有一系列問題，遠不是單單的Docker平臺能解決的問題：

微服務化的應用架構如何進行有效的服務管控。

在分布式服務體系下，服務鏈路跟蹤、鏈路分析、實時業務指標的監控等問題，也都是事先微服務架構時一定會面臨的問題，擴大到更大范圍就是整體服務平臺的管控能力。

分布式事務難題

服務化后的應用如何解決隨之而來的分布式事務問題，一定需要針對業務的需求在事務一致性和性能間做好平衡，一套穩定、成熟的分布式事務解決方案也是構建微服務架構首先要思考好的技術方向問題。

自動化運維和平臺穩定性。

微服務架構相比之前獨立應用的部署方式，從服務器的數量以及服務交互復雜程度都上升到一個新的等級，原有運維平臺和工具是否能高效支撐微服務架構的運維也需要好好斟酌。

　　微服務帶來了服務間錯綜復雜的調用關系，如何能在大促、秒殺、機器故障時，這些服務都能穩定提供服務？這對于整個平臺的高可用性和穩定性提出了非常高的要求：

1、微服務的服務設計：

　　微服務中服務邊界的劃分一定是從業務的維度，以什么樣的服務顆粒度定義服務？什么樣的數據模型支撐服務能力的線性擴展？如何保持設計出的服務具有很好的業務前瞻性？在高效滿足現有業務需求的前提下，還能保持整個服務能力的通用性，為接下來其他業務的服務接入提供業務的擴展能力？這些問題都是微服務架構在落地過程中，實施團隊都將面臨的問題。

2、原有組織架構是否滿足微服務架構持續發展的需要：

　　服務強調持續的演變，需要組建對應的組織或者對現有的組織架構進行調整，圍繞以服務為中心的持續運營，這對應很多企業原有的信息中心架構是一個不大的沖擊和改變。

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

三、SOA特點、微服務特性特點

SOA的主要特性：

IBM對SOA的定義：SOA是一種構造分布式系統的方法，它將業務應用功能以服務的形式提供給最終用戶應用或其他服務。

面向服務的分布式計算
服務間松散耦合
支持服務的組裝
服務的注冊和自動發現
以服務契約方式定義服務交互方式

“中心化”的SOA服務架構，即傳統軟件廠商提出的以ESB（企業服務總線）實現SOA的方案；還有一種是“去中心化”的服務架構。

微服務的主要特性：

定義：圍繞業務領域組件來創建應用，這些應用可獨立地進行開發、管理和迭代。在分散的組件中使用云架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。

以下是Martin Fowler對于微服務架構的典型特征的描述：

分布式服務組成的系統。
按照業務而不是技術來劃分組織。
做有生命的產品而不是項目
智能化服務端點與傻瓜式服務編排。
自動化運維。
系統容錯。
基礎設施自動化
服務快速演化。
去中心化的治理技術。
去中心化的管理數據。

從本質上來說，“微服務”是SOA的一種演變后的形態，與SOA的方法和原理沒有本質上的區別。將傳統SOA與微服務典型特征做一個對比解讀，會發現鮮明差異：（67頁）

四、SOA vs. MicroServices

SOA簡單理解為應用的垂直拆分，微服務理解為應用的垂直拆分+水平拆分，是SOA的演進。提高了靈活性，但是需要額外考慮分布式鎖、分布式事務等問題。

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

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

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

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

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

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

五、結論

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

總結

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

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