Spring框架之我見（六）——Spring Cloud

聊完Spring Boot，咱們來看看Spring Boot最重要的一方面的應用——Spring Cloud。

Spring Cloud

再聊SpringCloud以前咱們先聊聊微服務。

什麼是微服務？

微服務（Micro Service）:微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被 獨立部署，各個微服務之間是 鬆耦合的。每一個微服務僅關注於完成 一件任務並很好地完成該任務。在全部狀況下，每一個任務表明着一個小的業務能力。

微服務爲何會出現？

• 大型總體式應用維護困難。
• 傳統架構升級困難。
• 新的輕量級協議(RESTful)、容器化(Docker)的出現。

說完了什麼是微服務，咱們在開來看Spring Cloud。

什麼是Spring Cloud？

提到spring Cloud 你們可能覺得他是和雲計算相關的框架。其實不是，Spring Cloud是一套用於微服務的、簡單易懂、易部署和易維護的分佈式系統開發工具包。
它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，均可以用Spring Boot的開發風格作到一鍵啓動和部署。

Spring Cloud如何實現微服務？

• Eureka（註冊中心）：負責全部微服務的管理。
• Ribbon（服務發現）：主要負責客戶端的負載均衡
• Feign（接口假裝）：使微服務之間的調用像本地調用同樣簡單。
• Hystrix（熔斷處理）：在微服務出現問題時防止出現雪崩效應。
• Zuul（代理機制）：安全認證、動態路由、流量管理、服務器負載均衡
• Config（配置管理）：管理全部微服務的配置文件（GIT/SVN）。

具體的實現流程以下：

• 將使用Spring Boot寫的用戶微服務註冊於Eureka，使其受Eureka統一的調度管理。
• 在Eureka外部再包裹一個Ribbon組件，再用戶去訪問用戶微服務的時候，由Ribbon負責多個用戶微服務之間的負載均衡。Ribbon有一個‘心跳’機制，去檢測用戶微服務的狀態，在用戶微服務出現問題時可以及時發現，並處理。
• 在Ribbon的外層，還有一個feign組件用於給微服務作接口假裝，有了feign在用戶調用微服務時就像調用本地的接口同樣簡單，徹底隱藏了微服務的存在。
• 再聊Hystrix以前，咱們的先聊一下什麼是雪崩效應？以及它有什麼危害？先來看一張微服務之間相互調用的關係圖：

假如說用戶但願調用一下微服務A，微服務A又會調用微服務B，微服務B又會去調用微服務C，這時候微服務C出現故障，不能被使用了，若是沒有Hystrix，微服務B全部的調用微服務C的線程都會阻塞，直到把微服務B給拖垮，微服務B一掛，那麼微服務A和微服務Y也就掛了。最後微服務X也掛了。這就是雪崩效應。Hystrix就是用來解決這個問題的，假若有了Hystrix，微服務B在調用微服務C出現問題，線程並不會一直等待，而是直接調用微服務B的一個CallBack的回調方法，直接給微服務A返回一個錯誤消息。再過一段時間以後，微服務B會再次嘗試調用微服務C看微服務C是否已經恢復。這就給了整個微服務的集羣一個自我恢復的能力。

• Zuul就是一個微服務的代理，咱們前面說到的代理能幹的事它都能幹。
• Config是用於微服務的配置文件管理的，雖然在Spring Boot的加持下微服務的配置文件已經不多了，可是，在成百上千的微服務集羣中，配置文件仍是應該有一個組件統一管理和部署。Config使用SVN或者GIT作到配置文件的統一管理，仍是十分的方便。

固然Spring Cloud不單單隻有這幾個工具，其餘更有用的工具要靠你們本身發掘了。