單體架構，分散式系統的差別在哪裡？
目錄
前言
隨著技術日新月異的發展，最近幾年微服務和分散式技術成為主流。每一個好的解決方案不一定是直接設計出來的，但每一個優秀的架構都必須承受得住業務的考驗和需求驅動的積累。最初我們開發系統都是在單個的應用上進行開發、測試、部署和運維等。每次新的需求迭代都將可能涉及到整個系統的修改，尤其是龐大而臃腫的業務系統需要進行大量的資料增刪改查操作，開發起來變得非常麻煩。為了應對更高的並行和業務需求，解決單個應用的缺點，把龐大複雜的單體應用按照業務拆分成多個子業務模組，可進行垂直拆分或水平拆分，從而達到更高效的開發、更好的管理和維護的目的，這就是所謂的分散式系統。
一、單體架構是什麼？
1.1 定義
一個歸檔包（可以是JAR、WAR、EAR或其它歸檔格式）包含所有功能的應用程式，通常稱為單體應用。而架構單體應用的方法論，就是單體應用架構。
1.2 單體應用舉例
單體應用整合了前端頁面和後端介面服務及業務邏輯和資料操作於一體的單個完整系統，Struts1、Struts2及SSH、SSM架構的系統等，單個應用囊括了所有業務模組。
1.3 單體架構示意圖
1.4 單體應用優缺點
1.4.1 優點
- 易於集中式開發、測試、管理、部署。
- 無需考慮跨語言。
- 能避免功能重複開發（相對分散式）。
1.4.2 缺點
- 團隊合作困難
- 程式碼的維護、重構、部署都比較難。
- 穩定性、可用性（停機維護）、擴充套件性不高。
當使用者規模越來越大時，單體應用可以通過叢集來應對。如通過DNS、Nginx或硬體F5分配叢集中的伺服器來提供服務。它的缺點（開發效率低、可維護差穩定性查）導致需要對單體應用進行拆分，垂直拆分或水平拆分。
二、分散式系統（微服務）是什麼？
微服務架構風格是一種將一個單一應用程式開發為一組小型服務的方法，每個服務執行在自己的程序中，服務間通訊採用輕量級通訊機制。這些服務圍繞業務能力構建並且可通過全自動部署機制獨立部署。這些服務共用一個最小型的集中式的管理，服務可用不同的語言開發，使用不同的資料儲存技術。
市面上目前典型主流的微服務架構有SpringBoot、SpringCloud、Dubbo，微服務興起的時代，除了官方几個代表的框架外，各大廠商也開始了各自開源的分散式框架。除了上面說的Dubbo外，還有騰訊的Tars，京東的JSF，新浪的Motan等。
2.3 示意圖
2.4 優缺點
2.4.1 優點
- 每個業務模組獨立開發、測試、部署和管理。
- 每個業務模組之間相互的影響小，按需分配資源。
- 所有業務模組既是獨立，又組成一個完整整體。
- 可通過設定進行上游呼叫的升級或降級。
- 支援高並行、高擴充套件、高可用等大型系統。
2.4.2 缺點
- 資源耗用相對單體應用增大，每個業務模組需單獨部署。
- 分散式資料一致性問題（CAP）。
- 系統維護成本加大，需要更多的人工介入。
- 業務間耦合度變高，呼叫關係錯綜複雜。
儘管分散式微服務給開發人員帶來極大的使用便利性和系統效能上的優越性。但也暴露了分散式難以解決的一些問題，著名的CAP理論就是其中的一個典型。不過整體來說還是利大於弊，選擇分散式微服務架構是未來的趨勢，也是淘汰舊技術的必經之路。
三、總結
從單體架構到分散式微服務架構，我們可以把單體應用簡單分為水平拆分或垂直拆分兩種方式。如一個電商系統，包含：商品模組、會員模組、物流模組、支付模組、訂單模組幾個核心模組。水平拆分，單體應用把所有這些模組集中在一個電商系統裡面，水平拆分後分為：商品系統、會員系統、物流系統、支付系統、訂單系統。垂直拆分，會員系統可按會員等級分為：普通使用者、VIP使用者、超級VIP使用者等。
更多系統架構發展討論詳見另一篇：細數Java技術架構這些年的發展史