SpringCloud面試題（總結最全面的面試題！！！）

什麼是微服務架構

• 微服務架構就是將單體的應用程序分成多個應用程序，這多個應用程序就成爲微服務，每個微服務運行在自己的進程中，並使用輕量級的機制通信。這些服務圍繞業務能力來劃分，並通過自動化部署機制來獨立部署。這些服務可以使用不同的編程語言，不同數據庫，以保證最低限度的集中式管理。

爲什麼需要學習Spring Cloud

• 首先springcloud基於spingboot的優雅簡潔，可還記得我們被無數xml支配的恐懼？可還記得springmvc，mybatis錯綜複雜的配置，有了spingboot，這些東西都不需要了，spingboot好處不再贅訴，springcloud就基於SpringBoot把市場上優秀的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理

• 什麼叫做開箱即用？即使是當年的黃金搭檔dubbo+zookeeper下載配置起來也是頗費心神的！而springcloud完成這些只需要一個jar的依賴就可以了！

• springcloud大多數子模塊都是直擊痛點，像zuul解決的跨域，fegin解決的負載均衡，hystrix的熔斷機制等等等等

Spring Cloud 是什麼

• Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、智能路由、消息總線、負載均衡、斷路器、數據監控等，都可以用Spring Boot的開發風格做到一鍵啓動和部署。
• Spring Cloud並沒有重複製造輪子，它只是將各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

SpringCloud的優缺點

優點：

  1.耦合度比較低。不會影響其他模塊的開發。

  2.減輕團隊的成本，可以並行開發，不用關注其他人怎麼開發，先關注自己的開發。

  3.配置比較簡單，基本用註解就能實現，不用使用過多的配置文件。

  4.微服務跨平臺的，可以用任何一種語言開發。

  5.每個微服務可以有自己的獨立的數據庫也有用公共的數據庫。

  6.直接寫後端的代碼，不用關注前端怎麼開發，直接寫自己的後端代碼即可，然後暴露接口，通過組件進行服務通信。

缺點：

 1.部署比較麻煩，給運維工程師帶來一定的麻煩。

 2.針對數據的管理比麻煩，因爲微服務可以每個微服務使用一個數據庫。

 3.系統集成測試比較麻煩

 4.性能的監控比較麻煩。【最好開發一個大屏監控系統】

• 總的來說優點大過於缺點，目前看來Spring Cloud是一套非常完善的分佈式框架，目前很多企業開始用微服務、Spring Cloud的優勢是顯而易見的。因此對於想研究微服務架構的同學來說，學習Spring Cloud是一個不錯的選擇。

SpringBoot和SpringCloud的區別？

• SpringBoot專注於快速方便的開發單個個體微服務。

• SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，

• 爲各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務

• SpringBoot可以離開SpringCloud獨立使用開發項目， 但是SpringCloud離不開SpringBoot ，屬於依賴的關係

• SpringBoot專注於快速、方便的開發單個微服務個體，SpringCloud關注全局的服務治理框架。

Spring Cloud和SpringBoot版本對應關係

Spring Cloud Version	SpringBoot Version
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

SpringCloud由什麼組成

• 這就有很多了，我講幾個開發中最重要的
  • Spring Cloud Eureka：服務註冊與發現
  • Spring Cloud Zuul：服務網關
  • Spring Cloud Ribbon：客戶端負載均衡
  • Spring Cloud Feign：聲明性的Web服務客戶端
  • Spring Cloud Hystrix：斷路器
  • Spring Cloud Config：分佈式統一配置管理
  • 等20幾個框架，開源一直在更新

使用 Spring Boot 開發分佈式微服務時，我們面臨什麼問題

• （1）與分佈式系統相關的複雜性-這種開銷包括網絡問題，延遲開銷，帶寬問題，安全問題。

• （2）服務發現-服務發現工具管理羣集中的流程和服務如何查找和互相交談。它涉及一個服務目錄，在該目錄中註冊服務，然後能夠查找並連接到該目錄中的服務。

• （3）冗餘-分佈式系統中的冗餘問題。

• （4）負載平衡 --負載平衡改善跨多個計算資源的工作負荷，諸如計算機，計算機集羣，網絡鏈路，中央處理單元，或磁盤驅動器的分佈。

• （5）性能-問題 由於各種運營開銷導致的性能問題。

Spring Cloud 和dubbo區別?

• （1）服務調用方式：dubbo是RPC springcloud Rest Api

• （2）註冊中心：dubbo 是zookeeper springcloud是eureka，也可以是zookeeper

• （3）服務網關，dubbo本身沒有實現，只能通過其他第三方技術整合，springcloud有Zuul路由網關，作爲路由服務器，進行消費者的請求分發,springcloud支持斷路器，與git完美集成配置文件支持版本控制，事物總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素。

Eureka

服務註冊和發現是什麼意思？Spring Cloud 如何實現？

• 當我們開始一個項目時，我們通常在屬性文件中進行所有的配置。隨着越來越多的服務開發和部署，添加和修改這些屬性變得更加複雜。有些服務可能會下降，而某些位置可能會發生變化。手動更改屬性可能會產生問題。 Eureka 服務註冊和發現可以在這種情況下提供幫助。由於所有服務都在 Eureka 服務器上註冊並通過調用 Eureka 服務器完成查找，因此無需處理服務地點的任何更改和處理。

什麼是Eureka

• Eureka作爲SpringCloud的服務註冊功能服務器，他是服務註冊中心，系統中的其他服務使用Eureka的客戶端將其連接到Eureka Service中，並且保持心跳，這樣工作人員可以通過Eureka Service來監控各個微服務是否運行正常。

Eureka怎麼實現高可用

• 集羣吧，註冊多臺Eureka，然後把SpringCloud服務互相註冊，客戶端從Eureka獲取信息時，按照Eureka的順序來訪問。

什麼是Eureka的自我保護模式，

• 默認情況下，如果Eureka Service在一定時間內沒有接收到某個微服務的心跳，Eureka Service會進入自我保護模式，在該模式下Eureka Service會保護服務註冊表中的信息，不在刪除註冊表中的數據，當網絡故障恢復後，Eureka Servic 節點會自動退出自我保護模式

DiscoveryClient的作用

• 可以從註冊中心中根據服務別名獲取註冊的服務器信息。

Eureka和ZooKeeper都可以提供服務註冊與發現的功能,請說說兩個的區別

1. ZooKeeper中的節點服務掛了就要選舉
   在選舉期間註冊服務癱瘓,雖然服務最終會恢復,但是選舉期間不可用的，
   選舉就是改微服務做了集羣，必須有一臺主其他的都是從

2. Eureka各個節點是平等關係,服務器掛了沒關係，只要有一臺Eureka就可以保證服務可用，數據都是最新的。
   如果查詢到的數據並不是最新的，就是因爲Eureka的自我保護模式導致的

3. Eureka本質上是一個工程,而ZooKeeper只是一個進程

4. Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況,而不會像ZooKeeper 一樣使得整個註冊系統癱瘓

5. ZooKeeper保證的是CP，Eureka保證的是AP

   CAP：
   C：一致性>Consistency;
   取捨：(強一致性、單調一致性、會話一致性、最終一致性、弱一致性)
   A：可用性>Availability;
   P：分區容錯性>Partition tolerance;

Zuul

什麼是網關?

• 網關相當於一個網絡服務架構的入口，所有網絡請求必須通過網關轉發到具體的服務。

網關的作用是什麼

• 統一管理微服務請求，權限控制、負載均衡、路由轉發、監控、安全控制黑名單和白名單等

什麼是Spring Cloud Zuul（服務網關）

• Zuul是對SpringCloud提供的成熟對的路由方案，他會根據請求的路徑不同，網關會定位到指定的微服務，並代理請求到不同的微服務接口，他對外隱蔽了微服務的真正接口地址。
  三個重要概念：動態路由表，路由定位，反向代理：

  • 動態路由表：Zuul支持Eureka路由，手動配置路由，這倆種都支持自動更新
  • 路由定位：根據請求路徑，Zuul有自己的一套定位服務規則以及路由表達式匹配
  • 反向代理：客戶端請求到路由網關，網關受理之後，在對目標發送請求，拿到響應之後在 給客戶端

• 它可以和Eureka,Ribbon,Hystrix等組件配合使用，

• Zuul的應用場景：

  • 對外暴露，權限校驗，服務聚合，日誌審計等

網關與過濾器有什麼區別

• 網關是對所有服務的請求進行分析過濾，過濾器是對單個服務而言。

常用網關框架有那些？

• Nginx、Zuul、Gateway

Zuul與Nginx有什麼區別？

• Zuul是java語言實現的，主要爲java服務提供網關服務，尤其在微服務架構中可以更加靈活的對網關進行操作。Nginx是使用C語言實現，性能高於Zuul，但是實現自定義操作需要熟悉lua語言，對程序員要求較高，可以使用Nginx做Zuul集羣。

既然Nginx可以實現網關？爲什麼還需要使用Zuul框架

• Zuul是SpringCloud集成的網關，使用Java語言編寫，可以對SpringCloud架構提供更靈活的服務。

如何設計一套API接口

• 考慮到API接口的分類可以將API接口分爲開發API接口和內網API接口，內網API接口用於局域網，爲內部服務器提供服務。開放API接口用於對外部合作單位提供接口調用，需要遵循Oauth2.0權限認證協議。同時還需要考慮安全性、冪等性等問題。

ZuulFilter常用有那些方法

• Run()：過濾器的具體業務邏輯

• shouldFilter()：判斷過濾器是否有效

• filterOrder()：過濾器執行順序

• filterType()：過濾器攔截位置

如何實現動態Zuul網關路由轉發

• 通過path配置攔截請求，通過ServiceId到配置中心獲取轉發的服務列表，Zuul內部使用Ribbon實現本地負載均衡和轉發。

Zuul網關如何搭建集羣

• 使用Nginx的upstream設置Zuul服務集羣，通過location攔截請求並轉發到upstream，默認使用輪詢機制對Zuul集羣發送請求。

Ribbon

負載平衡的意義什麼？

• 簡單來說： 先將集羣，集羣就是把一個的事情交給多個人去做，假如要做1000個產品給一個人做要10天，我叫10個人做就是一天，這就是集羣，負載均衡的話就是用來控制集羣，他把做的最多的人讓他慢慢做休息會，把做的最少的人讓他加量讓他做多點。

• 在計算中，負載平衡可以改善跨計算機，計算機集羣，網絡鏈接，中央處理單元或磁盤驅動器等多種計算資源的工作負載分佈。負載平衡旨在優化資源使用，最大化吞吐量，最小化響應時間並避免任何單一資源的過載。使用多個組件進行負載平衡而不是單個組件可能會通過冗餘來提高可靠性和可用性。負載平衡通常涉及專用軟件或硬件，例如多層交換機或域名系統服務器進程。

Ribbon是什麼？

• Ribbon是Netflix發佈的開源項目，主要功能是提供客戶端的軟件負載均衡算法

• Ribbon客戶端組件提供一系列完善的配置項，如連接超時，重試等。簡單的說，就是在配置文件中列出後面所有的機器，Ribbon會自動的幫助你基於某種規則（如簡單輪詢，隨即連接等）去連接這些機器。我們也很容易使用Ribbon實現自定義的負載均衡算法。（有點類似Nginx）

Nginx與Ribbon的區別

• Nginx是反向代理同時可以實現負載均衡，nginx攔截客戶端請求採用負載均衡策略根據upstream配置進行轉發，相當於請求通過nginx服務器進行轉發。Ribbon是客戶端負載均衡，從註冊中心讀取目標服務器信息，然後客戶端採用輪詢策略對服務直接訪問，全程在客戶端操作。

Ribbon底層實現原理

• Ribbon使用discoveryClient從註冊中心讀取目標服務信息，對同一接口請求進行計數，使用%取餘算法獲取目標服務集羣索引，返回獲取到的目標服務信息。

@LoadBalanced註解的作用

​ 開啓客戶端負載均衡。

Hystrix

什麼是斷路器

• 當一個服務調用另一個服務由於網絡原因或自身原因出現問題，調用者就會等待被調用者的響應 當更多的服務請求到這些資源導致更多的請求等待，發生連鎖效應（雪崩效應）

• 斷路器有三種狀態

  • 打開狀態：一段時間內 達到一定的次數無法調用 並且多次監測沒有恢復的跡象 斷路器完全打開 那麼下次請求就不會請求到該服務
  • 半開狀態：短時間內 有恢復跡象 斷路器會將部分請求發給該服務，正常調用時 斷路器關閉
  • 關閉狀態：當服務一直處於正常狀態 能正常調用

什麼是 Hystrix？

• 在分佈式系統，我們一定會依賴各種服務，那麼這些個服務一定會出現失敗的情況，就會導致雪崩，Hystrix就是這樣的一個工具，防雪崩利器，它具有服務降級，服務熔斷，服務隔離，監控等一些防止雪崩的技術。

• Hystrix有四種防雪崩方式:

  • 服務降級：接口調用失敗就調用本地的方法返回一個空
  • 服務熔斷：接口調用失敗就會進入調用接口提前定義好的一個熔斷的方法，返回錯誤信息
  • 服務隔離：隔離服務之間相互影響
  • 服務監控：在服務發生調用時,會將每秒請求數、成功請求數等運行指標記錄下來。

談談服務雪崩效應

• 雪崩效應是在大型互聯網項目中，當某個服務發生宕機時，調用這個服務的其他服務也會發生宕機，大型項目的微服務之間的調用是互通的，這樣就會將服務的不可用逐步擴大到各個其他服務中，從而使整個項目的服務宕機崩潰.發生雪崩效應的原因有以下幾點

• 單個服務的代碼存在bug. 2請求訪問量激增導致服務發生崩潰(如大型商城的槍紅包，秒殺功能). 3.服務器的硬件故障也會導致部分服務不可用.

在微服務中，如何保護服務?

• 一般使用使用Hystrix框架，實現服務隔離來避免出現服務的雪崩效應，從而達到保護服務的效果。當微服務中，高併發的數據庫訪問量導致服務線程阻塞，使單個服務宕機，服務的不可用會蔓延到其他服務，引起整體服務災難性後果，使用服務降級能有效爲不同的服務分配資源,一旦服務不可用則返回友好提示，不佔用其他服務資源，從而避免單個服務崩潰引發整體服務的不可用.

服務雪崩效應產生的原因

• 因爲Tomcat默認情況下只有一個線程池來維護客戶端發送的所有的請求，這時候某一接口在某一時刻被大量訪問就會佔據tomcat線程池中的所有線程，其他請求處於等待狀態，無法連接到服務接口。

談談服務降級、熔斷、服務隔離

• 服務降級：當客戶端請求服務器端的時候，防止客戶端一直等待，不會處理業務邏輯代碼，直接返回一個友好的提示給客戶端。

• 服務熔斷是在服務降級的基礎上更直接的一種保護方式，當在一個統計時間範圍內的請求失敗數量達到設定值（requestVolumeThreshold）或當前的請求錯誤率達到設定的錯誤率閾值（errorThresholdPercentage）時開啓斷路，之後的請求直接走fallback方法，在設定時間（sleepWindowInMilliseconds）後嘗試恢復。

• 服務隔離就是Hystrix爲隔離的服務開啓一個獨立的線程池，這樣在高併發的情況下不會影響其他服務。服務隔離有線程池和信號量兩種實現方式，一般使用線程池方式。

服務降級底層是如何實現的？

• Hystrix實現服務降級的功能是通過重寫HystrixCommand中的getFallback()方法，當Hystrix的run方法或construct執行發生錯誤時轉而執行getFallback()方法。

Feign

什麼是Feign？

• Feign 是一個聲明web服務客戶端，這使得編寫web服務客戶端更容易

• 他將我們需要調用的服務方法定義成抽象方法保存在本地就可以了，不需要自己構建Http請求了，直接調用接口就行了，不過要注意，調用方法要和本地抽象方法的簽名完全一致。

SpringCloud有幾種調用接口方式

• Feign

• RestTemplate

Ribbon和Feign調用服務的區別

• 調用方式同：Ribbon需要我們自己構建Http請求，模擬Http請求然後通過RestTemplate發給其他服務，步驟相當繁瑣

• 而Feign則是在Ribbon的基礎上進行了一次改進，採用接口的形式，將我們需要調用的服務方法定義成抽象方法保存在本地就可以了，不需要自己構建Http請求了，直接調用接口就行了，不過要注意，調用方法要和本地抽象方法的簽名完全一致。

Bus

什麼是 Spring Cloud Bus？

• Spring Cloud Bus就像一個分佈式執行器，用於擴展的Spring Boot應用程序的配置文件，但也可以用作應用程序之間的通信通道。
• Spring Cloud Bus 不能單獨完成通信，需要配合MQ支持
• Spring Cloud Bus一般是配合Spring Cloud Config做配置中心的
• Springcloud config實時刷新也必須採用SpringCloud Bus消息總線

Config

什麼是Spring Cloud Config?

• Spring Cloud Config爲分佈式系統中的外部配置提供服務器和客戶端支持，可以方便的對微服務各個環境下的配置進行集中式管理。Spring Cloud Config分爲Config Server和Config Client兩部分。Config Server負責讀取配置文件，並且暴露Http API接口，Config Client通過調用Config Server的接口來讀取配置文件。

分佈式配置中心有那些框架？

• Apollo、zookeeper、springcloud config。

分佈式配置中心的作用？

• 動態變更項目配置信息而不必重新部署項目。

SpringCloud Config 可以實現實時刷新嗎？

• springcloud config實時刷新採用SpringCloud Bus消息總線。

Gateway

什麼是Spring Cloud Gateway?

• Spring Cloud Gateway是Spring Cloud官方推出的第二代網關框架，取代Zuul網關。網關作爲流量的，在微服務系統中有着非常作用，網關常見的功能有路由轉發、權限校驗、限流控制等作用。

• 使用了一個RouteLocatorBuilder的bean去創建路由，除了創建路由RouteLocatorBuilder可以讓你添加各種predicates和filters，predicates斷言的意思，顧名思義就是根據具體的請求的規則，由具體的route去處理，filters是各種過濾器，用來對請求做各種判斷和修改。

SpringCloud主要項目

• Spring Cloud的子項目，大致可分成兩類，一類是對現有成熟框架"Spring Boot化"的封裝和抽象，也是數量最多的項目；第二類是開發了一部分分佈式系統的基礎設施的實現，如Spring Cloud Stream扮演的就是kafka, ActiveMQ這樣的角色。

Spring Cloud Config

• Config能夠管理所有微服務的配置文件

• 集中配置管理工具，分佈式系統中統一的外部配置管理，默認使用Git來存儲配置，可以支持客戶端配置的刷新及加密、解密操作。

Spring Cloud Netflix(重點，這些組件用的最多)

• Netflix OSS 開源組件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心組件。
  • Eureka：服務治理組件，包括服務端的註冊中心和客戶端的服務發現機制；
  • Ribbon：負載均衡的服務調用組件，具有多種負載均衡調用策略；
  • Hystrix：服務容錯組件，實現了斷路器模式，爲依賴服務的出錯和延遲提供了容錯能力；
  • Feign：基於Ribbon和Hystrix的聲明式服務調用組件；
  • Zuul：API網關組件，對請求提供路由及過濾功能。

我覺得SpringCloud的福音是Netflix，他把人家的組件都搬來進行封裝了，使開發者能快速簡單安全的使用

Spring Cloud Bus

• 用於傳播集羣狀態變化的消息總線，使用輕量級消息代理鏈接分佈式系統中的節點，可以用來動態刷新集羣中的服務配置信息。
• 簡單來說就是修改了配置文件，發送一次請求，所有客戶端便會重新讀取配置文件。
  • 需要利用中間插件MQ

Spring Cloud Consul

• Consul 是 HashiCorp 公司推出的開源工具，用於實現分佈式系統的服務發現與配置。與其它分佈式服務註冊與發現的方案，Consul 的方案更“一站式”，內置了服務註冊與發現框架、分佈一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，不再需要依賴其它工具（比如 ZooKeeper 等）。使用起來也較爲簡單。Consul 使用 Go 語言編寫，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安裝包僅包含一個可執行文件，方便部署，與 Docker 等輕量級容器可無縫配合。

Spring Cloud Security

• 安全工具包，他可以對

  • 對Zuul代理中的負載均衡從前端到後端服務中獲取SSO令牌
  • 資源服務器之間的中繼令牌
  • 使Feign客戶端表現得像OAuth2RestTemplate（獲取令牌等）的攔截器
  • 在Zuul代理中配置下游身份驗證

• Spring Cloud Security提供了一組原語，用於構建安全的應用程序和服務，而且操作簡便。可以在外部（或集中）進行大量配置的聲明性模型有助於實現大型協作的遠程組件系統，通常具有中央身份管理服務。它也非常易於在Cloud Foundry等服務平臺中使用。在Spring Boot和Spring Security OAuth2的基礎上，可以快速創建實現常見模式的系統，如單點登錄，令牌中繼和令牌交換。

Spring Cloud Sleuth

• 在微服務中，通常根據業務模塊分服務，項目中前端發起一個請求，後端可能跨幾個服務調用才能完成這個請求（如下圖）。如果系統越來越龐大，服務之間的調用與被調用關係就會變得很複雜，假如一個請求中需要跨幾個服務調用，其中一個服務由於網絡延遲等原因掛掉了，那麼這時候我們需要分析具體哪一個服務出問題了就會顯得很困難。Spring Cloud Sleuth服務鏈路跟蹤功能就可以幫助我們快速的發現錯誤根源以及監控分析每條請求鏈路上的性能等等。
  

Spring Cloud Stream

• 輕量級事件驅動微服務框架，可以使用簡單的聲明式模型來發送及接收消息，主要實現爲Apache Kafka及RabbitMQ。

Spring Cloud Task

• Spring Cloud Task的目標是爲Spring Boot應用程序提供創建短運行期微服務的功能。在Spring Cloud Task中，我們可以靈活地動態運行任何任務，按需分配資源並在任務完成後檢索結果。Tasks是Spring Cloud Data Flow中的一個基礎項目，允許用戶將幾乎任何Spring Boot應用程序作爲一個短期任務執行。

Spring Cloud Zookeeper

• SpringCloud支持三種註冊方式Eureka， Consul(go語言編寫)，zookeeper

• Spring Cloud Zookeeper是基於Apache Zookeeper的服務治理組件。

Spring Cloud Gateway

• Spring cloud gateway是spring官方基於Spring 5.0、Spring Boot2.0和Project Reactor等技術開發的網關，Spring Cloud Gateway旨在爲微服務架構提供簡單、有效和統一的API路由管理方式，Spring Cloud Gateway作爲Spring Cloud生態系統中的網關，目標是替代Netflix Zuul，其不僅提供統一的路由方式，並且還基於Filer鏈的方式提供了網關基本的功能，例如：安全、監控/埋點、限流等。

Spring Cloud OpenFeign

• Feign是一個聲明性的Web服務客戶端。它使編寫Web服務客戶端變得更容易。要使用Feign，我們可以將調用的服務方法定義成抽象方法保存在本地添加一點點註解就可以了，不需要自己構建Http請求了，直接調用接口就行了，不過要注意，調用方法要和本地抽象方法的簽名完全一致。

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 Version	SpringBoot Version
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

Spring Cloud和各子項目版本對應關係

• Edgware.SR6：我理解爲最低版本號

• Greenwich.SR2 :我理解爲最高版本號

• Greenwich.BUILD-SNAPSHOT（快照）：是一種特殊的版本，指定了某個當前的開發進度的副本。不同於常規的版本，幾乎每天都要提交更新的版本，如果每次提交都申明一個版本號那不是版本號都不夠用？

Component	Edgware.SR6	Greenwich.SR2	Greenwich.BUILD-SNAPSHOT
spring-cloud-aws	1.2.4.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-bus	1.3.4.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-cli	1.4.1.RELEASE	2.0.0.RELEASE	2.0.1.BUILD-SNAPSHOT
spring-cloud-commons	1.3.6.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-contract	1.2.7.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-config	1.4.7.RELEASE	2.1.3.RELEASE	2.1.4.BUILD-SNAPSHOT
spring-cloud-netflix	1.4.7.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-security	1.2.4.RELEASE	2.1.3.RELEASE	2.1.4.BUILD-SNAPSHOT
spring-cloud-cloudfoundry	1.1.3.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-consul	1.3.6.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-sleuth	1.3.6.RELEASE	2.1.1.RELEASE	2.1.2.BUILD-SNAPSHOT
spring-cloud-stream	Ditmars.SR5	Fishtown.SR3	Fishtown.BUILD-SNAPSHOT
spring-cloud-zookeeper	1.2.3.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-boot	1.5.21.RELEASE	2.1.5.RELEASE	2.1.8.BUILD-SNAPSHOT
spring-cloud-task	1.2.4.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-vault	1.1.3.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-gateway	1.0.3.RELEASE	2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-openfeign		2.1.2.RELEASE	2.1.3.BUILD-SNAPSHOT
spring-cloud-function	1.0.2.RELEASE	2.0.2.RELEASE	2.0.3.BUILD-SNAPSHOT