單體架構，分布式系統的差別在哪裡？

前言

隨著技術日新月異的發展，最近幾年微服務和分布式技術成為主流。每一個好的解決方案不一定是直接設計出來的，但每一個優秀的架構都必須承受得住業務的考驗和需求驅動的積累。最初我們開發系統都是在單個的應用上進行開發、測試、部署和運維等。每次新的需求迭代都將可能涉及到整個系統的修改，尤其是龐大而臃腫的業務系統需要進行大量的數據增刪改查操作，開發起來變得非常麻煩。為了應對更高的並發和業務需求，解決單個應用的缺點，把龐大複雜的單體應用按照業務拆分成多個子業務模塊，可進行垂直拆分或水平拆分，從而達到更高效的開發、更好的管理和維護的目的，這就是所謂的分布式系統。

一、單體架構是什麼？

1.1 定義

一個歸檔包（可以是JAR、WAR、EAR或其它歸檔格式）包含所有功能的應用程式，通常稱為單體應用。而架構單體應用的方法論，就是單體應用架構。

1.2 單體應用舉例
單體應用集成了前端頁面和後端接口服務及業務邏輯和數據操作於一體的單個完整系統，Struts1、Struts2及SSH、SSM架構的系統等，單個應用囊括了所有業務模塊。

1.3 單體架構示意圖

1.4 單體應用優缺點
1.4.1 優點

• 易於集中式開發、測試、管理、部署。
• 無需考慮跨語言。
• 能避免功能重複開發（相對分布式）。

1.4.2 缺點

• 團隊合作困難
• 代碼的維護、重構、部署都比較難。
• 穩定性、可用性（停機維護）、擴展性不高。

當用戶規模越來越大時，單體應用可以通過集群來應對。如通過DNS、Nginx或硬體F5分配集群中的伺服器來提供服務。它的缺點（開發效率低、可維護差穩定性查）導致需要對單體應用進行拆分，垂直拆分或水平拆分。

二、分布式系統（微服務）是什麼？

2.1 微服務定義

微服務架構風格是一種將一個單一應用程式開發為一組小型服務的方法，每個服務運行在自己的進程中，服務間通信採用輕量級通信機制。這些服務圍繞業務能力構建並且可通過全自動部署機制獨立部署。這些服務共用一個最小型的集中式的管理，服務可用不同的語言開發，使用不同的數據存儲技術。

2.2 微服務舉例

市面上目前典型主流的微服務架構有SpringBoot、SpringCloud、Dubbo，微服務興起的時代，除了官方幾個代表的框架外，各大廠商也開始了各自開源的分布式框架。除了上面說的Dubbo外，還有騰訊的Tars，京東的JSF，新浪的Motan等。

2.3 示意圖

2.4 優缺點

2.4.1 優點

• 每個業務模塊獨立開發、測試、部署和管理。
• 每個業務模塊之間相互的影響小，按需分配資源。
• 所有業務模塊既是獨立，又組成一個完整整體。
• 可通過配置進行上遊調用的升級或降級。
• 支持高並發、高擴展、高可用等大型系統。

2.4.2 缺點

• 資源耗用相對單體應用增大，每個業務模塊需單獨部署。
• 分布式數據一致性問題（CAP）。
• 系統維護成本加大，需要更多的人工介入。
• 業務間耦合度變高，調用關係錯綜複雜。

儘管分布式微服務給開發人員帶來極大的使用便利性和系統性能上的優越性。但也暴露了分布式難以解決的一些問題，著名的CAP理論就是其中的一個典型。不過整體來說還是利大於弊，選擇分布式微服務架構是未來的趨勢，也是淘汰舊技術的必經之路。

---

三、總結

從單體架構到分布式微服務架構，我們可以把單體應用簡單分為水平拆分或垂直拆分兩種方式。如一個電商系統，包含：商品模塊、會員模塊、物流模塊、支付模塊、訂單模塊幾個核心模塊。水平拆分，單體應用把所有這些模塊集中在一個電商系統裡面，水平拆分後分為：商品系統、會員系統、物流系統、支付系統、訂單系統。垂直拆分，會員系統可按會員等級分為：普通用戶、VIP用戶、超級VIP用戶等。

福利：

點擊查看：