使用Spring Cloud須要瞭解一些概念

Spring Cloud是一個基於Spring Boot實現的微服務架構開發工具，它爲基於JVM的微服務開發中的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式會話和集羣狀態管理等操做提供了一站式的開發框架。而上文提到的微服務架構就是將一個完整的應用從數據存儲開始垂直拆分紅多個不一樣的服務，每一個服務都能獨立部署、獨立維護、獨立擴展，服務與服務間經過RESTful API方式進行通訊。

一次典型的對基於Spring Cloud架構的訪問以下

#1 client請求經過統一的API智能路由網關Zuul來訪問內部服務，這樣客戶端就不用知道服務端的詳細地址或者相關信息，僅僅經過API gateway就能夠訪問後端服務，同時zuul能夠對請求進行鑑權或者驗證。

#2 智能路由網關Zuul接收到請求後，從服務註冊發現中心Eureka獲取可用服務的host列表，經過負載均衡算法計算後獲取服務實例的host並轉發請求；這樣內部服務於外部調用方，或者內部服務之間的依賴耦合轉變成了對Eureka的依賴。

#3 獲取到指定類型的服務後由客戶端負載均衡器Ribbon統一分發到後端service具體實例。

#4 後端獨立的service之間經過Feign進行通訊處理業務信息。
#5 斷路由Hystrix負責處理服務超時熔斷，從而避免由於服務提供者不可用致使的服務消費者不可用的雪崩效應。
#6 集羣監控Turbine用於監控服務間的調用和熔斷相關指標。

 

 

使用Spring Boot快速構建spring app
隨着spring整合套件的增多，配置文件也愈來愈多，spring boot用於簡化冗餘的配置文件，基於約定和包路徑自動進行配置；spring-boot-starter-parent表示引用父項目模板中的缺省依賴和默認配置（好比src/main/resources/application.properties爲spring boot項目的缺省配置文件）；spring-boot-starter-web表示引入spring web全棧模塊，包含spring MVC和Tomcat；spring-boot-maven-plugin表示能夠直接經過mvc命令控制spring boot的啓停。
@RestController：於sprint 4.0引入，是@Controller和@ResponseBody的集合，表示定義支持REST接口的控制器。
@EnableAutoConfiguration：啓用基於約定和包路徑的自動配置
@SpringBootApplication：基於spring boot的全家桶配置

 

使用spring cloud eureka進行服務註冊和發現管理
隨着系統內服務的增長，維護服務實例的訪問host:port成爲一件很是費時費力的事情，各類服務的host:port可能隨時變化，而這類變化須要實時被記錄下來，不然可能致使服務不可用；eureka就是用於充當service provider和service client之間的一個呼叫中心，提供服務註冊和服務發現功能，讓provider和client徹底解耦獨立，不互相依賴。
@EnableEurakaServer：建立並啓動一個服務註冊中心。
@EnableDiscoveryClient：將當前app註冊成爲eureka的客戶端應用（自身成爲eureka管理的一個服務提供方）並具備發現其餘服務的能力。
RestTemplate.getForEntity("http://HELLO-SERVICE/hello", String.class).getBody()：生成GET請求（也提供了postForEntity, put, delete請求的封裝），eureka會返回一個Map包含hello-service和服務實例的地址列表，而後經過使用RestTemplate調用指定的服務HELLO-SERVICE/hello，spring cloud會將服務名字轉換成對應的服務實例地址，string.class表示返回結果的數據類型；

 

使用spring cloud ribbon實現客戶端負載均衡
一般所說的負載均衡通常指的是服務端負載均衡（硬件如F5，軟件如Nginx），做用於服務端，未來自客戶端的請求按必定策略分配給內部的服務實例；而客戶端負載均衡則是做用於客戶端，每個客戶端均可以從註冊中心獲取一份可用服務實例的清單，經過客戶端的負載均衡實現對系統的高可用、網絡壓力的緩解和處理能力的擴容。
經過spring cloud的封裝能夠將面向服務的REST模板請求自動封裝成客戶端負載均衡的服務調用；因爲spring cloud內部基本都是基於REST的通訊，而服務方基本均可以作集羣部署，所以ribbon是做爲一個工具框架應用於大部分spring cloud的服務中。
@LoadBalanced：使用LoadBalancerInterceptor對Http請求進行客戶端的負載均衡，全部經過restTemplate進行的請求都會被其攔截並動態分配服務實例 。

 

使用spring cloud hystrix 實現服務容錯保護
微服務架構中server之間可能存在相互調用的依賴，服務A須要調用服務B，同時服務A也爲服務C提供服務；若是由於某些網絡故障致使服務A隊服務B的調用不可達，最終致使服務A也不可用，這樣的狀況稱爲服務故障雪崩，spring cloud Hystrix經過引入斷路由的故障監控，在服務不可用而且知足某些條件的前提下，向服務調用方返回一個錯誤響應，而不是一味地等待。
@EnableCircuitBreaker：標註於服務調用方的啓動類，表示開啓斷路由功能
@HystrixCommand(fallbackMethod=」failCallBackFunc」)：標註於服務提供方的目標方法上，表示若是目標方法調用超時或者失敗的話，返回名字爲failCallBackFunc的資源方法。

 

使用spring cloud feign整合ribbon和hystrix的功能進行聲明式服務調用
通常應用中使用spring cloud ribbon和spring cloud hystrix都是同時出現，爲了簡化配置流程，使用feign統一配置客戶端負載均衡和微服務容錯保護。
@FeignClient(「target-service」)：標註於目標服務的資源類，綁定服務名並指定@RequestMapping資源，
@EnableFeignClients：標註於服務調用方的啓動類，而後經過@Controller就能夠直接訪問對應的資源，而且擁有負載均衡和服務容錯保護功能。

 

使用spring cloud zuul實現對外API網關服務
外部請求訪問內部服務的時候每每須要經過F5或者Nginx進行路由和負載均衡，最終發送到對應的服務實例上，運維人員須要手動維護路由規則、負載均衡規則和服務實例的地址，隨着內部複雜性的增長，須要一個相似façade的服務對外部請求進行統一處理。Zuul不只能夠實現路由和負載均衡（自動集成了ribbon和hystrix），還能夠經過添加過濾器的方式實現用戶登陸驗證和訪問鑑權的功能。
@EnableZuulProxy：開啓zuul的API網關服務功能，並經過在application.properties中添加路由規則的配置就能夠實現轉發功能：
zuul.routes.api-a-url.path=/api-a-url/**
zuul.routes.api-a-url.url=http://localhost:8081/
可是仍是推薦使用與eureka結合使用service id的方式，全部來自外部的請求首先會到達zuul實現的API網關服務器集羣，而後根據路由規則找到request對應的serviceId，接着根據eureka註冊中心獲取serviceId和host:port list的mapping，而且自動實現負載均衡和斷路由，最終將請求送到微服務的實例上。
zuul.routes.api-b-url.path=/api-b-url/**
zuul.routes.api-b-url.serviceId=helo-service
在zuul API網關上經過繼承ZuulFilter並實現抽象方法來實現攔截器的定義：
public String filterType()：表示過濾器在請求的那個生命階段執行，pre類型實現請求鑑權和路由映射，routing類型實現請求轉發到具體的實例，post類型處理請求返回的結果，error類型處理蒸鍋過程裏的異常錯誤。
public int filterOrder()：當一個生命階段有多個過濾器的時候須要決定執行的前後順序
public boolean shouldFilter()：當前的過濾器是否須要生效
public Object run()：具體過濾的操做邏輯

 

使用spring cloud config實現集中式的外部配置支持隨着spring cloud集羣的增大，各項配置也須要統一進行管理和統一配置，spring cloud config能夠實現經過一個做爲微服務的實例統一從GIT倉庫獲取配置文件。@EnableConfigServer：標註微服務實例的啓動類，而且在appication.properties中配置GIT的訪問URL，路徑分支，用戶名，密碼，文件版本等。