SOA為面向服務架構，它將應用程序的不同功能單元（稱為服務）進行拆分，並通過這些服務之間定義良好的接口和契約聯系起來。一個服務通常以獨立的形式存在與操作系統進程中。各個服務之間通過網絡調用。微服務是在 SOA 上做的升華，強調的一個重點是“業務需要徹底的組件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。微服務架構 = 80%的SOA服務架構思想 + 100%的組件化架構思想 + 80%的領域建模思想。
SOA架構的特點為：系統集成：站在系統的角度，解決企業系統間的通信問題，把原先散亂、無規划的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步往往需要引入 一些產品，比如 ESB、以及技術規范、服務管理規范，解決的核心問題是【有序】；系統的服務化：站在功能的角度，把業務邏輯抽象成可復用、可組裝的服務，通過服務的編排實現業務的快速再生，目的：把原先固有的業務功能轉變為通用的業務服務，實現業務邏輯的快速復用，解決的核心問題是【復用】；業務的服務化：站在企業的角度，把企業職能抽象成 可復用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能復用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務，解決的核心問題是【高效】。
微服務架構特點為1.通過服務實現組件化（不再協調其他服務部署）2.按業務能力來划分服務和開發團隊3.去中心化，進一步降低了微服務之間的耦合度，不同服務可以采用不同的數據庫技術（SQL、NoSQL等）。在復雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。4.基礎設施自動化（devops、自動化部署）的Java EE部署架構，通過展現層打包WARs，業務層划分到JARs最后部署為EAR一個大包，而微服務則打開了這個黑盒子，把應用拆分成為一個一個的單個服務，應用Docker技術，不依賴任何服務器和數據模型，是一個全棧應用，可以通過自動化方式獨立部署，每個服務運行在自己的進程中，通過輕量的通訊機制聯系，經常是基於HTTP資源API，這些服務基於業務能力構建，能實現集中化管理。
在下面SOA組件圖中，服務和服務消費者(客戶端)之間存在多個約束，當一個服務顯式暴露后，客戶端能夠通過綁定定位到該服務，相當於兩者簽訂了合同，規定了合同內容和如何實施，具體合同的描述是通過消息方式進行：
面向服務的架構SOA更加貼近業務客戶，也更適合業務伙伴之間流程整合，各個行業已經誕生自己行業特點的SOA，例如電信聯盟的NGOSS，已經成為電信行業業務支撐系統BOSS的標准。SOA不但是技術用語，也是業務銷售用語，通過服務這個中間概念，可以實現業務和技術之間的無縫轉換，如今SOA已經和REST RDD以及雲計算等新技術方法結合。
服務提供者和服務消費者，這兩者之間有一個合同約定，這非常類似我們現實生活中簽訂的服務合同，A單位和B單位分別是服務的提供者和消費者，兩者簽訂了一個服務合同，規定A為B提供某項服務。服務就是提供一些公共需求的設施，通過一個工作過程能提供幫助，使用，讓使用者受益。服務兩個重要特點：自治和管制，自治代表服務不能被外部勢力牽制，比如如果一個服務內部處理中需要調用外部資源或等待外部流程結束，這種等待不能影響服務本身的調用，如果一個服務分為顯式對外和隱式內部兩個部分，那么自治是針對隱式內部，意味着我們不能在具體一個服務中直接使用同步代碼實現復雜功能。
實現服務真正自治，實際就是解決類之間依賴耦合的問題，消息是一種方式，但是基於消息又有兩種通訊方式，基於請求響應和基於事件的EDA。
從服務自治可以看出，為什么要提出服務必須自治，因為服務是受管制的，在實際業務活動中，不同服務是被不同部分管理，比如定價服務歸屬財務部門系統，庫存歸屬倉庫系統，涉及系統之間調用協調不能自己使用同步RPC，而是需要消息。
在實際應用中，很多單位使用SOA主要看中其能夠無縫整合新舊系統,稱為EAI企業應用整合，下圖是蘇寧的一種SOA圖，使用ESB企業服務總線這樣的消息系統整合了新舊各種系統。
SOA使用者要根據自己業務進行模塊划分，進行領域建模設計，根據DDD領域驅動設計將業務分解為一個上下文模塊，然后再用服務作為對外接口，內部封裝的是DDD聚合根，而傳統SOA作法是內部封裝的是數據表的DTO，從而導致SOA服務內部腐爛堵塞，違背SOA自治和可用性等原則約束。
參考鏈接：