Spring Cloud做爲一套微服務治理的框架,幾乎考慮到了微服務治理的方方面面,以前也寫過一些關於Spring Cloud文章,主要偏重各組件的使用,本次分享主要解答這兩個問題:Spring Cloud在微服務的架構中都作了哪些事情?Spring Cloud提供的這些功能對微服務的架構提供了怎樣的便利?須要瞭解電子商務平臺源碼可加企鵝邱邱一零三八七七四六二六哦
傳統架構發展史
單體架構
單體架構在小微企業比較常見,典型表明就是一個應用、一個數據庫、一個web容器就能夠跑起來,好比咱們開發的開源軟件雲收藏,就是標準的單體架構。
在兩種狀況下可能會選擇單體架構:一是在企業發展的初期,爲了保證快速上線,採用此種方案較爲簡單靈活;二是傳統企業中垂直度較高,訪問壓力較小的業務。在這種模式下對技術要求較低,方便各層次開發人員接手,也能知足客戶需求。
下面是單體架構的架構圖:前端
在單體架構中,技術選型很是靈活,優先知足快速上線的要求,也便於快速跟進市場。
垂直架構
在單體架構發展一段時間後,公司的業務模式獲得了承認,交易量也慢慢的大起來,這時候有些企業爲了應對更大的流量,就會對原有的業務進行拆分,好比說:後臺系統、前端系統、交易系統等。
在這一階段每每會將系統分爲不一樣的層級,每一個層級有對應的職責,UI層負責和用戶進行交互、業務邏輯層負責具體的業務功能、數據庫層負責和上層進行數據交換和存儲。
下面是垂直架構的架構圖:web
在這個階段SSH(struts+spring+hibernate)是項目的關鍵技術,Struts負責web層邏輯控制、Spring負責業務層管理Bean、Hibernate負責數據庫操做進行封裝,持久化數據。
服務化架構
若是公司進一步的作大,垂直子系統會變的愈來愈多,系統和系統之間的調用關係呈指數上升的趨勢。在這樣的背景下,不少公司都會考慮服務的SOA化。SOA表明面向服務的架構,將應用程序根據不一樣的職責劃分爲不一樣的模塊,不一樣的模塊直接經過特定的協議和接口進行交互。這樣使整個系統切分紅不少單個組件服務來完成請求,當流量過大時經過水平擴展相應的組件來支撐,全部的組件經過交互來知足總體的業務需求。
SOA服務化的優勢是,它能夠根據需求經過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。服務層是SOA的基礎,能夠直接被應用調用,從而有效控制系統中與軟件代理交互的人爲依賴性。
服務化架構是一套鬆耦合的架構,服務的拆分原則是服務內部高內聚,服務之間低耦合。
下面是服務化架構圖:spring
在這個階段可使用WebService或者dubbo來服務治理。
SOA和微服務的區別
其實服務化架構已經能夠解決大部分企業的需求了,那麼咱們爲何要研究微服務呢?先說說它們的區別;
微服務架構強調業務系統須要完全的組件化和服務化,一個組件就是一個產品,能夠獨立對外提供服務
微服務再也不強調傳統SOA架構裏面比較重的ESB企業服務總線
微服務強調每一個微服務都有本身獨立的運行空間,包括數據庫資源。
微服務架構自己來源於互聯網的思路,所以組件對外發布的服務強調了採用HTTP Rest API的方式來進行
微服務的切分粒度會更小
總結:微服務架構是 SOA 架構思想的一種擴展,更增強調服務個體的獨立性、拆分粒度更小。
爲何考慮Spring Cloud
Spring Cloud來源於Spring,質量、穩定性、持續性均可以獲得保證
Spirng Cloud自然支持Spring Boot,更加便於業務落地。
Spring Cloud發展很是的快,從16年開始接觸的時候相關組件版本爲1.x,到如今將要發佈2.x系列
Spring Cloud是Java領域最適合作微服務的框架。
相比於其它框架,Spring Cloud對微服務周邊環境的支持力度最大。
對於中小企業來說,使用門檻較低。
Spring Cloud 是微服務架構的最佳落地方案
如下爲Spring Cloud的核心特性:
分佈式/版本化配置
服務註冊和發現
路由
服務和服務之間的調用
負載均衡
斷路器
分佈式消息傳遞
這些特性都是由不一樣的組件來完成,在架構的演進過程當中扮演着重要的角色。數據庫