為什么需要學習Spring Cloud
不論是商業應用還是用戶應用，在業務初期都很簡單，我們通常會把它實作為單體結構的應用，但是，隨著業務逐漸發展，產品思想會變得越來越復雜，單體結構的應用也會越來越復雜，這就會給應用帶來如下的幾個問題：
-
代碼結構混亂：業務復雜，導致代碼量很大，管理會越來越困難，同時，這也會給業務的快速迭代帶來巨大挑戰；
-
開發效率變低：開發人員同時開發一套代碼，很難避免代碼沖突，開發程序會伴隨著不斷解決沖突的程序，這會嚴重的影響開發效率；
-
排查解決問題成本高：線上業務發現 bug，修復 bug 的程序可能很簡單，但是，由于只有一套代碼，需要重新編譯、打包、上線，成本很高，
由于單體結構的應用隨著系統復雜度的增高，會暴露出各種各樣的問題，近些年來，微服務架構逐漸取代了單體架構，且這種趨勢將會越來越流行，Spring Cloud是目前最常用的微服務開發框架，已經在企業級開發中大量的應用，
什么是Spring Cloud
Spring Cloud是一系列框架的有序集合，它利用Spring Boot的開發便利性巧妙地簡化了分布式系統基礎設施的開發，如服務發現注冊、配置中心、智能路由、訊息總線、負載均衡、斷路器、資料監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署，
Spring Cloud并沒有重復制造輪子，它只是將各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實作原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分布式系統開發工具包，
設計目標與優缺點
設計目標
協調各個微服務，簡化分布式系統開發，
優缺點
微服務的框架那么多比如：dubbo、Kubernetes，為什么就要使用Spring Cloud的呢？
優點：
-
產出于Spring大家族，Spring在企業級開發框架中無人能敵，來頭很大，可以保證后續的更新、完善
-
組件豐富，功能齊全，Spring Cloud 為微服務架構提供了非常完整的支持，例如、配置管理、服務發現、斷路器、微服務網關等；
-
Spring Cloud 社區活躍度很高，教程很豐富，遇到問題很容易找到解決方案
-
服務拆分粒度更細，耦合度比較低，有利于資源重復利用，有利于提高開發效率
-
可以更精準的制定優化服務方案，提高系統的可維護性
-
減輕團隊的成本，可以并行開發，不用關注其他人怎么開發，先關注自己的開發
-
微服務可以是跨平臺的，可以用任何一種語言開發
-
適于互聯網時代，產品迭代周期更短
缺點：
-
微服務過多，治理成本高，不利于維護系統
-
分布式系統開發的成本高（容錯，分布式事務等）對團隊挑戰大
總的來說優點大過于缺點，目前看來Spring Cloud是一套非常完善的分布式框架，目前很多企業開始用微服務、Spring Cloud的優勢是顯而易見的，因此對于想研究微服務架構的同學來說，學習Spring Cloud是一個不錯的選擇，
Spring Cloud發展前景
Spring Cloud對于中小型互聯網公司來說是一種福音，因為這類公司往往沒有實力或者沒有足夠的資金投入去開發自己的分布式系統基礎設施，使用Spring Cloud一站式解決方案能在從容應對業務發展的同時大大減少開發成本，
同時，隨著近幾年微服務架構和Docker容器概念的火爆，也會讓Spring Cloud在未來越來越“云”化的軟體開發風格中立有一席之地，尤其是在五花八門的分布式解決方案中提供了標準化的、全站式的技術方案，意義可能會堪比當年Servlet規范的誕生，有效推進服務端軟體系統技術水平的進步，
整體架構
主要專案
Spring Cloud的子專案，大致可分成兩類，一類是對現有成熟框架"Spring Boot化"的封裝和抽象，也是數量最多的專案；第二類是開發了一部分分布式系統的基礎設施的實作，如Spring Cloud Stream扮演的就是kafka, ActiveMQ這樣的角色，
Spring Cloud Config
集中配置管理工具，分布式系統中統一的外部配置管理，默認使用Git來存盤配置，可以支持客戶端配置的重繪及加密、解密操作，
Spring Cloud Netflix
Netflix OSS 開源組件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心組件，
-
Eureka：服務治理組件，包括服務端的注冊中心和客戶端的服務發現機制；
-
Ribbon：負載均衡的服務呼叫組件，具有多種負載均衡呼叫策略；
-
Hystrix：服務容錯組件，實作了斷路器模式，為依賴服務的出錯和延遲提供了容錯能力；
-
Feign：基于Ribbon和Hystrix的宣告式服務呼叫組件；
-
Zuul：API網關組件，對請求提供路由及過濾功能，
Spring Cloud Bus
用于傳播集群狀態變化的訊息總線，使用輕量級訊息代理鏈接分布式系統中的節點，可以用來動態重繪集群中的服務配置，
Spring Cloud Consul
基于Hashicorp Consul的服務治理組件，
Spring Cloud Security
安全工具包，對Zuul代理中的負載均衡OAuth2客戶端及登錄認證進行支持，
Spring Cloud Sleuth
Spring Cloud應用程式的分布式請求鏈路跟蹤，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟蹤，
Spring Cloud Stream
輕量級事件驅動微服務框架，可以使用簡單的宣告式模型來發送及接收訊息，主要實作為Apache Kafka及RabbitMQ，
Spring Cloud Task
用于快速構建短暫、有限資料處理任務的微服務框架，用于向應用中添加功能性和非功能性的特性，
Spring Cloud Zookeeper
基于Apache Zookeeper的服務治理組件，
Spring Cloud Gateway
API網關組件，對請求提供路由及過濾功能，
Spring Cloud OpenFeign
基于Ribbon和Hystrix的宣告式服務呼叫組件，可以動態創建基于Spring MVC注解的介面實作用于服務呼叫，在Spring Cloud 2.0中已經取代Feign成為了一等公民，
Spring Cloud的版本關系
Spring Cloud是一個由許多子專案組成的綜合專案，各子專案有不同的發布節奏，為了管理Spring Cloud與各子專案的版本依賴關系，發布了一個清單，其中包括了某個Spring Cloud版本對應的子專案版本，
為了避免Spring Cloud版本號與子專案版本號混淆，Spring Cloud版本采用了名稱而非版本號的命名，這些版本的名字采用了倫敦地鐵站的名字，根據字母表的順序來對應版本時間順序，例如Angel是第一個版本，Brixton是第二個版本，
當Spring Cloud的發布內容積累到臨界點或者一個重大BUG被解決后，會發布一個"service releases"版本，簡稱SRX版本，比如Greenwich.SR2就是Spring Cloud發布的Greenwich版本的第2個SRX版本，目前Spring Cloud的最新版本是Hoxton，
Spring Cloud和SpringBoot版本對應關系
Spring Cloud和各子專案版本對應關系
注意：Hoxton版本是基于SpringBoot 2.2.x版本構建的，不適用于1.5.x版本，隨著2019年8月SpringBoot 1.5.x版本停止維護，Edgware版本也將停止維護，
SpringBoot和SpringCloud的區別？
SpringBoot專注于快速方便的開發單個個體微服務，
SpringCloud是關注全域的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合并管理起來，
為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全域鎖、決策競選、分布式會話等等集成服務
SpringBoot可以離開SpringCloud獨立使用開發專案， 但是SpringCloud離不開SpringBoot ，屬于依賴的關系
SpringBoot專注于快速、方便的開發單個微服務個體，SpringCloud關注全域的服務治理框架，
使用 Spring Boot 開發分布式微服務時，我們面臨以下問題
（1）與分布式系統相關的復雜性-這種開銷包括網路問題，延遲開銷，帶寬問題，安全問題，
（2）服務發現-服務發現工具管理群集中的流程和服務如何查找和互相交談，它涉及一個服務目錄，在該目錄中注冊服務，然后能夠查找并連接到該目錄中的服務，
（3）冗余-分布式系統中的冗余問題，
（4）負載平衡 --負載平衡改善跨多個計算資源的作業負荷，諸如計算機，計算機集群，網路鏈路，中央處理單元，或磁盤驅動器的分布，
（5）性能-問題 由于各種運營開銷導致的性能問題，
（6）部署復雜性-Devops 技能的要求，
服務注冊和發現是什么意思？Spring Cloud 如何實作？
當我們開始一個專案時，我們通常在屬性檔案中進行所有的配置，隨著越來越多的服務開發和部署，添加和修改這些屬性變得更加復雜，有些服務可能會下降，而某些位置可能會發生變化，手動更改屬性可能會產生問題，
Eureka 服務注冊和發現可以在這種情況下提供幫助，由于所有服務都在 Eureka 服務器上注冊并通過呼叫 Eureka 服務器完成查找，因此無需處理服務地點的任何更改和處理，
Spring Cloud 和dubbo區別?
（1）服務呼叫方式 dubbo是RPC springcloud Rest Api
（2）注冊中心,dubbo 是zookeeper springcloud是eureka，也可以是zookeeper
（3）服務網關,dubbo本身沒有實作，只能通過其他第三方技術整合，springcloud有Zuul路由網關，作為路由服務器，進行消費者的請求分發,springcloud支持斷路器，與git完美集成組態檔支持版本控制，事物總線實作組態檔的更新與服務自動裝配等等一系列的微服務架構要素，
負載平衡的意義什么？
在計算中，負載平衡可以改善跨計算機，計算機集群，網路鏈接，中央處理單元或磁盤驅動器等多種計算資源的作業負載分布，負載平衡旨在優化資源使用，最大化吞吐量，最小化回應時間并避免任何單一資源的過載，使用多個組件進行負載平衡而不是單個組件可能會通過冗余來提高可靠性和可用性，負載平衡通常涉及專用軟體或硬體，例如多層交換機或域名系統服務器行程，
什么是 Hystrix？它如何實作容錯？
Hystrix 是一個延遲和容錯庫，旨在隔離遠程系統，服務和第三方庫的訪問點，當出現故障是不可避免的故障時，停止級聯故障并在復雜的分布式系統中實作彈性，
通常對于使用微服務架構開發的系統，涉及到許多微服務，這些微服務彼此協作，
思考以下微服務
假設如果上圖中的微服務 9 失敗了，那么使用傳統方法我們將傳播一個例外，但這仍然會導致整個系統崩潰，
隨著微服務數量的增加，這個問題變得更加復雜，微服務的數量可以高達 1000.這是 hystrix 出現的地方 我們將使用 Hystrix 在這種情況下的 Fallback 方法功能，我們有兩個服務 employee-consumer 使用由 employee-consumer 公開的服務，
簡化圖如下所示
現在假設由于某種原因，employee-producer 公開的服務會拋出例外，我們在這種情況下使用 Hystrix 定義了一個回退方法，這種后備方法應該具有與公開服務相同的回傳型別，如果暴露服務中出現例外，則回退方法將回傳一些值，
什么是 Hystrix 斷路器？我們需要它嗎？
由于某些原因，employee-consumer 公開服務會引發例外，在這種情況下使用Hystrix 我們定義了一個回退方法，如果在公開服務中發生例外，則回退方法回傳一些默認值，
如果 firstPage method() 中的例外繼續發生，則 Hystrix 電路將中斷，并且員工使用者將一起跳過 firtsPage 方法，并直接呼叫回退方法，斷路器的目的是給第一頁方法或第一頁方法可能呼叫的其他方法留出時間，并導致例外恢復，可能發生的情況是，在負載較小的情況下，導致例外的問題有更好的恢復機會 ，
什么是 Netflix Feign？它的優點是什么？
Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 啟發的 java 客戶端聯編程式，
Feign 的第一個目標是將約束分母的復雜性統一到 http apis，而不考慮其穩定性，
在 employee-consumer 的例子中，我們使用了 employee-producer 使用 REST模板公開的 REST 服務，
但是我們必須撰寫大量代碼才能執行以下步驟
（1）使用功能區進行負載平衡，
（2）獲取服務實體，然后獲取基本 URL，
（3）利用 REST 模板來使用服務，前面的代碼如下
@Controller
public class ConsumerControllerClient {
@Autowired
private LoadBalancerClient loadBalancer;
public void getEmployee() throws RestClientException, IOException {
ServiceInstance serviceInstance=loadBalancer.choose("employee-producer");
System.out.println(serviceInstance.getUri());
String baseUrl=serviceInstance.getUri().toString();
baseUrl=baseUrl+"/employee";
RestTemplate restTemplate = new RestTemplate();
ResponseEntity<String> response=null;
try{
response=restTemplate.exchange(baseUrl,
HttpMethod.GET, getHeaders(),String.class);
}
catch (Exception ex)
{
System.out.println(ex);
}
System.out.println(response.getBody());
}
之前的代碼，有像 NullPointer 這樣的例外的機會，并不是最優的，我們將看到如何使用 Netflix Feign 使呼叫變得更加輕松和清潔，如果 Netflix Ribbon 依賴關系也在類路徑中，那么 Feign 默認也會負責負載平衡，
什么是 Spring Cloud Bus？我們需要它嗎？
考慮以下情況：我們有多個應用程式使用 Spring Cloud Config 讀取屬性，而Spring Cloud Config 從 GIT 讀取這些屬性，
下面的例子中多個員工生產者模塊從 Employee Config Module 獲取 Eureka 注冊的財產，
如果假設 GIT 中的 Eureka 注冊屬性更改為指向另一臺 Eureka 服務器，會發生什么情況，在這種情況下，我們將不得不重新啟動服務以獲取更新的屬性，
還有另一種使用執行器端點/重繪的方式，但是我們將不得不為每個模塊單獨呼叫這個 url，例如，如果 Employee Producer1 部署在埠 8080 上，則呼叫 http：// localhost：8080 / refresh，同樣對于 Employee Producer2 http：//localhost：8081 / refresh 等等，這又很麻煩，這就是 Spring Cloud Bus 發揮作用的地方，
Spring Cloud Bus 提供了跨多個實體重繪配置的功能，因此，在上面的示例中，如果我們重繪 Employee Producer1，則會自動重繪所有其他必需的模塊，如果我們有多個微服務啟動并運行，這特別有用，這是通過將所有微服務連接到單個訊息代理來實作的，無論何時重繪實體，此事件都會訂閱到偵聽此代理的所有微服務，并且它們也會重繪，可以通過使用端點/總線/重繪來實作對任何單個實體的重繪，
Spring Cloud斷路器的作用
當一個服務呼叫另一個服務由于網路原因或自身原因出現問題，呼叫者就會等待被呼叫者的回應 當更多的服務請求到這些資源導致更多的請求等待，發生連鎖效應（雪崩效應）
斷路器有完全打開狀態:一段時間內 達到一定的次數無法呼叫 并且多次監測沒有恢復的跡象 斷路器完全打開 那么下次請求就不會請求到該服務
半開:短時間內 有恢復跡象 斷路器會將部分請求發給該服務，正常呼叫時 斷路器關閉
關閉：當服務一直處于正常狀態 能正常呼叫
什么是Spring Cloud Config?
在分布式系統中，由于服務數量巨多，為了方便服務組態檔統一管理，實時更新，所以需要分布式配置中心組件，在Spring Cloud中，有分布式配置中心組件spring cloud config ，它支持配置服務放在配置服務的記憶體中（即本地），也支持放在遠程Git倉庫中，在spring cloud config 組件中，分兩個角色，一是config server，二是config client，
使用：
（1）添加pom依賴
（2）組態檔添加相關配置
（3）啟動類添加注解@EnableConfigServer
什么是Spring Cloud Gateway?
Spring Cloud Gateway是Spring Cloud官方推出的第二代網關框架，取代Zuul網關，網關作為流量的，在微服務系統中有著非常作用，網關常見的功能有路由轉發、權限校驗、限流控制等作用，
使用了一個RouteLocatorBuilder的bean去創建路由，除了創建路由RouteLocatorBuilder可以讓你添加各種predicates和filters，predicates斷言的意思，顧名思義就是根據具體的請求的規則，由具體的route去處理，filters是各種過濾器，用來對請求做各種判斷和修改，
寫在最后
歡迎大家關注我的公眾號【風平浪靜如碼】，海量Java相關文章，學習資料都會在里面更新，整理的資料也會放在里面，
覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/287545.html
標籤：其他