1、服務粒度
整體上來說，SOA（Service Oriented Architecture 面向服務的架構） 的服務粒度要粗一些，而微服務的服務粒度要細一些。例如，對一個大型企業來說，“員工管理系統”就是一個 SOA 架構中的服務；而如果採用微服務架構，則“員工管理系統”會被拆分爲更多的服務，比如“員工信息管理”“員工考勤管理”“員工假期管理”和“員工福利管理”等更多服務。
2、服務通信
SOA 採用了 ESB 作爲服務間通信的關鍵組件，負責服務定義、服務路由、消息轉換、消息傳遞，總體上是重量級的實現。微服務推薦使用統一的協議和格式，例如，RESTful 協議、RPC 協議，無須 ESB 這樣的重量級實現。
3、服務交付
SOA 對服務的交付並沒有特殊要求，因爲 SOA 更多考慮的是兼容已有的系統；微服務的架構理念要求“快速交付”，相應地要求採取自動化測試、持續集成、自動化部署等敏捷開發相關的最佳實踐。如果沒有這些基礎能力支撐，微服務規模一旦變大（例如，超過 20 個微服務），整體就難以達到快速交付的要求，這也是很多企業在實行微服務時踩過的一個明顯的坑，就是系統拆分爲微服務後，部署的成本呈指數上升。
4、應用場景
SOA 更加適合於龐大、複雜、異構的企業級系統，這也是 SOA 誕生的背景。這類系統的典型特徵就是很多系統已經發展多年，採用不同的企業級技術，有的是內部開發的，有的是外部購買的，無法完全推倒重來或者進行大規模的優化和重構。因爲成本和影響太大，只能採用兼容的方式進行處理，而承擔兼容任務的就是 ESB。
微服務更加適合於快速、輕量級、基於 Web 的互聯網系統，這類系統業務變化快，需要快速嘗試、快速交付；同時基本都是基於 Web，雖然開發技術可能差異很大（例如，Java、C++、.NET 等），但對外接口基本都是提供 HTTP RESTful 風格的接口，無須考慮在接口層進行類似 SOA 的 ESB 那樣的處理。
綜合上述分析，我將 SOA 和微服務對比如下：
因此，我們可以看到，SOA 和微服務本質上是兩種不同的架構設計理念，只是在“服務”這個點上有交集而已。
SOA 和微服務是兩種不同理念的架構模式，並不存在孰優孰劣，只是應用場景不同而已。我們介紹 SOA 時候提到其產生歷史背景是因爲企業的 IT 服務系統龐大而又複雜，改造成本很高，但業務上又要求其互通，因此纔會提出 SOA 這種解決方案。如果我們將微服務的架構模式生搬硬套到企業級 IT 服務系統中，這些 IT 服務系統的改造成本可能遠遠超出實施 SOA 的成本。