# 什么是微服務架構 * 微服務架構就是將單體的應用程序分成多個應用程序，這多個應用程序就成為微服務，每個微服務運行在自己的進程中，并使用輕量級的機制通信。這些服務圍繞業務能力來劃分，并通過自動化部署機制來獨立部署。這些服務可以使用不同的編程語言，不同數據庫，以保證最低限度的集中式管理。 ## 為什么需要學習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 | 、