## 12.2 單體系統到系統拆分 如果你對上一節還有疑惑，在想為什么我不把所有系統放到一個工程里，打成一個war包，也就是我們所謂的單體系統呢？ 單體系統確實是一種常見系統設計方式，這十幾年年來最主要的設計方式。單體系統的所有功能都在一個工程里，打成一個war包，部署。這樣有如下明顯好處 * 單體系統開發方式簡單，我們從剛開始學習編程，就是完成的單體系統，開發人員只要集中精力開發當前工程 * 容易修改，如果需要修改任何功能，都非常方便，只需要修改一個工程范圍的代碼 * 測試簡單，單體系統測試不需要考慮別的系統，避免本書下冊要提到的各種REST，MQ調用 * 部署也很容易：不需要考慮跟別的系統關系，直接打war包部署到Web服務器即可 * 性能容易擴展，可以通過Nginx，把一個應用部署到多個服務器上。 隨著業務發展，重構，單體系統越來越多，在開發一個龐大的單體系統的時候，就會有如下弊病 * 單體系統龐大，越來越難理解單體系統，微小的改動牽涉面廣泛導致開發小組小心謹慎，開發速度會越來越慢。另外，啟動一個龐大的單體系統，可能需要3分鐘，或者更多時間 * 多個功能在同一個單體系統上開發，導致測試越來越慢，比如，測試必須排期，串行測試 * 單體系統如果想對技術進行更新換代，那代價非常大，如果是個小系統構成，則可以選取一個小系統先做嘗試。單體大系統是幾乎不可能做技術升級的 * 單體系統的所有功能運行在同一個JVM里，功能會互相影響，比如一個統計上傳word文檔的頁碼的功能由于非常消耗CPU，因此，會因為調用統計功能，導致整個系統短暫都不可用，出現假死的現象 因此，越來越多的架構師在設計系統的時候，會考慮系統拆分成多個單體小系統甚至是微服務。對于傳統企業應用，拆成小系統更合適，對互聯網系統，使用微服務個更合適，這是因為 * 傳統IT系統本質上還是會用一個數據庫，而微服務提倡的是一個服務一個數據庫 * 傳統IT系統很少需要調用其他模塊服務。傳統IT系統通過工作流來串聯其他子系統。而電商類的微服務則是通過RPC等方式進行交互，是一個輕量級協議。傳統IT系統也可以通過SOA，JMS跟其他系統(非子系統)交互，采用重量級協議 * 微服務對系統的基礎設施要求很高，比如微服務治理，彈性庫等等，只要電商系統才有人力物力去做這種事情，而傳統IT系統，及時財大氣粗，也暫時不具備微服務那樣的IT基礎設置 因此，對于大多數傳統IT應用來說，單體拆分小系統在技術上沒有風險，是一個可以立即實施的架構。如下是一個單體系統拆分后的物理架構  對于用戶來說，訪問不同的菜單功能，講定位到不同的子系統，提供服務。 > 關于如上物理架構實現，在本書的下冊。plus系統即可以拆分成小系統，也可以作為一個單體系統來設計。這一章主要介紹plus系統的核心功能和開發方法