Java 系統架構的演變

Java 系統架構演變過程

單一應用 -> 垂直分佈 -> 分佈式服務 -> SOA(面向服務的架構) -> 微服務架構 -> Google Service Mesh

  • 1. 單一應用

特點:

1. 結構簡單,易於部署。

2. 網站流量很小時,一個應用部署所有功能。

3. 簡化增刪改查工作量的ORM框架是影響開發的關鍵。

問題:

1. 代碼耦合,開發維護困難。(代碼之間相互調用,引起錯誤。

2. 無法針對不同模塊進行鍼對化優化。

3. 無法水平擴展。

4. 單點容錯低,併發能力差。(單點故障:一臺掛了,整個掛了。

使用場景:

傳統行業內部開發,訪問量小,適用集中架構。

互聯網訪問量大,不適合集中架構。

  • 2. 垂直分佈

訪問量增大時,單一應用無法滿足需求。爲應對更高的併發和業務需求,需根據業務功能對系統進行拆分。

“用戶中心”,“搜索服務”都要訪問數據庫增刪改查,造成了代碼重複,重複開發引起資源浪費。

“用戶中心”,“搜索服務”相互獨立,分攤流量。

優點:

1. 系統拆分實現流量分擔,解決了併發問題。

2. 針對不同模塊進行優化。

3. 方便水平擴展、負載均衡、容錯率提高。

缺點:

系統間相互獨立、重複開發工作多、影響開發效率。

  • 3. 分佈式服務

垂直應用越來越多,應用之間交互不可避免,抽取核心業務作爲獨立的服務,逐漸形成穩定的服務中心。

服務中心使得前端應用能更快響應市場需求。

分佈式調用:提高業務複用即整合。

優點:

將基礎服務進行抽取、系統間相互調用、提高代碼複用率、提升開發效率

缺點:

系統間耦合度變高、調用關係錯綜複雜、難以維護

  • 4. SOA 面向服務的架構

服務越來越多、容量的評估和小服務資源浪費的問題逐漸出現,此時需要增加一個調度中心基於訪問壓力實時管理集羣容量,提高集羣利用率。

用戶提高機器利用率的資源調度和治理中心(SOA)是關鍵。

以前出現了什麼問題?

  • 服務越來越多,需要管理每個服務的地址。

  • 調用關係錯綜複雜,難以理清依賴關係。

  • 服務過多,服務狀態難以理解,無法根據服務情況動態管理。

服務治理要做什麼?

  • 服務註冊中心:實現服務自動註冊和發現,無需人爲記錄服務地址。

  • 服務自動訂閱,服務列表自動推送,服務調用透明化,無需關心依賴關係。

  • 動態監控服務狀態監控報告,人爲控制服務狀態。

缺點:

  • 服務間會有依賴關係,一旦某個環節出錯會影響很大。(形成雪崩

  • 服務關係複雜,運維、測試部署困難,不符合DevOps思想。

  • 5. 微服務架構

​​​​​​​

微服務特點:

  • 單一職責:微服務中每一個服務都對應唯一的業務能力,做到單一職責。

  • 微:微服務的服務拆分粒度很小。例如:一個用戶管理就可以作爲一個服務。

  • 面向服務:每個服務都要對外暴露Reset風格服務接口API。不關心服務的技術實現,做到與平臺和語言無關,不限定技術實現,只提供Reset的接口即可。

  • 6. Google Service Mesh

​​​​​​​ServiceMesh本質上就是模式三~主機獨立進程代理,它結合了模式一和模式二的優勢,但是分佈式部署運維管理開銷大。Istio對ServiceMesh的架構、功能和API進行了標準化

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章