Spring Cloud的目標是為Spring開發人員提供一套易于使用的工具來構建分布式系統。它主要通過包裝其他實現堆棧，從Netflix OSS堆棧開始。然后，這些堆棧將通過基于注釋的配置，JAVA配置和基于模板的編程的熟悉工具進行消耗。我們來看幾個Spring Cloud的組件。
Spring Cloud配置服務器
Spring Cloud Config Server(配置服務器)提供了可水平擴展的集中式配置服務。它使用可插拔存儲庫層作為其數據存儲，當前支持本地存儲，Git和Subversion。通過利用版本控制系統作為配置存儲，開發人員可以輕松地對配置更改進行版本化和審核。
配置表示為Java屬性或YAML文件。Config Server將這些文件合并到環境對象中，將對Spring屬性和配置文件的理解模型呈現為REST API。這個REST API可以直接由任何應用程序查詢來獲取配置數據，但可以將智能客戶端綁定添加到 Spring Boot 應用程序中，這些應用程序將自動協調任何本地配置與配置服務器接收的配置。
Spring Cloud總線
Spring Cloud Config Server是一種強大的機制，用于在一組應用程序實例中一致地分發配置。然而，就目前而言，我們目前僅限于在應用程序啟動時更新此類配置。將屬性的新值推送到Git后，我們需要手動重新啟動每個應用程序流程以獲取新值。我們想要的是在不重新啟動的情況下刷新應用程序配置的功能。
Spring Cloud Bus為您的應用程序實例添加一個管理背板。它目前被實現為客戶端綁定到一組AMQP交換和隊列，但這個后端也被設計為可插拔。Cloud Bus為您的應用程序添加了更多的管理端點。在圖中，我們看到上POST到App A的/bus/refresh端點的一個請求，由此獲得Git的greeting屬性新值。此請求觸發三個事件：
- App A從配置服務器請求最新的配置。 使用@RefreshScope注釋的任何Spring Bean 將重新初始化到新配置。
- 應用程序A向AMQP交換機發送消息，指示它已經接收到刷新事件。
- 通過聆聽適當的AMQP隊列參與Cloud Bus的應用程序B和C以與App A相同的方式接收消息并更新其配置。現在我們可以刷新應用程序的配置而無需重新啟動。
Spring Cloud Netflix
Spring Cloud Netflix提供了幾個Netflix組件的封裝：Eureka，Ribbon，Hystrix和Zuul。下面依次討論這些。
Eureka是一個有彈性的服務注冊表實現。服務注冊表是用于服務發現的一種機制
Spring Cloud Netflix通過簡單地將spring-cloud-starter-eureka-server依賴關系添加到Spring Boot應用程序，然后用@EnableEurekaServer來標注該應用程序的配置類.
應用程序可以通過添加spring-cloud-starter-eureka依賴關系并注釋@EnableDiscoveryClient其配置類來參與服務發現。此注釋提供了將DiscoveryClient正確配置的實例注入任何Spring Bean的功能。 DiscoveryClient是服務發現的抽象，在這種情況下恰好是通過Eureka實現的，但也可以提供與其他候選技術棧（如Consul）的集成。 DiscoveryClient 能夠提供位置信息（例如網絡地址），并提供根據服務邏輯標識符在Eureka注冊服務實例的其它元數據。
Eureka提供的負載平衡算法只限于輪循。 Ribbon提供了一個復雜的客戶端IPC庫，具有可配置的負載平衡和容錯能力。可以從Eureka服務器獲取的動態服務器列表導出輪詢列表。Spring Cloud Netflix通過向Spring Boot添加spring-cloud-starter-ribbonSpring添加依賴關系來提供輪詢Ribbon的集成。這個額外的庫也提供了將LoadBalancerClient正確配置的實例注入任何Spring Bean的能力，這將使客戶端獲得負載平衡（圖4）。
除了其他任務之外，使用Ribbon還可以實現額外的負載平衡算法，例如可用性過濾，加權響應時間和可用性區域密切關系。
Spring Cloud Netflix將通過自動創建一個RestTemplate的可以注入到任何Spring Bean中的Ribbon增強實例進一步增強Spring開發人員對Ribbon的使用。開發人員可以簡單地將提供URL中的邏輯服務名稱傳遞給RestTemplate：
@Autowired
@LoadBalanced
private RestTemplate restTemplate;
@RequestMapping("/")
public String consume() {
ProducerResponse response = restTemplate.getForObject("http://producer", ProducerResponse.class);
return String.format("{"value": %s}", response.getValue());
}
Hystrix 為分布式系統提供了常見的容錯模式的實現（如斷路器 和隔板）。斷路器通常被實現為狀態機，其示例在圖5中找到。
斷路器可以放置在服務和其遠程依賴之間。如果電路關閉，則對依賴關系的調用正常通過。如果呼叫失敗，則計算該失敗。如果故障次數在可配置的時間段內達到閾值，則電路跳閘以打開。在打開狀態下，調用不再發送到依賴項，并且生成的行為是可自定義的（拋出異常，返回偽數據，調用不同的依賴關系等）。
定期地，狀態機將轉換到“半開”狀態，以確定依賴關系是否再次健康。在這種狀態下，請求再次通過。如果請求成功，機器將返回到關閉狀態。如果請求失敗，機器將轉回到打開狀態。
Spring Cloud應用程序可以通過添加spring-cloud-starter-hystrix 依賴關系并注釋@EnableCircuitBreaker其配置類來利用Hystrix。然后，您可以通過以下方式對任何Spring Bean方法用@HystrixCommand添加斷路器：
@HystrixCommand(fallbackMethod = "getProducerFallback")
public ProducerResponse getValue() {
return restTemplate.getForObject("http://producer", ProducerResponse.class);
}
此示例指定一個名為getProducerFallback的后備方法。當斷路器處于斷開狀態時，這種方法將被用來代替getValue：
private ProducerResponse getProducerFallback() {
return new ProducerResponse(42);
}
除了提供狀態機行為外，Hystrix還會從每個斷路器發出一個指標流，提供重要的遙測，如請求測量，響應時間直方圖以及成功，失敗和短路請求的數量（圖6）。
Zuul處理Netflix邊緣服務的所有傳入請求。它與其他Netflix組件（如Ribbon和Hystrix）結合使用，為Netflix服務提供靈活而有彈性的路由選擇層。
Netflix使用動態加載到Zuul中的過濾器執行以下功能：
- 身份驗證和安全性： 識別每個資源的身份驗證要求，并拒絕不滿足他們的請求。
- 洞察和監控： 跟蹤邊緣的有意義的數據和統計數據，以便我們準確地了解生產情況。
- 動態路由： 根據需要將請求動態路由到不同的后端集群。
- 壓力測試： 逐漸增加到集群的流量，以衡量性能。
- 卸載： 為每種類型的請求分配容量并刪除超過限制的請求。
- 靜態響應處理： 直接在邊緣構建一些響應，而不是將它們轉發到內部集群。
- 多區域彈性： 跨AWS地區的路由請求，以使我們的ELB使用多樣化，并使我們的邊緣更接近我們的成員。
此外， Netflix利用Zuul的功能,通過canary 版本執行外部路由和壓力測試。
對于一個UI應用程序想要代理對一個或多個后端服務的呼叫等非常常見的用例，Spring Cloud已經創建了一個嵌入式的Zuul代理，以簡化開發。該功能便于用戶前端對其所需的后端服務進行代理，避免了對所有后端單獨管理CORS（跨原始資源共享）和身份驗證問題的需求。Zuul代理是API網關模式的一個重要應用（圖7）
Spring Cloud增強了嵌入式Zuul代理，提供文件上傳的自動處理功能，并且通過添加Spring Cloud Security可以輕松提供OAuth2 SSO，以及向下游服務提供令牌繼承。Zuul使用Ribbon作為其客戶端和所有出站請求的負載均衡器。Ribbon的動態服務器列表通常由Eureka導入，但Spring Cloud能夠從其他來源導入。
進入微服務世界使我們直接進入分布式系統的世界，分布式系統并不總是“正常工作”，所以我們必須假設我們系統的組件的行為和位置往往會是以不可預知的方式不斷變化。
轉自：https://www.jdon.com/soa/spring-cloud.html
