一、面向服務的架構SOA

       面向服務的架構是一種軟體體系結構，應用程式的不同元件通過網路上的通訊協議向其他元件提供服務。通訊可以是簡單的資料傳遞，也可以是兩個或多個服務彼此協調連線。這些獨特的服務執行一些小功能，例如驗證付款、建立使用者帳戶或提供社交登入等。

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

       SOA架構中有兩個主要角色：服務提供者（Provider）和服務使用者（Consumer）

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

二、微服務架構

       微服務架構在某種程度上是面向服務的架構SOA繼續發展的下一步。基本上，這種架構型別是開發軟體，網路或移動應用程式作為獨立服務套件（又稱微服務）

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

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

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

三、SOA與MicroServices的區別

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

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

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

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

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

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

四、結論

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