面向服務架構（SOA）已經存在有些年頭了，這是一種用於設計軟件的偉大原則。在SOA中，所有組件都是獨立自主的，並能為其他組件提供服務。要替換掉系統中的某些部分而不對整個系統造成較大的影響本是個難題，然而只要維護好系統各模塊之間的低耦合，該難題便能迎刃而解，這也是我們之前談及微服務時所認可的。大體上，SOA與微服務架構是非常相像的。那么它們之間的區別到底是什么呢？微服務是細粒度的SOA組件。換句話說，某單個SOA組件可以被拆成多個微服務，而這些微服務通過分工協作，可以提供與原SOA組件相同級別的功能，如下圖所。
微服務是細粒度的SOA組件，它們是關注點更窄的輕量級服務。微服務與SOA之間的另一個不同之處是服務互聯和編寫服務時所使用的技術。J2EE是一個遵守企業級標准的用於編寫SOA架構的技術棧。Java命名與目錄接口（JNDI）、企業級JavaBean（EJB）以及企業服務總線（ESB）都是SOA應用賴以構建和維護的生態土壤。即便ESB是標准，在2005年之后畢業的工程師卻鮮有聽說過ESB的，至於用過ESB的那就更少了。而當代的，例如Rubyon Rails這樣的框架甚至不會去考慮如此復雜的軟件部件。
而另一方面，微服務推崇執行的標准（例如HTTP）卻是人們廣泛了解並共同使用的。我們可以通過選擇合適的語言或工具來構建某個組件（微服務），進而獲得本章“技術多樣性”小節所提到的關鍵好處。除了技術棧與服務規模之外，在SOA與微服務之間還有一個更大的區別：領域模型。在本章前面的內容中，我們曾討論過去中心化。有管理的去中心化，也有數據的去中心化。在一個基於微服務的軟件中，每個微服務應該在本地存儲自身管理的數據，並將領域模型分別隔離到單個服務中。而在面向SOA的軟件中，數據往往存儲在單個大型的數據庫中，服務之間會共享領域模型。
一、面向服務的架構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看作微服務的超集”。
那么，差異在哪里呢？可以說，兩種架構比起不同的架構有更多的相似之處，然而，它們是兩種不同類型的架構。下面會詳細分析這一點。
三、SOA vs. MicroServices
SOA |
微服務架構 |
|---|---|
| 應用程序服務的可重用性的最大化 | 專注於解耦 |
| 系統性的改變需要修改整體 | 系統性的改變是創建一個新的服務 |
| DevOps和持續交付正在變得流行，但還不是主流 | 強烈關注DevOps和持續交付 |
| 專注於業務功能重用 | 更重視“上下文邊界”的概念 |
| 通信使用企業服務總線ESB | 對於通信而言，使用較少精細和簡單的消息系統 |
| 支持多種消息協議 | 使用輕量級協議，例如HTTP，REST或Thrift API |
| 對部署到它的所有服務使用通用平台 | 應用程序服務器不是真的被使用，通常使用雲平台 |
| 容器（如Docker）的使用不太受歡迎 | 容器在微服務方面效果很好 |
| SOA服務共享數據存儲 | 每個微服務可以有一個獨立的數據存儲 |
| 共同的治理和標准 | 輕松的治理，更加關注團隊協作和選擇自由 |
下面進一步解釋上表所述的不同之處：
-
開發方面 - 在這兩種體系結構中，可以使用不同的編程語言和工具開發服務，從而將技術多樣性帶入開發團隊。開發可以在多個團隊中組織，但是在SOA中，每個團隊都需要了解常見的通信機制。另一方面，使用微服務，服務可以獨立於其他服務運行和部署。因此，頻繁部署新版本的微服務或獨立擴展服務會更容易。您可以在這里進一步閱讀有關微服務的這些好處。
-
“上下文邊界” - SOA鼓勵組件的共享，而微服務嘗試通過“上下文邊界”來最小化共享。上下文邊界是指以最小的依賴關系將組件及其數據耦合為單個單元。由於SOA依靠多個服務來完成業務請求，構建在SOA上的系統可能比微服務要慢。
-
通信 - 在SOA中，ESB可能成為影響整個系統的單一故障點。由於每個服務都通過ESB進行通信，如果其中一個服務變慢，可能會阻塞ESB並請求該服務。另一方面，微服務在容錯方面要好得多。例如，如果一個微服務存在內存錯誤，那么只有該微服務會受到影響。所有其他微服務將繼續定期處理請求。
-
互操作性 - SOA通過消息中間件組件促進了多種異構協議的使用。微服務試圖通過減少集成選擇的數量來簡化架構模式。因此，如果您想要在異構環境中使用不同協議來集成多個系統，則需要考慮SOA。如果您的所有服務都可以通過相同的遠程訪問協議訪問，那么微服務對您來說是一個更好的選擇。
-
大小Size - 最后一點但並非最不重要的一點，SOA和微服務的主要區別在於規模和范圍。微服務架構中的前綴“微”是指內部組件的粒度，意味着它們必須比SOA架構的服務往往要小得多。微服務中的服務組件通常有一個單一的目的，他們做得很好。另一方面，在SOA服務中通常包含更多的業務功能，並且通常將它們實現為完整的子系統。
四、結論
我們不能簡單地說一種架構比另一種架構更好。這主要取決於您正在構建的應用程序的目的。SOA更適合需要與許多其他應用程序集成的大型復雜企業應用程序環境。這就是說，小型應用程序不適合SOA架構，因為它們不需要消息中間件組件。而微服務架構，在另一方面，是更適合於較小和良好的分割，基於Web的系統。另外，如果您正在開發移動或Web應用程序，那么微服務作為開發人員可以為您提供更大的控制權。最后，我們可以得出結論，因為它們服務於不同的目的，微服務和SOA確實是不同類型的體系結構。