單體應用 單體應用簡單講就是把一個系統所涉及的各個組件都打包成一個一體化結構併進行部署和運行。在Java EE領域，一體化結構很多時候體現為一個WAR包，而部署和運行的環境就是以Tomcat、weblogic為代表的各種應用伺服器 應用伺服器上同時運行面向用戶的web組件、封裝業務邏輯的servic ...
單體應用
單體應用簡單講就是把一個系統所涉及的各個組件都打包成一個一體化結構併進行部署和運行。
在Java EE領域，一體化結構很多時候體現為一個WAR包，而部署和運行的環境就是以Tomcat、weblogic為代表的各種應用伺服器
應用伺服器上同時運行面向用戶的web組件、封裝業務邏輯的service組件、數據訪問的DAO（data access object，數據訪問對象）組件。這些組件作為一個整體進行統一開發、部署、維護。
優點：
團隊規模不太大時，單體應用可由一個開發團隊獨立維護，因為結構簡單，所以團隊成員能對單體應用快速學習、理解、修改。單體應用表現形式一般是一個獨立的WAR包，對它進行集成、部署、實現無狀態集群比較簡單，通常使用負載均衡運行多個相同的實例就能實現系統的伸縮性
缺點：
- 當業務複雜度高時，可擴展性差：單體應用中對系統業務的任何一處進行修改，都需要重新構建這個系統併進行發佈
- 代碼腐化：單體應用缺乏合理的業務和技術實現邊界，隨著產品業務功能增多，出現缺陷時則有可能引起缺陷的原因組合就較多，這會導致分析、定位、修複缺陷的成本增高，即缺陷的平均修複時間可能較長。隨著功能的增加，單體應用的代碼結構也越來越複雜，在開發人員對全局功能缺乏深度理解的情況下，修複一個缺陷的同時還可能引入其他的缺陷。在自動化測試不完善的情況下，可能導致問題越修越多的情況
- 在單體應用中所有的業務和代碼很大程度上無序地混合在一起，存在大量錯綜複雜的業務和代碼結構、由於歷史原因所造成的迥然不同的開發風格以及看似複雜但已經不被使用的遺留代碼，使新員工瞭解行業背景、熟悉應用程式業務、配置本地開發環境變得困難。隨著應用程式的複雜性逐漸增加以及功能越來越多，如果團隊希望嘗試引入新的框架和技術，或對現有技術棧進行升級，通常會面臨較大的風險，即初始的技術選型嚴重限制了單體應用未來採用不同開發語言或框架的能力
分散式系統
分散式系統是指硬體或軟體組件分佈在不同的網路電腦上，彼此之間僅通過消息傳遞進行通信和協調的系統。
在設計和實現分散式系統時需要考慮：
- 網路：分散式系統的所有組件都位於網路之中，對於互聯網應用而言，則位於更為複雜的互聯網環境中
- 通信和協調：位於分散式系統中的各個組件只有通過約定、高效且可靠的通信機制進行相關協作才能完成某一項業務功能
分散式系統兩種拆分思路
- 縱向拆分：將一個大應用拆分為多個小應用，如果新業務較為獨立，那麼就直接將其設計部署為一個獨立的應用系統。縱向拆分關註於業務，通過梳理產品線，將內聚度較高的相關業務進行剝離從而形成不同的子系統
- 橫向拆分：橫向拆分更多地關註於技術。橫向拆分通過將可以復用的業務拆分出來，獨立部署為分散式服務，調用這些分散式服務，構建複雜的新業務。橫向拆分的關鍵在於識別可復用的業務，設計服務介面並規範服務依賴關係
分散式系統的挑戰
- 網路傳輸的三態性：構建分散式系統依賴網路通信，而網路通信表現為一個複雜且不可控的過程。相比單機系統中函數式調用的失敗或者成功，網路通信會出現三態性，即成功、失敗、超時。由於網路原因，消息沒有成功發送到接收方，而是在發送過程中發生了丟失現象；或者接收方處理後，響應給發送方的過程中發生消息丟失現象。這些問題會增加通信的代價，如何使通信的代價降到用戶可以忍耐的層次是分散式系統設計的首要目標
- 異構性：分散式系統由於基於不同的網路、不同的操作系統、不同的軟體實現技術體系，必須要考慮一種通用的服務集成和交互方式來屏蔽異構系統之間的差異。異構系統之間的不同處理方式會對系統設計和開髮帶來難度和挑戰
- 負載均衡：由於分散式系統是多機協同工作的系統，為了提高系統的整體效率和吞吐量，必須考慮最大程度發揮每個節點的作用。負載均衡是保證系統運行效率的關鍵技術
- 數據一致性：在分散式系統中，數據被分散或複製到不同的機器上，如何保證各台主機之間的數據一致性將成為一個難點。因為網路的異常會導致分散式系統中只有部分節點能夠正常通信，從而形成了網路分區(Network Partition，可理解為腦裂)
