一、單體應用架構
單體架構，一個war文件包含所有功能的應用程序包。包含複雜的業務邏輯/自服務接口/定時任務/集團接口等等，都在一個war文件裏面。每次發佈，都是版本管理員拿到一個大war包，上傳到Tomcat，再往幾十臺服務器上推送。好處是都在一個上，部署測試比較容易，版本管控比較簡單。但是隨着時間的推移，越來越多的需求被加到war包中，慢慢地，單體應用變得越來越臃腫，上線後運行五六年，war包就有幾百兆，可維護性和靈活性低
特點：
1、所有的功能集成在一個項目工程中。
2、所有的功能打一個war包部署到服務器。
3、應用與數據庫分開部署。
4、通過部署應用集羣和數據庫集羣來提高系統的性能。
優點：
項目架構簡單，前期開發成本低，週期短，小型項目的首選。
缺點：
(1):複雜性高
一個百萬行級別的單體應用爲例，整個項目包含的模塊非常多，模塊的邊界模糊，依賴關係不清晰，代碼質量參差不齊，混亂地堆砌在一起……整個項目非常複雜。每次修改代碼都心驚膽戰，甚至添加一個簡單的功能，或者修改一個BUG都會造成隱含的缺陷。
(2):技術債務
隨着時間推移、需求變更和人員更迭，會逐漸形成應用程序的技術債務，並且越積越多。“不壞不修（Not broken，don’t fix）”，這在軟件開發中非常常見，在單體應用中這種思想更甚。已使用的系統設計或代碼難以修改，因爲應用程序的其他模塊可能會以意料之外的方式使用它。
(3):部署頻率低
隨着代碼的增多，構建和部署的時間也會增加。而在單體應用中，每次功能的變更或缺陷的修復都會導致我們需要重新部署整個應用。全量部署的方式耗時長、影響的範圍大、風險高，這使得單體應用項目上線部署的頻率較低。而部署頻率低又導致兩次發佈之間會有大量的功能變更和缺陷修復，出錯概率比較高。
(4):擴展能力受限
單體應用只能作爲一個整體進行擴展，無法結合業務模塊的特點進行伸縮。例如，應用中有的模塊是計算密集型的，它需要強勁的CPU；有的模塊則是IO密集型的，需要更大的內存。由於這些模塊部署在一起，我們不得不在硬件的選擇上做出妥協。
(5):阻礙技術創新
單體應用往往使用統一的技術平臺或方案解決所有問題，團隊的每個成員都必須使用相同的開發語言和框架，想要引入新的框架或技術平臺會非常困難。例如，一個使用Struts 2構建的、100萬行代碼的單體應用，如果想要換用Spring MVC，切換成本無疑是非常高的。
二、垂直應用架構
垂直應用顧名思義，就是層級之間的排列是垂直的，爲什麼是垂直的？
我們原先的服務，都是單節點的，假如是單節點的，那麼，當我們初期，應用開始不大的時候，我們的單節點足夠了，可是，當我們的網絡訪問量達到了非常高的情況下，我們的單節點將變得非常的擁堵，這個時候，我們需要將所有的訪問給拆分開，放到多臺機器上，以便不同的機器，提供不同的服務，這些個分散的服務，原先都是集中在一起的，那麼現在，就是被垂直的切割開了，部署怎麼部署呢，實際上市這樣的：我們將本來一個大的服務，拆成許多個小的服務，這樣，我們可以將許多個war包分開部署，這樣，就達到了，將整個大的服務，拆分爲多個小的服務，部署在不同的節點上，就是拆分功能，達到分開部署，每個單節點是一個服務，這樣，就有多個服務後臺了吧，每個節點就可以提供不同的服務了吧
特點：
1、以單體結構規模的項目爲單位進行垂直劃分項目即將一個大項目拆分成一個一個單體結構項目。
2、項目與項目之間的存在數據冗餘，耦合性較大。
3、項目之間的接口多爲數據同步功能，如：數據庫之間的數據庫，通過網絡接口進行數據庫同步。
優點：
1、解決高併發問題（如果用戶中心訪問的人數過多，我們只需要對用戶中心進行單一的集羣部署）
2、方便水平擴展，容錯(用戶中心出現問題，商品系統，後臺系統還可以正常訪問)
3、通過垂直拆分，原來的單體項目不至於無限擴大。
4、不同的項目可採用不同的技術。
缺點：
1、系統之間太過於獨立(彼此之間有聯繫，有需要互相調用的，怎麼辦。應用之間的交互，已經達到了不可避免的地步)
2、重複開發工作(每個獨立的項目都會出現重複性的的代碼)
三、SOA架構
詳細說明參照 https://blog.csdn.net/u013343616/article/details/79460398
特點：
1、將系統服務層完全獨立出來，並將服務層抽取爲一個一個的微服務。
2、微服務遵循單一原則。
3、微服務之間採用RESTful等輕量協議傳輸。
優點：
1、抽取公共的功能爲服務，提高開發效率
2、對不同的服務進行集羣化部署，解決系統壓力
3、基於ESB/DUBBO減少系統耦合。
缺點：
1、微服務過多，服務治理成本高，不利於系統維護。
2、分佈式系統開發的技術成本高（容錯、分佈式事務等），對團隊挑戰大。
如有錯誤之處歡迎指出修正！謝謝