Monolith（單體應用）架構的缺點
在項目很小的情況下這種單體應用比較簡單，但是隨着項目越變越大，代碼越來越多。就會存在以下缺點。
①編譯難，部署難，測試難
代碼量變多，即使更改一行代碼，也需花大量時間編譯，部署前要編譯打包，解壓等所以部署難，部署完了還要測試所以測試難。
②技術選擇難
在變得越來越大的同時，我們的應用所使用的技術也會變得越來越多。這些技術有些是不兼容的，就比如在一個項目中大范圍地混合使用C++和Java幾乎是不可能的事情。在這種情況下，我們就需要拋棄對某些不兼容技術的使用，而選擇一種不是那么適合的技術來實現特定的功能。
③擴展難
按照Monolith組織的代碼將只產生一個包含了所有功能的WAR包，因此在對服務的容量進行擴展的時候，我們只能選擇重復地部署這些WAR包來擴展服務能力，而不是僅僅擴展出現系統瓶頸的組成：
MicroService(微服務)架構
微服務架構是一種架構模式，它提倡將單一應用程序划分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。
微服務就是把一個單體項目,拆分為多個微服務,每個微服務可以獨立技術選型,獨立開發,獨立部署,獨立運維.並且多個服務相互協調,相互配合,最終完成用戶的價值.
優勢
復雜度可控：
在將應用分解的同時，規避了原本復雜度無止境的積累。每一個微服務專注於單一功能，並通過定義良好的接口清晰表述服務邊界。由於體積小、復雜 度低，每個微服務可由一個小規模開發團隊完全掌控，易於保持高可維護性和開 發效率。
獨立部署：
由於微服務具備獨立的運行進程，所以每個微服務也可以獨立部署。當某個微服務發生變更時無需編譯、部署整個應用。由微服務組成的應用相當於具備一系列可並行的發布流程，使得發布更加高效，同時降低對生產環境所造成的風險，最終縮短應用交付周期。
技術選型靈活：
微服務架構下，技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。由於每個微服務相對簡單，故需要對技術棧進行升級時所面臨的風險就較低，甚至完全重構一個微服務也是可行的。
容錯：
當某一組建發生故障時，在單一進程的傳統架構下，故障很有可能在進程內擴散，形成應用全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩退化等機制實現應用層面的容錯。
擴展：
單塊架構應用也可以實現橫向擴展，就是將整個應用完整的復制到不同的節點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴展。
MonolithµSrvice使用場景
從上圖中可以看到，在剛開始的階段，使用Microservice架構模式開發應用的效率明顯低於Monolith。但是隨着應用規模的增大，基於Microservice架構模式的開發效率將明顯上升，而基於Monolith模式開發的效率將逐步下降。
選型
單體應用架構：中小型項目(功能相對較少) crm 物流 庫存管理等
微服務架構：大型項目（功能比較多） 商城 erp等