一,傳統的應用
1.1,在此之前,所有的架構都是採用單體應用的模式,通過status,spring,hibernate,mybatis等技術架構
每一個項目都會發佈一個單體應用,通過war包的形式發佈到tomcat,每新增一個模塊都要在原始應用上增加,若干個版本後,該war包不斷膨脹,程序員要維護和調試都要啓動半天,變得極其複雜和管理。例:如下war包
該系統涵蓋了銷售,庫存,會員,報表模塊,後期可能還會增加採購,財務,行政等模塊,這樣的單體應用隱患非常多,可能某個模塊的一個Bug就會引發系統的宕機,不斷效率低,風險性還很高,所以得從本質上去改變。
二,架構演進
針對以上的單體應用對架構進行改進,參考SOA架構,將各個模塊劃分爲獨立的服務模塊,並進行數據的讀寫分離。
各個模塊之間存在相互依賴關係,例如銷售模塊需要調用庫存模塊,未來減少模塊之間的耦合,我們加入企業服務總線(ESB)
加入ESB後,將各個模塊發佈到ESB中,發現系統的整體性能提高了,模塊之間的耦合度也降低了,但過了段時間後發現銷售終端的數量增多了,銷售模塊也明顯超出了其承受範圍,爲了保證銷售前端的正常運行,我們加入nginx做負載均衡
目前回到正常運行狀態,但隨着以後各模塊數量的不斷增多,不便於後期的維護,一旦出現模塊修改則牽引着一大批依賴模塊的改動,企業服務總線也可能成爲性能的瓶頸。
1.2從前面的架構演進也可知,應用中的每一點都可能成爲系統的問題點,隨着互聯網的普及和大數據應用,高併發,我們必須建立一套全新的架構能應對這些問題嚴謹的挑戰,它起碼得滿足以下要求。
1:高性能:這是應用程序的基本要求
2:獨立性:確保在某個模塊出現bug等不影響其他模塊
3:易擴展:系統中的每個模塊都能根據需求進行擴展
4:便於管理:輕鬆管理各個模塊之間的資源,升級,減少維護成本
5:狀態監控和警報:當某個節點出現問題能及時發出警報通知從而做出相應的處理方案
爲了能解決以上的問題,我們着手研究SpringCloud吧!
三,微服務與SpringCloud
3.1
微服務是一種架構風格,將各個應用模塊劃分爲單獨的服務單元,微服務之間通過http的api進行資源訪問和操作
微服務對比SOA架構的好處是微服務中的各個模塊單元本身就可以做成一個或多個服務組件,更加細粒度的劃分。
3.2:SpringCloud與微服務
SpringCloud並不是一個具體的框架,大家可以理解爲一個工具箱,它能幫我們快速構建一個分佈式系統,SpringCloud的各個項目通過SpringBoot將NetFilx的多個項目進行封裝,通過自動配置的形式綁定到Spring中,從而簡化了這些框架的使用,由於SpringBoot的簡單易用,我們要使用SpringCloud時可以方便的使用將Netfilx中的各個項目整合進來,SpringCloud主要整合了Netfilx中的項目
Eureka:基於Rest服務的分佈式的中間件,主要用於服務管理
Hystrix:容錯框架,通過添加延遲閥值來幫我們控制分佈式組件中的交互
Feign:一個Rest客戶端,幫助我們簡化webService的開發
Ribbon:一個負載均衡框架,在微服務中爲各個集羣中的通信提供支持,主要應用在中間層框架的負載均衡
Zuul:爲微服務提供代理,過濾,路由等功能
3.3:SpringCloud中的主要模塊
除了SpringCloud-Netfilx中的各個項目,還包括以下主要模塊
SpringCloud-Config:爲分佈式系統中的服務器和客戶端提供配置,通過配置可以更好的管理各組件的配置文件
SpringCloud-Sleuth:服務跟蹤框架,可以與Zipkin,Apache,HTace等數據分析,服務跟蹤系統進行整合
SpringCloud-Steam:用於構建消息驅動的微服務框架
SpringCloud-Bus:連接RibbitMQ,Kafka等消息代理的集羣消息總線
結尾:以上就是本篇的整體概述,下一篇開始代碼。
以上內容部分引自<<楊大仙的瘋狂Spring Cloud>><鏈接>