絕大部分的應用框架都會有一個演進的過程，這個演進的過程通常是被業務逼出來的，所以要想知道為什麼要使用SOA框架，就需要了解傳統的單體架構有哪些缺點。

在專案的初期，專案通常都是採用單體應用進行開發部署，軟體架構分為Web層、業務邏輯層和資料持久化層，不同層次的模組化元件被聚合後執行在應用伺服器上；

再往後發展，開源軟體SSH嶄露頭角，MVC的設計模式，強制性的把應用程式的輸入、處理和輸出分開，讓各個模組各施其職，互不干涉；

這個時代的專案大多數都是企業級應用，使用者量不是很大，專案都會被打成一個包進行部署釋出。

雖然單體架構有容易部署、測試等優點，但是隨著需求的增多，單體應用變得越來越臃腫、越來越難以維護；使用者越來越多，專案只能透過增加資源的方式來提高專案的效能；隨著時間的推移，單體專案暴露的缺點也越來越多：

程式碼越來越多，增加了程式碼的複雜性；作為開發人員一定深有感觸，每當修改一個老方法的時候，一定會格外的小心翼翼，生怕影響了其他的功能；

隨著開發人員的流動，老員工離開專案組，複雜且龐大的專案程式碼又讓新成員難以閱讀和理解，技術債務越積越多；

程式碼都在一個程式碼包中，就算是修改一個小小的功能，都要把整個專案打包上線；

所有的模組都執行在同一個JVM中，非關鍵性業務可能佔用大量的資源，導致關鍵性業務發生問題；

不能單獨對某一個模組進行擴充套件；

單體應用需要統一技術棧，團隊中的開發人員，都需要掌握相同的開發語言和框架。

因為單體應用架構的種種缺點，已經不能再滿足業務需求的時候，於是就出現了SOA、出現了微服務。

先說說服務化架構SOA，它的主要思想是把應用程式的模組化元件，透過介面聯絡起來（介面可以獨立於語言、框架、硬體、作業系統）；在SOA架構中，有兩個主流實現方式：

Web Service：使用WSDL定義介面，SOAP協議通訊，傳輸XML資料；

再說說現在很流行的微服務：微服務的產生，也是由於SOA架構的一些缺點，這裡再次印證了本文開頭說的那句話，【應用架構的演進的過程通常是被業務逼出來的】。

Web Service：SOAP、XML較重；服務管理不完善；

ESB：ESB本身就比較中，而且它本身算是一個單點，在軟體架構中，單點意味著風險；

在微服務的架構中，各個微服務可以獨立開發，獨立部署；微服務之間通常使用Restful風格的API通訊，傳輸格式也通常選擇JSON；微服務是SOA架構的延續，它們和單體應用相比，大大提高了系統的負載能力，解決了應用高併發的需求；服務和服務之間的耦合度也被降低，並且專案團隊可以被拆分成多個小團隊，每個微服務都可以進行敏捷開發部署；每個團隊的技術棧也可以不相同，只要遵守介面協議即可。

當然SOA、微服務的出現，在解決一些問題的時候，也帶來了另外一部分的問題，比如增加了網路開銷、服務依賴性、增加了測試運維難度、資料一致性問題等等。

在10多年前接觸SOA概念的時候，以IBM、Oracle為主的頭部玩家加上國內一些中介軟體廠商都在跟進，火爆程度不亞於現在的區塊鏈、中臺、AIOT，各公司都用自己的產品、方案組合來演繹SOA，比較典型的產品就是ESB、BPM、Portal，有時候也會帶著DP開發平臺，當時很多定製軟體開發商、甚至ERP廠商都得跟SOA扯上關係，不然就不知道怎麼講片子、不好意思跟人打招呼。

SOA面向服務架構是一種設計理念、架構規範，用來構建敏捷柔韌的IT架構、隨需應變支撐業務。

從這個角度來說跟中臺理念類似，不過中臺的範疇更廣、跟業務關聯度更高。SOA其實分兩種流派，一種SOI面向服務整合、SOD面向服務開發，這就是為什麼中介軟體廠商跟應用軟體開發商都能跟SOA扯上關係的原因，不過一個是蓋房子的一個是修道路橋樑的，談不上誰比誰高階，但解決問題卻是一致的：讓應用軟體更容易互聯互通、敏捷整合，只是應用軟體廠商強調的整合性更多是大系統的模組間的整合，而中介軟體廠商強調的是異構應用系統之間的整合。