從 2004 年發佈 1.0 版本開始,Spring 目前已經演進至 5.x 版本了,爲不一樣時期的應用開發提供了強有力的支撐。如今咱們正面對微服務、DevOps、雲計算這些新的挑戰,Spring 家族的新生力量 Spring Cloud 又將給咱們提供哪些方面的支撐呢?歸納起來講,我以爲主要分爲四類:面試
接下來,咱們將展開每一個點來看一看。首先,咱們來看一下它究竟集成了一些什麼樣的經常使用組件:數據庫
除了經常使用組件以外,Spring Cloud 還集成了微服務全家桶,開箱即用:安全
服務註冊發現類,包括:Eureka、Consul、Zookeeper、Etcd 等。服務註冊:每一個微服務組件都向註冊中心登記本身提供的服務,包括服務的主機、端口號、版本號、通信協議等信息。註冊中心按照服務類型分類組織服務清單,同時以心跳檢測的方式監測清單中服務是否可用,若不可用須要從服務清單中剔除,以達到排除故障服務的效果。服務發現:在服務治理框架下,服務間的調用再也不經過具體的實例地址來實現,而是經過服務名發起請求調用實現。服務調用方經過服務名從註冊中心的服務清單中獲取服務實例的列表清單,經過指定的負載均衡策略取出一個服務實例位置來進行服務調用。架構
服務調用框架類,包括:Ribbon、Feign 等。客戶端負載均衡,將負載均衡邏輯集成到消費方,消費方從註冊中心獲知服務有哪些實例可用,而後再按照某種策略從這些地址中選擇一個服務實例進行訪問。app
服務容錯組件類,包括:Hystrix 等。服務熔斷:某個目標服務不可用或大量訪問超時,系統將斷開該服務的調用,對後續的調用請求,系統再也不繼續轉發至此服務,直接返回失敗應答,從而快速地釋放資源;若是目標服務狀況好轉,則恢復調用。服務降級:在應急屏蔽或服務熔斷狀況下,直接返回本地缺省的應答。負載均衡
統一配置中心類,包括:Spring Cloud Config、Spring Cloud Bus 等。在服務構建階段,配合構建流水線,爲服務軟件包或鏡像提供配置;在服務運維階段,動態調整服務配置,知足運維的靈活性需求;在服務開發階段,提供配置API將配置外置化,供其餘系統調用。框架
服務網關代理類,包括:Zuul、Spring Cloud Gateway 等。主要提供服務路由功能,即接收消費方的全部請求,按照某種策略將請求轉發至服務提供方。同時,在服務網關中完成一系列橫切面的功能,例如:權限校驗、請求計量、流量控制、服務質量、請求管理、響應管理、版本管理等。運維
調用鏈路監測類,包括:Spring Cloud Sleuth,封裝了 Dapper、Zipkin 和 HTrace 等。微服務架構下組件的數量衆多,一個業務請求可能須要調用多個服務,調用的複雜性決定了錯誤和異常難以定位。咱們須要知道每一個請求到底有哪些服務參與,調用順序是怎麼樣的,從而清楚每一個調用步驟,出現問題也能很快定位。微服務
一般咱們會採用 Eureka 做爲服務註冊中心,實現服務註冊與發現;經過 Ribbon 和 Feign 實現服務的消費以及客戶端負載均衡;經過 Spring Cloud Config 實現應用不一樣環境的外部化配置以及版本管理。爲了讓服務集羣更爲健壯,藉助 Hystrix 的融斷機制來避免微服務架構中個別服務出現異常時引發故障蔓延和雪崩。服務網關 Zuul 爲微服務架構門戶,將權限控制、計量計費等較重的非業務邏輯內容遷移到服務路由層面,使得服務集羣主體可以具有更高的可複用性和可測試性。學習
本文主要價值是幫助你們梳理出 Spring Cloud 相關的知識框架,也就是咱們常說的全局視角或者上帝視角。有了這個框架以後,咱們能夠根據本身的須要按圖索驥找相關節點的資料來研究學習,不至於陷入細節找不到方向。固然,考慮到咱們每一個人的工做學習狀況不一樣,平時遇到的問題也不一樣,本文內容沒法覆蓋全部人遇到的問題,歡迎你們留言提問。
今天先分享到這裏,若是你以爲有價值,麻煩動動手指 轉發 給其餘須要的小夥伴。另外,老兵哥我後續還會分享職業規劃、應聘面試、技能提高、影響力打造等經驗,歡迎 關注 本專欄或歪信公主號 「IT老兵哥」!
本系列其餘文章索引以下: