IBM觀點：SOA與微服務區別？

為什麼這種差異很重要
當你忽視這種差異時，每種方法的許多核心原則都會變得不相容。如果您接受範圍的差異，您可能很快意識到這兩者可能相互補充而不是競爭。

以下是這種區別發揮作用的幾種情況：

1. 重用, 在SOA中，整合上的重用是企業主要目標，在企業級別，努力實現某種程度的重用是至關重要的。在微服務架構中，強調松耦合、敏捷性和彈性，微服務元件通常更喜歡透過複製重用程式碼並接受資料複製以幫助改善解耦

banq注：軟體複雜性是因為一段程式碼做兩件事，因此一段程式碼只實現一個單一職責，微服務透過執行時呼叫某個單一職責的微服務來實現重用。但是重用有時如果不仔細設計，就可能導致一段程式碼做多個事情，因為程式設計師覺得這幾個事情差不多，就是實現單一職責功能，其實忽視了職責功能所處的上下文區別，雖然主要功能差不多，但是細微上有差別，最後實現成可執行時的程式碼時實際上變成了做幾件事，比如透過設定很多if語句來判斷不同上下文和入引數據。這就很難修改擴充，變成單體架構。

如果開始編碼主要目的不是為了單一職責，而是為了重用，很容易在程式碼級別耦合呼叫那些所謂重用程式碼，最後造成緊耦合，變成單體架構，整個程式碼都如同義大利麵條一樣混雜在一起，變成鐵板一塊。

SOA主要目的整合重用，比如A系統實現了A功能，B系統實現了B功能，那麼現在C=A+B，那麼當然會將A和B系統整合進來，之所以稱為整合，是因為你不能再修改A系統程式碼了，也許A系統已經是遺留系統，或者別的公司程式碼，並不配合你修改。所以，這種整合重用是不破壞原來封裝情況下的重用，其實這種難度比較大，其實整合主要目的是流程組合：今天希望先完成A系統的A功能，明天希望完成B系統的B功能；過幾天兩種執行順序再倒過來，或糅合進入其他功能重組流程。

所以，我個人認為：微服務已經透過單一職責方式實現了松耦合的職責功能重用，而SOA主要目的不是職責功能重用，而是職責功能執行流程的重組，而這也是建立在微服務單一職責基礎上。
見我另外一篇：單一職責和重用可能是對立的

2. 同步通訊，SOA中的可重用服務可在整個企業中使用，主要使用RESTful API等同步協議，但是，在微服務應用程式中，同步呼叫會引入實時依賴性，從而導致彈性喪失。它還可能導致延遲，從而影響效能。在微服務應用程式中，優選是基於非同步通訊的互動模式，例如事件溯源，其中使用釋出訂閱模型使微服務元件能夠保持最新發生在另一元件中的資料發生的變化。

banq注：雖然微服務採取非同步更加完美，但是程式設計師對於非同步程式設計有一定門檻，因此採取RESTful API同步呼叫也是微服務的主要特點，同步和非同步的通訊方式不構成SOA和微服務的主要區別，主要區別是通訊管道的設計特點上，如果所有服務依賴一個複雜的智慧的總管道，比如ESB匯流排之類，這是SOA；而微服務強調智慧端點，啞管道，所謂啞管道就是笨管道，管道要求簡單，不要採取複雜匯流排，否則ESB成為單點風險，成為系統耦合中心。

3. 資料重複，在SOA中提供服務的明確目標是讓所有應用程式直接在其主要資料來源上同步獲取和更改資料，從而減少維護複雜資料同步模式的需要。在微服務應用程式中，每個微服務理想地擁有自己的資料來源，不同微服務不能像SOA那樣跨資料庫訪問，這樣才能確保微服務的獨立性，但這樣做可能意味在自己資料庫中存在一些其他資料庫的重複資料。當然，這種重複增加了複雜性，因此必須與敏捷性和效能的提升相平衡，但這被認為是微服務設計的現實。

banq注：如果一個微服務需要使用其他資料庫，需要透過那個資料庫所屬的微服務呼叫，微服務是無狀態的，也不贊成在本地資料庫快取一些其他微服務的資料，因此，不會存在資料重複和冗餘，冗餘與重複來自於單一職責沒有實現到位。

最後一點，資料重複其實是因為只考慮重用導致的後果，結果變成程式碼實際做了幾件事，資料實際複製了好幾份，這種複雜性是單體架構正是當前SOA系統主要問題，這些都是因為從系統開始之處只注重複用的設計思維導致。

原文：

SOA versus microservices: What’s the difference? -

見我另外一篇：單一職責和重用可能是對立的