Spring Cloud 模塊簡介2

前面一篇文章談到微服務基礎框架，而Netflix的多個開源組件一塊兒正好能夠提供完整的分佈式微服務基礎架構環境，而對於 Spring Cloud正是對Netflix的多個開源組件進一步的封裝而成 ，同時又實現了和雲端平臺，和Spring Boot開發框架很好的集成。

Spring Cloud是一個相對比較新的微服務框架，今年(2016)才推出1.0的release版本. 雖然Spring Cloud時間最短, 可是相比Dubbo等RPC框架, Spring Cloud提供的全套的分佈式系統解決方案。

Spring Cloud 爲開發者提供了 在分佈式系統（配置管理，服務發現，熔斷，路由，微代理，控制總線，一次性token，全居瑣，leader選舉，分佈式session，集羣狀態）中快速構建的工具 ，使用Spring Cloud的開發者能夠快速的啓動服務或構建應用、同時可以快速和雲平臺資源進行對接。

咱們先簡單闡述下Spring Cloud中文社區對四個基礎關鍵組件的描述：

社區地址： http://springcloud.cn/

Spring Cloud Config配置中心



Spring Cloud Config就是咱們一般意義上的配置中心。Spring Cloud Config-把應用本來放在本地文件的配置抽取出來放在中心服務器， 本質是配置信息從本地遷移到雲端 。從而可以提供更好的管理、發佈能力。

Spring Cloud Config分服務端和客戶端， 服務端負責將git（svn）中存儲的配置文件發佈成REST接口 ，客戶端能夠從服務端REST接口獲取配置。但客戶端並不能主動感知到配置的變化，從而主動去獲取新的配置，這須要每一個客戶端經過POST方法觸發各自的/refresh。

Spring Cloud Netflix 服務發現


Spring Cloud Eureka提供在分佈式環境下的服務發現，服務註冊的功能。

Spring Cloud Netflix，該項目是Spring Cloud的子項目之一，主要內容是對Netflix公司一系列開源產品的包裝，它爲Spring Boot應用提供了自配置的Netflix OSS整合。

經過一些簡單的註解，開發者就能夠快速的在應用中配置一下經常使用模塊並構建龐大的分佈式系統。它主要提供的模塊包括： 服務發現（Eureka），斷路器（Hystrix），智能路由（Zuul），客戶端負載均衡（Ribbon）等。

Spring cloud Hystrix 熔斷器



斷路器(Cricuit Breaker)是一種可以在遠程服務不可用時自動熔斷(打開開關)，並在遠程服務恢復時自動恢復(閉合開關)的設施。

斷路器(Cricuit Breaker)是一種可以在遠程服務不可用時自動熔斷(打開開關)，並在遠程服務恢復時自動恢復(閉合開關)的設施，Spring Cloud經過Netflix的Hystrix組件提供斷路器、資源隔離與自我修復功能。

Spring Cloud Zuul 服務網關


Spring Cloud Eureka提供在分佈式環境下的服務發現，服務註冊的功能。

Spring Cloud Netflix，該項目是Spring Cloud的子項目之一，主要內容是對Netflix公司一系列開源產品的包裝，它爲Spring Boot應用提供了自配置的Netflix OSS整合。 經過一些簡單的註解，開發者就能夠快速的在應用中配置一下經常使用模塊並構建龐大的分佈式系統。它主要提供的模塊包括：服務發現（Eureka），斷路器（Hystrix），智能路有（Zuul），客戶端負載均衡（Ribbon）等。

固然Spring Cloud還有額外擴展的其它不少組件，包括了服務鏈路監控和跟蹤（很關鍵的一個功能），消息總線，數據流處理，批量任務處理等。而對於整個Spring Cloud微服務框架簡單來講，便是：

你只要劃分到你的微服務組件和模塊，並定義好須要暴露的API接口，那麼剩下的整個開發和傳統方式沒有太大的區別，你開發完成的組件集成起來就是一個分佈式可擴展的微服務環境。裏面設計到的接口發佈，服務註冊，服務調用和路由，服務監控，健康檢測和流控等都會由微服務框架來幫你完成。

正是有了成熟的微服務框架，咱們才更應該將微服務架構設計重心從技術底層轉移到組件劃分和接口設計上。

SpringCloud和Dubbo的區別問題

對於二者的區別在以下文章有詳細描述能夠參考：

http://blog.didispace.com/microservice-framework/

能夠看到SpringCLoud可以提供的基礎能力要多於Dubbo，Dubbo能夠看做是SpringCLoud簡單實現。

Dubbo是RPC服務治理框架，和Spring Cloud同樣具有服務註冊、發現、路由、負載均衡等能力。可是沒有配置中心，完整的好用全鏈路監控，須要採用開源的解決方案定製或者自研。Spring cloud的配置中心，全鏈路監控等組件。從目前來看，Spring Cloud國內中小型企業用的比較多，大型企業可能須要對其須要的組件進行定製化處理。

可是也須要看到Spring Cloud基於註解的服務發現，服務治理等功能具備代碼侵入性，dubbo沒有代碼侵入性，業務開發人員不須要經過註解的方式去關注框架級別的處理。從中間件或者作基礎架構的角度來看，其實服務治理等功能對普通的業務程序員應該是透明的，業務程序員不須要關注服務治理框架的使用，專一於業務代碼便可。

基於SpringCLoud微服務框架的實踐

對於基於SpringCLoud框架的具體實踐，建議參考翟永超博客的系列文章，具體以下：

• 服務註冊和發現：http://blog.didispace.com/springcloud1/
• 服務消費：http://blog.didispace.com/springcloud2/
• 服務熔斷機制：http://blog.didispace.com/springcloud3/
• 服務配置中心：http://blog.didispace.com/springcloud4/
• 服務網關：http://blog.didispace.com/springcloud5/
• 高可用服務註冊中心：http://blog.didispace.com/springcloud6/
• 消息總線：http://blog.didispace.com/springcloud7/

服務註冊和發現

注意這裏仍然使用的是SpringBoot框架，並和SpringBoot框架進行了集成，在pom.xml配置文件中增長了對SpringCLoud相關包和組件的依賴。在原有的接口API定義的基礎上，咱們增長@EnableDiscoveryClient註解後，便可以讓服務註冊中心很輕鬆的發現服務提供方以及提供的服務。

服務消費

方式1 - Ribbon是一個基於HTTP和TCP客戶端的負載均衡器。Ribbon能夠在經過客戶端中配置的ribbonServerList服務端列表去輪詢訪問以達到均衡負載的做用。當Ribbon與Eureka聯合使用時，ribbonServerList會被DiscoveryEnabledNIWSServ erList重寫，擴展成從Eureka註冊中心中獲取服務端列表。

方式2 - Feign是一個聲明式的Web Service客戶端，它使得編寫Web Serivce客戶端變得更加簡單。咱們只須要使用Feign來建立一個接口並用註解來配置它既可完成。它具有可插拔的註解支持，包括Feign註解和JAX-RS註解。Feign也支持可插拔的編碼器和解碼器。Spring Cloud爲Feign增長了對Spring MVC註解的支持，還整合了Ribbon和Eureka來提供均衡負載的HTTP客戶端實現。

斷路器

首先在pom.xml文件中增長引入對hystrix依賴，同時在消費端Application主類上增長@EnableCircuitBreaker註解開啓斷路器功能。注意原有的服務消費方式也涉及到修改，增長了服務Callback的回調函數。

服務網關

服務網關是微服務架構中一個不可或缺的部分。經過服務網關統一貫外系統提供REST API的過程當中，除了具有服務路由、均衡負載功能以外，它還具有了權限控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，爲微服務架構提供了前門保護的做用，同時將權限控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務集羣主體可以具有更高的可複用性和可測試性。