軟件是有生命的，你做出來的架構決定了這個軟件它這一生是坎坷還是幸福。
本文不是講解如何使用Spring Cloud的教程，而是探討Spring Cloud是什麼，以及它誕生的背景和意義。
原文鏈接：：https://www.jianshu.com/p/3899d7f47303
一、背景
2008年以後，國內互聯網行業飛速發展，我們對軟件系統的需求已經不再是過去”能用就行”這種很low的檔次了，像搶紅包、雙十一這樣的活動不斷逼迫我們去突破軟件系統的性能上限，傳統的IT企業”能用就行”的開發思想已經不能滿足互聯網高併發、大流量的性能要求。系統架構走向分佈式已經是服務器開發領域解決該問題唯一的出路，然而分佈式系統由於天生的複雜度，並不像開發單體應用一樣把框架一堆就能搞定，因此各大互聯網公司都在投入技術力量研發自己的基礎設施。這裡面比較有名的如阿里的開源項目dubbo, Netflix開發的一系列服務框架。在這種“百花齊放”、重複造輪子的狀況下，必然要出現一種統一的標準來簡化分佈式系統的開發，
Spring Cloud應運而生。二、Spring Cloud是什麼
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署。Spring並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。Spring Cloud正是對Netflix的多個開源組件進一步的封裝而成，同時又實現了和雲端平臺，和Spring Boot開發框架很好的集成。Spring Cloud是一個相對比較新的微服務框架，2016年才推出1.0的release版本. 雖然Spring Cloud時間最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分佈式系統解決方案。Spring Cloud 為開發者提供了在分佈式系統（
配置管理，服務發現，熔斷，路由，微代理，控制總線，一次性token，全居瑣，leader選舉，分佈式session，集群狀態）中快速構建的工具，使用Spring Cloud的開發者可以快速的啟動服務或構建應用、同時能夠快速和雲平臺資源進行對接。
從上圖可以看出Spring Cloud各個組件相互配合，合作支持了一套完整的微服務架構。
- 其中Eureka負責服務的註冊與發現，很好將各服務連接起來
- Hystrix 負責監控服務之間的調用情況，連續多次失敗進行熔斷保護。
- Hystrix dashboard,Turbine 負責監控 Hystrix的熔斷情況，並給予圖形化的展示
- Spring Cloud Config 提供了統一的配置中心服務
- 當配置文件發生變化的時候，Spring Cloud Bus 負責通知各服務去獲取最新的配置信息
- 所有對外的請求和服務，我們都通過Zuul來進行轉發，起到API網關的作用
- 最後我們使用Sleuth+Zipkin將所有的請求數據記錄下來，方便我們進行後續分析
Spring Cloud從設計之初就考慮了絕大多數互聯網公司架構演化所需的功能，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等。這些功能都是以插拔的形式提供出來，方便我們系統架構演進的過程中，可以合理的選擇需要的組件進行集成，從而在架構演進的過程中會更加平滑、順利。
微服務架構是一種趨勢，Spring Cloud提供了標準化的、全站式的技術方案，意義可能會堪比當前Servlet規範的誕生，有效推進服務端軟件系統技術水平的進步。
三、Spring Cloud組成
Spring Cloud的子項目，大致可分成兩類，一類是對現有成熟框架”Spring Boot化”的封裝和抽象，也是數量最多的項目；第二類是開發了一部分分佈式系統的基礎設施的實現，如Spring Cloud Stream扮演的就是kafka, ActiveMQ這樣的角色。對於我們想快速實踐微服務的開發者來說，第一類子項目就已經足夠使用，如：Spring Cloud Netflix，是對Netflix開發的一套分佈式服務框架的封裝，包括服務的發現和註冊，負載均衡、斷路器、REST客戶端、請求路由等。該項目是Spring Cloud的子項目之一，主要內容是對Netflix公司一系列開源產品的包裝，它為Spring Boot應用提供了自配置的Netflix OSS整合。通過一些簡單的註解，開發者就可以快速的在應用中配置一下常用模塊並構建龐大的分佈式系統。它主要提供的模塊包括：服務發現（Eureka），斷路器（Hystrix），智能路由（Zuul），客戶端負載均衡（Ribbon）等。
Spring Cloud Netflix 這可是個大boss，地位僅次於老大，老大各項服務依賴與它，與各種Netflix OSS組件集成，組成微服務的核心，它的小弟主要有Eureka, Hystrix, Zuul, Archaius... 太多了
3.1、Spring Cloud Eureka 服務發現
服務中心，雲端服務發現，一個基於 REST 的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。這個可是SpringCloud最牛鼻的小弟，服務中心，任何小弟需要其它小弟支持什麼都需要從這裡來拿，同樣的你有什麼獨門武功的都趕緊過報道，方便以後其它小弟來調用；它的好處是你不需要直接找各種什麼小弟支持，只需要到服務中心來領取，也不需要知道提供支持的其它小弟在哪裡，還是幾個小弟來支持的，反正拿來用就行，服務中心來保證穩定性和質量。Spring Cloud
Eureka提供在分佈式環境下的服務發現，服務註冊的功能。一個RESTful服務，用來定位運行在AWS地區（Region）中的中間層服務。由兩個組件組成：Eureka服務器和Eureka客戶端。Eureka服務器用作服務註冊服務器。Eureka客戶端是一個java客戶端，用來簡化與服務器的交互、作為輪詢負載均衡器，並提供服務的故障切換支持。Netflix在其生產環境中使用的是另外的客戶端，它提供基於流量、資源利用率以及出錯狀態的加權負載均衡。3.2、Spring Cloud Ribbon 客戶端負載均衡
Ribbon，主要提供客戶側的軟件負載均衡算法。Ribbon客戶端組件提供一系列完善的配置選項，比如連接超時、重試、重試算法等。Ribbon內置可插拔、可定製的負載均衡組件。下面是用到的一些負載均衡策略：
- 簡單輪詢負載均衡
- 加權響應時間負載均衡
- 區域感知輪詢負載均衡
- 隨機負載均衡
Ribbon中還包括以下功能：
- 易於與服務發現組件（比如Netflix的Eureka）集成
- 使用Archaius完成運行時配置
- 使用JMX暴露運維指標，使用Servo發佈
- 多種可插拔的序列化選擇
- 異步和批處理操作（即將推出）
- 自動SLA框架（即將推出）
- 系統管理/指標控制檯（即將推出）
ribbon架構示例
- 一個服務註冊中心，eureka server,端口為8761
- service-hi工程跑了兩個實例，端口分別為8762,8763，分別向服務註冊中心註冊
- sercvice-ribbon端口為8764,向服務註冊中心註冊
- 當sercvice-ribbon通過restTemplate調用service-hi的hi接口時，因為用ribbon進行了負載均衡，會輪流的調用service-hi：8762和8763 兩個端口的hi接口；
3.3、Spring Cloud Config
俗稱的配置中心，配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集群配置，目前支持本地存儲、Git以及Subversion。就是以後大家武器、槍火什麼的東西都集中放到一起，別隨便自己帶，方便以後統一管理、升級裝備。
將配置信息中央化保存, 配置Spring Cloud Bus可以實現動態修改配置文件。這個還是靜態的，得配合Spring Cloud Bus實現動態的配置更新。
Spring Cloud Config就是我們通常意義上的配置中心。Spring Cloud Config-把應用原本放在本地文件的配置抽取出來放在中心服務器，本質是配置信息從本地遷移到雲端。從而能夠提供更好的管理、發佈能力。Spring Cloud Config分服務端和客戶端，服務端負責將git（svn）中存儲的配置文件發佈成REST接口，客戶端可以從服務端REST接口獲取配置。但客戶端並不能主動感知到配置的變化，從而主動去獲取新的配置，這需要每個客戶端通過POST方法觸發各自的/refresh。
3.4、Spring cloud Hystrix 熔斷器
熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。比如突然某個小弟生病了，但是你還需要它的支持，然後調用之後它半天沒有響應，你卻不知道，一直在等等這個響應；有可能別的小弟也正在調用你的武功絕技，那麼當請求多之後，就會發生嚴重的阻塞影響老大的整體計劃。這個時候Hystrix就派上用場了，
當Hystrix發現某個小弟不在狀態不穩定立馬馬上讓它下線，讓其它小弟來頂上來，或者給你說不用等了這個小弟今天肯定不行，該幹嘛趕緊幹嘛去別在這排隊了。
斷路器(Cricuit Breaker)是一種能夠在遠程服務不可用時自動熔斷(打開開關)，並在遠程服務恢復時自動恢復(閉合開關)的設施，Spring Cloud通過Netflix的Hystrix組件提供斷路器、資源隔離與自我修復功能。
斷路器可以防止一個應用程序多次試圖執行一個操作，即很可能失敗，允許它繼續而不等待故障恢復或者浪費 CPU 週期，而它確定該故障是持久的。斷路器模式也使應用程序能夠檢測故障是否已經解決。如果問題似乎已經得到糾正，應用程序可以嘗試調用操作。
斷路器增加了穩定性和靈活性，以一個系統，提供穩定性，而系統從故障中恢復，並儘量減少此故障的對性能的影響。它可以幫助快速地拒絕對一個操作，即很可能失敗，而不是等待操作超時（或者不返回）的請求，以保持系統的響應時間。如果斷路器提高每次改變狀態的時間的事件，該信息可以被用來監測由斷路器保護系統的部件的健康狀況，或以提醒管理員當斷路器跳閘，以在打開狀態。
Netflix開源了Hystrix組件，實現了斷路器模式，SpringCloud對這一組件進行了整合。 在微服務架構中，一個請求需要調用多個服務是非常常見的，如下圖：
較底層的服務如果出現故障，會導致連鎖故障。當對特定的服務的調用的不可用達到一個閥值（Hystric 是5秒20次） 斷路器將會被打開。
斷路打開後，可用避免連鎖故障，fallback方法可以直接返回一個固定值。
在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,並將不可用逐漸放大的過程。
如下圖所示：A作為服務提供者，B為A的服務消費者，C和D是B的服務消費者。A不可用引起了B的不可用，並將不可用像滾雪球一樣放大到C和D時，雪崩效應就形成了。
在這種情況下就需要整個服務機構具有故障隔離的功能，避免某一個服務掛掉影響全局。在Spring Cloud 中Hystrix組件就扮演這個角色。Hystrix會在某個服務連續調用N次不響應的情況下，立即通知調用端調用失敗，避免調用端持續等待而影響了整體服務。Hystrix間隔時間會再次檢查此服務，如果服務恢復將繼續提供服務。
Hystrix Dashboard和Turbine當熔斷髮生的時候需要迅速的響應來解決問題，避免故障進一步擴散，那麼對熔斷的監控就變得非常重要。熔斷的監控現在有兩款工具：Hystrix-dashboard和Turbine
Hystrix-dashboard是一款針對Hystrix進行實時監控的工具，通過Hystrix Dashboard我們可以直觀地看到各Hystrix Command的請求響應時間, 請求成功率等數據。但是隻使用Hystrix Dashboard的話, 你只能看到單個應用內的服務信息, 這明顯不夠. 我們需要一個工具能讓我們彙總系統內多個服務的數據並顯示到Hystrix Dashboard上, 這個工具就是Turbine. 監控的效果圖如下：
3.5、Spring Cloud Zuul 服務網關，智能路由
在微服務架構模式下，後端服務的實例數一般是動態的，對於客戶端而言很難發現動態改變的服務實例的訪問地址信息。因此在基於微服務的項目中為了簡化前端的調用邏輯，通常會引入API Gateway作為輕量級網關，同時API Gateway中也會實現相關的認證邏輯從而簡化內部服務之間相互調用的複雜度。
Spring Cloud體系中支持API Gateway落地的技術就是Zuul。Spring Cloud Zuul路由是微服務架構中不可或缺的一部分，提供動態路由，監控，彈性，安全等的邊緣服務。Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器。
它的具體作用就是服務轉發，接收並轉發所有內外部的客戶端調用。使用Zuul可以作為資源的統一訪問入口，同時也可以在網關做一些權限校驗等類似的功能 。
Zuul 是在雲平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架。Zuul 相當於是設備和 Netflix 流應用的 Web 網站後端所有請求的前門。當其它門派來找大哥辦事的時候一定要先經過zuul,看下有沒有帶刀子什麼的給攔截回去，或者是需要找那個小弟的直接給帶過去。
類似Nginx，反向代理的功能，不過netflix自己增加了一些配合其他組件的特性。
3.6、Spring Netflix Archaius
配置管理API，包含一系列配置管理API，提供動態類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。可以實現動態獲取配置，原理是每隔60s（默認，可配置）從配置源讀取一次內容 ，這樣修改了配置文件後不需要重啟服務就可以使修改後的內容生效，前提使用archaius的API來讀取。
3.7、Spring Cloud Bus
事件、消息總線，用於在集群（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。相當於水滸傳中日行八百里的神行太保戴宗，確保各個小弟之間消息保持暢通。
分佈式消息隊列，是對Kafka, MQ的封裝；事件、消息總線，用於在集群（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。Spring cloud bus通過輕量消息代理連接各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其他的消息指令。Spring bus的一個核心思想是通過分佈式的啟動器對spring boot應用進行擴展，也可以用來建立一個多個應用之間的通信頻道。目前唯一實現的方式是用AMQP消息代理作為通道，同樣特性的設置（有些取決於通道的設置）在更多通道的文檔中。Spring cloud bus被國內很多都翻譯為消息總線，也挺形象的。大家可以將它理解為管理和傳播所有分佈式項目中的消息既可，其實本質是利用了MQ的廣播機制在分佈式的系統中傳播消息，目前常用的有Kafka和RabbitMQ。利用bus的機制可以做很多的事情，其中配置中心客戶端刷新就是典型的應用場景之一，我們用一張圖來描述bus在配置中心使用的機制。
根據此圖我們可以看出利用Spring Cloud Bus做配置更新的步驟:
- 提交代碼觸發post給客戶端A發送bus/refresh
- 客戶端A接收到請求從Server端更新配置並且發送給Spring Cloud Bus
- Spring Cloud bus接到消息並通知給其它客戶端
- 其它客戶端接收到通知，請求Server端獲取最新配置
- 全部客戶端均獲取到最新的配置
3.8 Spring Cloud Security
對Spring Security的封裝，並能配合Netflix使用，安全工具包，為你的應用程序添加安全控制，主要是指OAuth2。基於spring security的安全工具包，為你的應用程序添加安全控制。這個小弟很牛鼻專門負責整個幫派的安全問題，設置不同的門派訪問特定的資源，不能把秘籍葵花寶典洩漏了。
3.9、Spring Cloud Zookeeper
對Zookeeper的封裝，使之能配置其它Spring Cloud的子項目使用；操作Zookeeper的工具包，用於使用zookeeper方式的服務註冊和發現。ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等。ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。操作Zookeeper的工具包，用於使用zookeeper方式的服務發現和配置管理，抱了Zookeeper的大腿。
3.10、Spring Cloud Stream
數據流；數據流操作開發包，封裝了與Redis,Rabbit、Kafka等發送接收消息。Spring Cloud Stream是創建消息驅動微服務應用的框架。Spring Cloud Stream是基於spring boot創建，用來建立單獨的／工業級spring應用，使用spring integration提供與消息代理之間的連接。數據流操作開發包，封裝了與Redis,Rabbit、Kafka等發送接收消息。一個業務會牽扯到多個任務，任務之間是通過事件觸發的，這就是Spring Cloud stream要乾的事了。
3.11、Spring Cloud Sleuth
隨著服務的越來越多，對調用鏈的分析會越來越複雜，如服務之間的調用關係、某個請求對應的調用鏈、調用之間消費的時間等，對這些信息進行監控就成為一個問題。在實際的使用中我們需要監控服務和服務之間通訊的各項指標，這些數據將是我們改進系統架構的主要依據。因此分佈式的鏈路跟蹤就變的非常重要，Spring Cloud也給出了具體的解決方案：Spring Cloud Sleuth和Zipkin。
服務跟蹤；日誌收集工具包，封裝了Dapper,Zipkin和HTrace操作。日誌收集工具包，封裝了Dapper和log-based追蹤以及Zipkin和HTrace操作，為SpringCloud應用實現了一種分佈式追蹤解決方案。
簡介
Spring Cloud Sleuth 主要功能就是在分佈式系統中提供追蹤解決方案，並且兼容支持了 zipkin，你只需要在pom文件中引入相應的依賴即可。
服務追蹤分析
微服務架構上通過業務來劃分服務的，通過REST調用，對外暴露的一個接口，
可能需要很多個服務協同才能完成這個接口功能，如果鏈路上任何一個服務出現問題或者網絡超時，都會形成導致接口調用失敗。隨著業務的不斷擴張，服務之間互相調用會越來越複雜。
隨著服務的越來越多，對調用鏈的分析會越來越複雜。它們之間的調用關係也許如下：
術語
- Span：基本工作單元，例如，在一個新建的span中發送一個RPC等同於發送一個回應請求給RPC，span通過一個64位ID唯一標識，trace以另一個64位ID表示，span還有其他數據信息，比如摘要、時間戳事件、關鍵值註釋(tags)、span的ID、以及進度ID(通常是IP地址)
span在不斷的啟動和停止，同時記錄了時間信息，當你創建了一個span，你必須在未來的某個時刻停止它。 - Trace：一系列spans組成的一個樹狀結構，例如，如果你正在跑一個分佈式大數據工程，你可能需要創建一個trace。
- Annotation：用來及時記錄一個事件的存在，一些核心annotations用來定義一個請求的開始和結束
cs - Client Sent -客戶端發起一個請求，這個annotion描述了這個span的開始
sr - Server Received -服務端獲得請求並準備開始處理它，如果將其sr減去cs時間戳便可得到網絡延遲
ss - Server Sent -註解表明請求處理的完成(當請求返回客戶端)，如果ss減去sr時間戳便可得到服務端需要的處理請求時間
cr - Client Received -表明span的結束，客戶端成功接收到服務端的回覆，如果cr減去cs時間戳便可得到客戶端從服務端獲取回覆的所有所需時間
將Span和Trace在一個系統中使用Zipkin註解的過程圖形化：
3.12、Spring Cloud Feign 使用HTTP請求遠程服務
在Spring Cloud Netflix棧中，各個微服務都是以HTTP接口的形式暴露自身服務的，因此在調用遠程服務時就必須使用HTTP客戶端。我們可以使用JDK原生的URLConnection、Apache的Http Client、Netty的異步HTTP Client, Spring的RestTemplate。但是，用起來最方便、最優雅的還是要屬Feign了。Feign是一種聲明式、模板化的HTTP客戶端。在Spring Cloud中使用Feign, 我們可以做到使用HTTP請求遠程服務時能與調用本地方法一樣的編碼體驗，開發者完全感知不到這是遠程方法，更感知不到這是個HTTP請求。通過Feign， 我們能把HTTP遠程調用對開發者完全透明，得到與調用本地方法一致的編碼體驗。這一點與阿里Dubbo中暴露遠程服務的方式類似，區別在於Dubbo是基於私有二進制協議，而Feign本質上還是個HTTP客戶端。如果是在用Spring Cloud Netflix搭建微服務，那麼Feign無疑是最佳選擇。
Feign是一個聲明式的偽Http客戶端，它使得寫Http客戶端變得更簡單。使用Feign，只需要創建一個接口並註解。它具有可插拔的註解特性，可使用Feign 註解和JAX-RS註解。Feign支持可插拔的編碼器和解碼器。Feign默認集成了Ribbon，並和Eureka結合，默認實現了負載均衡的效果。
簡而言之：
- Feign 採用的是基於接口的註解
- Feign 整合了ribbon
3.13、Spring Cloud for Cloud Foundry
Cloud Foundry是VMware推出的業界第一個開源PaaS雲平臺，它支持多種框架、語言、運行時環境、雲平臺及應用服務，使開發人員能夠在幾秒鐘內進行應用程序的部署和擴展，無需擔心任何基礎架構的問題其實就是與CloudFoundry進行集成的一套解決方案，抱了
Cloud Foundry的大腿。3.14、Spring Cloud Cluster
Spring Cloud Cluster將取代Spring Integration。提供在分佈式系統中的集群所需要的基礎功能支持，如：選舉、集群的狀態一致性、全局鎖、tokens等常見狀態模式的抽象和實現。如果把不同的幫派組織成統一的整體，Spring Cloud Cluster已經幫你提供了很多方便組織成統一的工具。
3.15、Spring Cloud Consul
Consul 是一個支持多數據中心分佈式高可用的服務發現和配置共享的服務軟件,由 HashiCorp 公司用 Go 語言開發, 基於 Mozilla Public License 2.0 的協議進行開源. Consul 支持健康檢查,並允許 HTTP 和 DNS 協議調用 API 存儲鍵值對.Spring Cloud Consul 封裝了Consul操作，consul是一個服務發現與配置工具，與Docker容器可以無縫集成。
3.16、Spring Cloud Data Flow
Data flow 是一個用於開發和執行大範圍數據處理其模式包括ETL，批量運算和持續運算的統一編程模型和託管服務。對於在現代運行環境中可組合的微服務程序來說，Spring Cloud data flow是一個原生雲可編配的服務。使用Spring Cloud data flow，開發者可以為像數據抽取，實時分析，和數據導入/導出這種常見用例創建和編配數據通道 （data pipelines）。Spring Cloud data flow 是基於原生雲對 spring XD的重新設計，該項目目標是簡化大數據應用的開發。Spring XD 的流處理和批處理模塊的重構分別是基於 spring boot的stream 和 task/batch 的微服務程序。這些程序現在都是自動部署單元而且他們原生的支持像 Cloud Foundry、Apache YARN、Apache Mesos和Kubernetes 等現代運行環境。Spring Cloud data flow 為基於微服務的分佈式流處理和批處理數據通道提供了一系列模型和最佳實踐。
3.17、Spring Cloud Task
Spring Cloud Task 主要解決短命微服務的任務管理，任務調度的工作，比如說某些定時任務晚上就跑一次，或者某項數據分析臨時就跑幾次。
3.18、Spring Cloud Connectors
Spring Cloud Connectors 簡化了連接到服務的過程和從雲平臺獲取操作的過程，有很強的擴展性，可以利用Spring Cloud Connectors來構建你自己的雲平臺。便於雲端應用程序在各種PaaS平臺連接到後端，如：數據庫和消息代理服務。
3.19、Spring Cloud Starters
Spring Boot式的啟動項目，為Spring Cloud提供開箱即用的依賴管理。
3.20、Spring Cloud CLI
基於 Spring Boot CLI，可以讓你以命令行方式快速建立雲組件。
3.21、Netflix Turbine
Turbine是聚合服務器發送事件流數據的一個工具，用來監控集群下hystrix的metrics情況。
四、和Spring Boot 是什麼關係
Spring boot 是 Spring 的一套快速配置腳手架，可以基於spring boot 快速開發單個微服務，Spring Cloud是一個基於Spring Boot實現的雲應用開發工具；Spring boot專注於快速、方便集成的單個個體，Spring Cloud是關注全局的服務治理框架；spring boot使用了默認大於配置的理念，很多集成方案已經幫你選擇好了，能不配置就不配置，Spring Cloud很大的一部分是基於Spring boot來實現,可以不基於Spring boot嗎？不可以。Spring boot可以離開Spring Cloud獨立使用開發項目，但是Spring Cloud離不開Spring boot，屬於依賴的關係。
Spring -> Spring Boot > Spring Cloud 這樣的關係。
五、Spring Cloud的優勢
微服務的框架那麼多比如：dubbo、Kubernetes，為什麼就要使用Spring Cloud的呢？
- 產出於Spring大家族，Spring在企業級開發框架中無人能敵，來頭很大，可以保證後續的更新、完善。比如dubbo現在就差不多死了
- 有Spring Boot 這個獨立干將可以省很多事，大大小小的活spring boot都搞的挺不錯。
作為一個微服務治理的大傢伙，考慮的很全面，幾乎服務治理的方方面面都考慮到了，方便開發開箱即用。 - Spring Cloud 活躍度很高，教程很豐富，遇到問題很容易找到解決方案
- 輕輕鬆鬆幾行代碼就完成了熔斷、均衡負責、服務中心的各種平臺功能
- Spring Cloud 也有一個缺點，只能使用Java開發,不適合小型獨立的項目。
六、Spring Cloud前景
Spring Cloud對於中小型互聯網公司來說是一種福音，因為這類公司往往沒有實力或者沒有足夠的資金投入去開發自己的分佈式系統基礎設施，使用Spring Cloud一站式解決方案能在從容應對業務發展的同時大大減少開發成本。同時，隨著近幾年微服務架構和docker容器概念的火爆，也會讓Spring Cloud在未來越來越“雲”化的軟件開發風格中立有一席之地，尤其是在目前五花八門的分佈式解決方案中提供了標準化的、全站式的技術方案，
意義可能會堪比當前Servlet規範的誕生，有效推進服務端軟件系統技術水平的進步。共同進步，學習分享
歡迎大家關注我的公眾號【風平浪靜如碼】，海量Java相關文章，學習資料都會在裡面更新，整理的資料也會放在裡面。
覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！
閱讀更多 愛喝王老吉的劉某人 的文章
