單體架構
一個歸檔包（例如war格式）包含所有功能的應用程式，通常稱為單體應用。
如圖：
儘管該應用已經使用了MVC分層與模組化，但是由於所有部件最終都打包在一個war包中，該war包包含了整個系統所有的業務功能，這樣的應用系統稱為單體應用。
單體架構的缺陷：
1.複雜度高：隨著程式碼的增多，會導致業務模組邊界模糊、依賴關係不清、程式碼耦合嚴重、程式碼質量參差不齊、混亂的堆疊在一起，每改一個小bug都有可能會影響到其他地方。
2.釋出頻繁：每個功能的迭代或bug的修復都需要重新部署整個應用，風險高，不利於線上系統的穩定性。
3.可靠性差：某個地方出現bug，例如死迴圈、記憶體用完等等，都可能會導致整個系統癱瘓掉。
服務化架構
SOA 面向服務的架構（Service-Oriented Architecture）
SOA是在單體應用中將模組元件從單一程式進一步拆分，形成獨立的對外提供服務的網路化元件，每個網路化元件通過某種網路協議對外提供服務（不侷限於某種網路協議，可以是底層的TCP/IP，可以是應用層的HTTP，也可以是訊息佇列協議），最終將多個業務服務通過元件化模組方式打包在一個War包裡，然後統一部署在一個應用伺服器上。
所以可以這麼理解，SOA是單體架構的內部升級。
SOA有兩個主流的實現方式：
1.Web Service，它的每個服務都要依賴中心化目錄來發現現存的服務，服務提供者通過UDDI協議將服務註冊到目錄，服務消費者通過UDDI協議從目錄中查詢服務並獲得服務的WSDL描述檔案。
2.ESB，它沒有中心化的服務節點，每個服務提供者都是通過服務匯流排的模式插入系統，匯流排根據流程編排負責將服務的輸出進行轉換併傳送給流程要求的下一個服務進行處理。
要做SOA架構，就要做系統拆分，以服務化的思想為指導，實現面向服務的架構，做服務化拆分。
首先要解決的是如何去拆解我們的系統，一般需要從整體上梳理公司的業務，包括過去、現在以及未來幾年內的業務進展，將業務模組化，分解出各個業務模組之間的依賴以及業務模組之間的邊界，按照業務邊界以及業務之間的依賴順序進行系統拆分，這是系統拆分的常見做法。
從單體應用到SOA架構的轉變如圖：
SOA架構的缺陷：
1.升級風險高：因為是所有的功能都部署在一個釋出包裡，如果要升級，就要更換整個釋出包，那麼在升級的過程中，會導致整個應用停掉，致使所有的功能不可用。
2.專案交付週期變長：由於單體架構必須要等到最後一個功能測試沒有問題了，才能整體上線，這就是水桶理論，只要有一個功能存在短板，整個系統的交付就會被拖累。
3.可伸縮性差：由於應用的所有功能程式碼都執行在同一個伺服器上，如果你想擴充套件某一個單一功能，但你不得不將整個應用水平進行了擴容，這就導致了其他不需要擴容的功能浪費。
4.監控困難：不同的功能都雜合在一個程式中，這讓監控這個程式中的功能變得困難。
微服務架構
將單體應用拆分成多個服務，每個服務獨立部署，這樣的架構就叫做微服務架構。
微服務架構如圖：
微服務架構的優點：
1.易於開發和維護：微服務把一個單一的業務功能放在一個獨立的服務中，所以它業務清晰，程式碼量較少，開發和維護單個微服務相對簡單。
2.啟動較快：單個微服務程式碼量較少，所以啟動會比較快。
3.區域性修改容易部署：對某個服務進行修改，只需要重新部署這個服務即可。
4.每個服務擁有單獨的程式，單個服務出現故障不會影響到其他服務的執行。
5.技術棧不受限：在微服務架構中，可以結合實際合理選擇技術棧，例如這個服務可以使用MySQL，那個服務可以使用MongoDB。
微服務架構與SOA服務化的對比
1.目的不同
SOA強調不同的異構服務之間的寫作和契約，並強調有效整合、業務流程編排、歷史應用整合等，典型代表為Web Service和ESB。
微服務使用一系列微小的服務來實現整體的業務流程，目的是有效的拆分應用，實現敏捷開發和部署，縮小變更和迭代影響的範圍，並達到單一微服務更容易水平擴充套件的目的。
2.部署方式不同
SOA服務化通常將多個業務通過元件化模組方式大伯啊在一個war包裡，然後統一部署在一個應用伺服器上。
微服務將完整的應用拆分成多個微小的服務，每個微服務執行在單一的程式內，微服務中的部署互相獨立，互不影響。
3.服務粒度不同
SOA對粒度沒有要求，在實踐中服務通常是粗粒度的，強調介面契約的規範化，內部實現可以更粗粒度。
微服務倡導將服務拆分成更細的粒度，拆分到職責單一，最終通過多個微小服務組合來實現整個架構。