SpringCloud是什麼

聊SpringCloud之前先聊聊微服務

1、微服務是什麼

微服務架構是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦

微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。

**概念：**把一個大型的單個應用程序和服務拆分爲數個甚至數十個的支持微服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。

**定義：**圍繞業務領域組件來創建應用，這些應用可獨立地進行開發、管理和迭代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。

**本質：**用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。

2、微服務架構的演變

微服務架構不是一下就出來的，而是經過市場的發展，技術的升級而逐漸出現的。

2.1、單體應用

單體應用就是將所有的功能都打包成一個獨立的單元。當網站訪問量很小是，只需要一個應用，將所有功能部署到一起，以便減少部署節點和成本。

特點：

所有的功能都集成在一個項目中
所有的功能打包成war包部署到服務器
應用與數據庫分開部署
通過部署應用集羣和數據庫集羣來提高系統的性能

優點：

開發簡單。一個IDE就可以快速構建單體應用。
便於共享。單個文檔包含所有的功能，傳遞共享很方便。
易於測試。一旦部署，所有的服務或特性就可以使用了，簡化了測試過程，沒有額外的依賴。
容易部署。項目就一個war包，Tomcat安裝好了之後，丟進去就可以運行。

缺點：

妨礙持續交互，就是說產品上線後，如果後期需要修改代碼，則需要對整個項目進行重新打包，再次上傳到服務器。
不夠靈活，就是隨着時間推移，功能越來越多，那麼在編譯打包部署項目的時候，就會很慢，降低了團隊開發的靈活性。
技術棧受限，就是說一旦確定了使用一種語言，就不能使用別的語言，不能混合別的語言，需要考慮各語言之間的兼容性。
可靠性差，就說是，一旦一個地方出了問題，整個項目就會崩掉。
伸縮性差，就比如說，在某個場景下某功能併發量會很大，需要加機器，但是如果是單體應用，整個應用是一體的，就需要對整個應用都加機器，造成不必要的性能浪費。、
技術債務，就是說，單體應用寫代碼的時候不會分的很細，什麼技術都使用了，寫在了一起，耦合度很高，後期維護什麼的很不方便，原本兩天就能完成的工作，就會變得很麻煩。

2.2、垂直應用

將單體應用的每個功能拆分文爲項目獨立存在。

特點：

以單體結構規模的項目爲單位進行垂直劃分，就是將一個大項目拆分成一個一個單體結構項目。
項目與項目之間存在數據冗餘，耦合性較大，比如上圖中三個項目都存在用戶信息。
項目之間的接口多爲數據同步功能，如：數據庫之間的數據庫，通過網絡接口進行數據庫同步。

優點：

架構簡單、開發成本低
避免單體無線擴張，就是說單體應用越開發功能越多，但是垂直應用不會，垂直應用本來就是每個功能獨立拆分出來的，後期如果要要新增功能，直接獨立爲一個新的項目就行。
系統拆分，流量分擔，解決併發問題。單體應用都是在一起的，而垂直應用是拆分開的，對服務器來說，不會像單體應用一樣有那麼大的壓力。
可以針對不同的功能進行升級，不用像單體應用一樣，一處改動，就需要對整個項目進行編譯打包數據。
系統間相對獨立。各個功能是分開的，一個功能出現問題，最多就是該功能無法使用，而不會造成整個大項目的崩潰。

缺點：

垂直應用各個之間是獨立了，相同功能代碼都需要重複編寫，代碼冗餘。
系統之間相互調用，IP如果發生改變，調用系統需要手動更改。各個功能之間的調用是根據IP和端口連接調用的，如果一個功能的ip或者端口發生了改變，則調用該功能的項目都要手動更改爲新的ip或者端口。
伸縮性依舊很差，如果要加機器，還要對整個拆分後的項目進行增加。成本高。

2.3、SOA面向服務架構

特點：

基於 SOA 的架構思想將重複公用的功能抽取爲組件，以服務的形式給各系統提供服務。
各項目（系統）與服務之間採用 WebService、RPC 等方式進行通信。
使用 ESB 企業服務總線作爲項目與服務之間通信的橋樑。

優點：

重複的功能抽取爲服務，提供開發效率
採用該ESB，減少系統中的接口耦合
可以針對不同的服務特點指定集羣優化方案。

缺點：

系統與服務器的界限模糊
服務器的拆分粒度比較大，系統與服務之間耦合較高
涉及多種中間件，對開發人員技術棧要求比較高
服務關係複雜，運維，測試，部署變得困難

2.4、微服務架構

優點：

團隊獨立。
技術獨立。（去中心化）??
前後端分離
數據庫分離
微服務拆分粒度更細
團隊新人可以更快的投入生產
可以使用不同的語言
適用於互聯網時代，產品迭代週期短

缺點：

微服務過多，服務治理成本高，不利於維護。
分佈式系統開發技術成本高（網絡問題，容錯問題，調用關係，分佈式事務…）
可能會有異步通信
運維，部署…

2.5、總結

微服務就是SOA發展出來的產物，他是一種比較現代化更細粒度的SOA實現方式。微服務是一種架構風格，架構就是爲了解耦，實際開發使用的還是分佈式。

3、微服務設計原則

3.1、AKF拆分原則

通常有一個理念就是：通過機器可以解決容量和可用性問題（一臺不行就兩臺）。

《The Art of Scalability》一書提出了一個系統的可擴展模型——AKF 可擴展立方。這個立方體中沿着三個座標軸設置分別爲 X，Y，Z。

一個叫 AKF 的公司的技術專家抽象總結的應用擴展的三個維度。理論上按照這三個擴展模式，可以將一個單體系統，進行無限擴展。

Y軸

就是微服務的拆分模式，按照功能拆分。

X軸

水平復制，一臺機器不行，就再來一臺機器…

Z軸

分區，爲了更好的使用體驗，進行分區，在每個地區（例如：華南區、華東區…）都建立一套自己的服務器，各個地區之間是相互隔離又是完整的。

3.2、前後端分離原則

3.2.1未分離

代表技術：Servlet+JSP+JavaBean

在前後端不分離的應用模式中，前端看到的頁面都是由後端控制的。例如JSP就是未分離的，需要在前端頁面中寫Java代碼。可以想象，在前端中寫後端代碼是一個多麼操蛋的事情。

<body>
   <%
       request.setCharacterEncoding("utf-8");
       String username = request.getParameter("username");
       System.out.print(username);
   %>
</body>

3.2.2、半分離

代表技術：：SSH、SSM、Freemarker…

半分離，例如Freemarker模板引擎，在發起請求的時候，後端返回攜帶Model數據，然後前端通過模板引擎解析獲數據。這種方式雖然不用在前端寫後端代碼，但是要獲取後端返回的數據還需要使用模板引擎的語法去解析數據。

3.2.3、已分離

代表技術：Node.js前端開發框架。VueJS，ReactJS，AngularJS

已分離的應用模式中，後端僅僅返回前端所需要的數據（通常是JSON格式），而不再進行其它操作，具體返回的JSON數據怎麼使用，由前端開發者安排。這樣就可以做到前後端分離，前端和後端，各自做自己要實現的功能，後端寫完後只需要給個接口給前端即可。

總結

前後端技術分離，可以由各自的開發團隊來對各自的領域進行優化，這樣前端的用戶體驗優化效果更好。

前後端分離模式下，前後端交互界面更清晰，就剩下了接口模型，後端的接口簡潔明瞭，更容易維護。

前端多渠道集成場景更容易實現，後端服務無需變更，採用統一的數據和模型，可以支持多個前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。

3.3、無狀態服務

如果一個數據需要被多個服務共享才能完成一筆交易，那麼這個數據被稱爲狀態。進而依賴這個"狀態"數據的服務被稱爲有狀態服務，反之稱爲無狀態服務。

3.4、Restful通信風格

IP:PORT/接口

JSON報文，輕量級，人機均可閱讀
HTTP無狀態，加密又可以依附HTTPS
有一套約定俗成的接口設計風格

3.5、CAP原則與BASE理論

C：一致性，分佈式項目中，各個節點的數據最終要保持一致。
A：可用性，分佈式項目的任意節點，在一定的時間內返回有效數據，數據可以是成功或者失敗
P：分區容錯，多分區存儲數據

CAP原則指的是，在構建分佈式項目時，只能滿足其中兩項，三者不可兼得。業界的人花了兩年時間論證該信息。

分析：分佈式項目，必然會設計數據分區的問題。肯定需要P，那麼項目肯定是CP或者AP。

BASE理論其實核心就是：最終一致性。

這裏簡單說明，具體在Eureka註冊中心中描述。

4、微服務架構帶來的問題

客戶端如何訪問服務?

後臺有N個服務，前臺就需要管理N個地址，一個服務的下線/升級/擴容，前端都要從新部署

所以，一般在後臺N個服務和客戶端之間會有一個代理(API Gateway)，作用：

提供統一入口
聚合後臺服務，節省流量，提供用戶體驗
提供安全、流控、過濾、緩存、路由、監控…

服務之間如何通信?

同步通信：

Restful
RPC

異步通信：

這麼多服務如何查找?

利用註冊中心機制，將服務集羣註冊到註冊中心，然後把服務的狀態推送到各個節點，比如動態的服務擴容、服務的下線等。通過心跳機制檢測服務是否可用。

服務掛了怎麼辦？

服務容錯手段：

請求緩存：支持將一個請求與返回結果做緩存處理
請求合併：將相同的請求進行合併然後調用批處理接口
請求限流：當請求過多時，可以採取限流措施，降低機器的負載壓力
服務隔離：限制調用分佈式服務的資源，某一個調用的服務出現問題不會影響其它服務調用
服務熔斷：犧牲局部服務，保證整體系統穩定性的措施
服務降級：服務熔斷後，客戶端調用自己本地方法返回缺省值

5、微服務架構技術生態體系

5.1、服務網關

所有的API調用接入到API網關層，由網關層統一提供入口和輸出，屏蔽底層的微服務。

一個網關的基本功能有：統一接入、安全防護、協議適配、流量管控、長短鏈接支持、容錯能力。有了網關之後，各個 API 服務提供團隊可以專注於自己的的業務邏輯處理，而 API 網關更專注於安全、流量、路由等問題。

5.2、服務調用

微服務架構中，通常存在多個服務之間的遠程調用。目前主流的遠程調用技術有基於 HTTP 的 RESTful 接口和基於 TCP 的 RPC 協議。以上兩種都屬於同步通信，還有基於隊列模式的異步通信。

REST：一種HTTP調用的格式，更標準，更通用，無論哪種語言都支持HTTP協議。
RPC：進程間的通信共享，允許像調用本地服務一樣調用遠程服務。RPC框架的主要目標就是讓遠程服務調用更簡單更透明。RPC 框架負責屏蔽底層的傳輸方式、序列化方式和通信細節。開發人員在使用的時候只需要瞭解誰在什麼位置提供了什麼樣的遠程服務接口即可，並不需要關心底層通信細節和調用過程。

比較項	REST	RPC
通訊協議	HTTP	一般使用 TCP
性能	略低	較高
靈活度	高	低
應用	微服務架構	SOA 架構

5.3、負載均衡

服務高可用的保證手段，爲了保證高可用，每一個微服務都需要部署多個服務實例來提供服務，此時就需要根據不同的負載均衡策略對服務進行調用。

5.4、服務容錯

微服務中，一個請求經常會設計到調用多個服務，如果其中某個服務不可用，沒有做服務容錯的話，極有可能會造成一連串的服務不可用，這就是服務雪峯效應。最終的結果就是，一個服務不可用，導致一系列服務不可用。

造成雪崩的原因有三點：

服務提供者不可用(硬件故障、程序BUG、緩存擊穿、用戶大量請求等)
重試加大流量(用戶重試，代碼邏輯重試)
消費者服務不可用(同步等待造成的資源浪費)

沒法預防雪崩效應的發生，只能儘可能去做好容錯。服務容錯的三個核心思想是：

不被外界環境影響
不被上游請求壓垮
不被下游響應拖垮

5.5、鏈路追蹤

隨着微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務。互聯網應用構建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千臺服務器，橫跨多個不同的數據中心。因此，就需要對一次請求涉及的多個服務鏈路進行日誌記錄，性能監控等等。單純的理解鏈路追蹤，就是指一次任務的開始到結束，期間調用的所有系統及耗時（時間跨度）都可以完整記錄下來。

5.6、配置中心

微服務系統中，每個微服務不僅僅只有代碼，還需要連接其他資源，例如數據庫的配置或功能性的開關 MySQL、Redis 、Security 等相關的配置。除了項目運行的基礎配置之外，還有一些配置是與業務有關係的，比如說七牛存儲、短信和郵件相關，或者一些業務上的開關。

但是隨着微服務系統的不斷迭代，整個微服務系統可能會成爲一個網狀結構，這個時候就要考慮整個微服務系統的擴展性、伸縮性、耦合性等等。其中一個很重要的環節就是配置管理的問題。

常規配置管理方案的缺點：

硬編碼（需要修改代碼，繁瑣，風險大）
properties 或者 yml（集羣環境下需要替換和重啓）
xml（重新打包和重啓）

常規配置管理有很大的缺點，所以採用 Spring Cloud Config 或 Consul 或 Apollo 或 Nacos 等配置中心集中式的來管理每個服務的配置信息。

5.7、安全認證

從單體應用架構到分佈式應用架構再到微服務架構，應用的安全訪問在不斷的經受考驗。爲了適應架構的變化、需求的變化，身份認證與鑑權方案也在不斷的變革。面對數十個甚至上百個微服務之間的調用，如何保證高效安全的身份認證？面對外部的服務訪問，該如何提供細粒度的鑑權方案？

David Borsos 在倫敦的微服務大會上提出了四種解決方案：

5.7.1、單點登錄(SSO)

這種方案意味着每個面向用戶的服務都必須與認證服務交互，這會產生大量非常瑣碎的網絡流量和重複的工作，隨着微服務應用的增多，這種方案的弊端會更加明顯。

5.7.2、分佈式Session方案

分佈式會話方案原理主要是將關於用戶認證的信息存儲在共享存儲中，且通常由用戶會話作爲 Key 來實現的簡單分佈式哈希映射。當用戶訪問微服務時，用戶數據可以從共享存儲中獲取。這種方案的缺點在於共享存儲需要一定保護機制，因此需要通過安全鏈接來訪問，這時解決方案的實現就通常具有相當高的複雜性了。

5.7.3、客戶端Token方案

令牌在客戶端生成，由身份驗證服務進行簽名，並且必須包含足夠的信息，以便可以在所有微服務中建立用戶身份。令牌會附加到每個請求上，爲微服務提供用戶身份驗證，這種解決方案的安全性相對較好，但身份驗證註銷是一個大問題，緩解這種情況的方法可以使用短期令牌和頻繁檢查認證服務等。對於客戶端令牌的編碼方案，David Borsos 更喜歡使用 JSON Web Tokens（JWT），它足夠簡單且庫支持程度也比較好。

5.7.4、客戶端Token與API網關結合

這個方案意味着所有請求都通過網關，從而有效地隱藏了微服務。在請求時，網關將原始用戶令牌轉換爲內部會話 ID 令牌。在這種情況下，註銷就不是問題，因爲網關可以在註銷時撤銷用戶的令牌。

5.7.5、總結

微服務架構下，更傾向於 David Borsos 所建議的 JWT 方案，將 OAuth2 和 JWT 結合使用，OAuth2 一般用於第三方接入的場景，管理對外的權限，所以比較適合和 API 網關結合，針對於外部的訪問進行鑑權（當然，底層 Token 標準採用 JWT 也是可以的）。

JWT 更加輕巧，在微服務之間進行認證&鑑權已然足夠，並且可以避免和身份認證服務直接打交道。當然，從能力實現角度來說，類似於分佈式 Session 在很多場景下也是完全能滿足需求，具體怎麼去選擇鑑權方案，還是要結合實際的需求來。

6、微服務架構技術支持

6.1、Spring Cloud

Spring Cloud Netflix Eureka：服務註冊中心。
Spring Cloud Zookeeper：服務註冊中心。
Spring Cloud Consul：服務註冊和配置管理中心。
Spring Cloud Netflix Ribbon：客戶端負載均衡。
Spring Cloud Netflix Hystrix：服務容錯保護。
Spring Cloud Netflix Feign：聲明式服務調用。
Spring Cloud OpenFeign(可替代 Feign)：OpenFeign 是 Spring Cloud 在 Feign 的基礎上支持了 Spring MVC 的註解，如 @RequesMapping等等。OpenFeign 的 @FeignClient 可以解析 SpringMVC 的 @RequestMapping 註解下的接口，並通過動態代理的方式產生實現類，實現類中做負載均衡並調用其他服務。
Spring Cloud Netflix Zuul：API 網關服務，過濾、安全、監控、限流、路由。
Spring Cloud Gateway(可替代 Zuul)：Spring Cloud Gateway 是 Spring 官方基於 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術開發的網關，Spring Cloud Gateway 旨在爲微服務架構提供一種簡單而有效的統一的 API 路由管理方式。Spring Cloud Gateway 作爲 Spring Cloud 生態系中的網關，目標是替代 Netflix Zuul，其不僅提供統一的路由方式，並且基於 Filter 鏈的方式提供了網關基本的功能，例如：安全，監控/埋點，和限流等。
Spring Cloud Security：安全認證。
Spring Cloud Config：分佈式配置中心。配置管理工具，支持使用 Git 存儲配置內容，支持應用配置的外部化存儲，支持客戶端配置信息刷新、加解密配置內容等。
Spring Cloud Bus：事件、消息總線，用於在集羣（例如，配置變化事件）中傳播狀態變化，可與 Spring Cloud Config 聯合實現熱部署。
Spring Cloud Stream：消息驅動微服務。
Spring Cloud Sleuth：分佈式服務跟蹤。
Spring Cloud Alibaba Nacos：阿里巴巴開源產品，一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。
Spring Cloud Alibaba Sentinel：面向分佈式服務架構的輕量級流量控制產品，把流量作爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。
Spring Cloud Alibaba RocketMQ：一款開源的分佈式消息系統，基於高可用分佈式集羣技術，提供低延時的、高可靠的消息發佈與訂閱服務。
Spring Cloud Alibaba Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架，用於實現服務通信。
Spring Cloud Alibaba Seata：阿里巴巴開源產品，一個易於使用的高性能微服務分佈式事務解決方案。
Spring Cloud Alibaba OSS：阿里雲對象存儲服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、安全、低成本、高可靠的雲存儲服務。您可以在任何應用、任何時間、任何地點存儲和訪問任意類型的數據。
Spring Cloud Alibaba SchedulerX：阿里中間件團隊開發的一款分佈式任務調度產品，提供秒級、精準、高可靠、高可用的定時（基於 Cron 表達式）任務調度服務。
Spring Cloud Alibaba SMS：覆蓋全球的短信服務，友好、高效、智能的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。

6.2、其它

RibbitMQ：RabbitMQ 是部署最廣泛的開源消息中間件。是實現了高級消息隊列協議（AMQP）的開源消息中間件。
Kafka：Kafka 是由 Apache 軟件基金會開發的一個開源流處理平臺，由Scala和Java編寫。Kafka 是一種高吞吐量的分佈式發佈訂閱消息系統。
Redis：Redis（Remote Dictionary Server )，即遠程字典服務，是一個開源的使用 ANSI C 語言編寫、支持網絡、可基於內存亦可持久化的日誌型、Key-Value 數據庫，並提供多種語言的 API。
MongoDB：MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。它支持的數據結構非常鬆散，是類似 json 的 bson 格式，因此可以存儲比較複雜的數據類型。
Elasticsearch：Elasticsearch 是一個基於 Lucene 的搜索服務器。它提供了一個分佈式多用戶能力的全文搜索引擎，基於 RESTful web 接口。Elasticsearch 是最受歡迎的企業搜索引擎，其次是 Apache Solr，也是基於 Lucene。
MySQL：MySQL 是一種開放源代碼的關係型數據庫管理系統（RDBMS），免費、簡單、佔資源少、強大好用。
Oracle：世界上最昂貴的數據庫，一般金融系統使用居多。
FastDFS：FastDFS是一個開源的輕量級分佈式文件系統，它對文件進行管理，功能包括：文件存儲、文件同步、文件訪問（文件上傳、文件下載）等，解決了大容量存儲和負載均衡的問題。特別適合以文件爲載體的在線服務，如相冊網站、視頻網站等等。
HDFS：Hadoop 生態組件，可以支持千萬級的大型分佈式文件系統。
XX-JOB：輕量級分佈式任務調度平臺，其核心設計目標是開發迅速、學習簡單、輕量級、易擴展。現已開放源代碼並接入多家公司線上產品線，開箱即用。
TX-LCN：分佈式事務解決防範，LCN 並不生產事務，LCN 只是本地事務的搬用工（事務的協調工）。LCN 是一個高性能的分佈式事務框架，兼容 Dubbo、Spring Cloud，支持 RPC 框架拓展，支持各種 ORM 框架、NoSQL、負載均衡、事務補償。
Zipkin：Twitter 公司開發貢獻的一款開源的分佈式實時數據追蹤系統（Distributed Tracking System），基於 Google Dapper 的論文設計而來，其主要功能是聚集各個異構系統的實時監控數據。
Skywalking：Apache Skywalking 是一個開源的，用於收集、分析，聚合，可視化來自於不同服務和本地基礎服務的數據的可觀察的平臺。特別爲分佈式系統而設計的數據觀察和監控系統。
Apollo：攜程框架部門研發的分佈式配置中心，能夠集中化管理應用不同環境、不同集羣的配置，配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性，適用於微服務配置管理場景。
ConfigKeeper：隨行付架構部基於 Spring Cloud 研發的分佈式配置中心。與 Spring Boot、Spring Cloud 應用無縫兼容。
JWT：JSON Web Token（JWT）是一個非常輕巧的規範。這個規範允許我們使用 JWT 在用戶和服務器之間傳遞安全可靠的信息。
Nginx：Nginx 是一款輕量級的 Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，其特點是佔有內存少，併發能力強，中國大陸使用 Nginx 網站用戶有：百度、淘寶、騰訊、京東、新浪、網易等。
Git：開源的分佈式版本控制系統，可以有效、高速地處理從很小到非常大的項目版本管理。
Docker：Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的鏡像中，然後發佈到任何流行的 Linux 或 Windows 機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何接口。
Kubernetes：Kubernetes，簡稱 k8s，是用 8 代替 8 個字符“ubernete”而成的縮寫。Kubernetes 脫胎於 Google 的 Borg 系統，是一個開源的功能強大的容器編排系統，用於管理雲平臺中多個主機上的容器化的應用，實現了容器集羣的自動化部署、擴容以及運維的開源平臺。Kubernetes 的目標是讓部署容器化的應用簡單並且高效。
Git：版本控制工具
Docker：開源應用容器
K8s：容器管理

7、SpringCloud

SpringCloud是一個服務治理平臺，是若干的框架的集合，提供了全套的分佈式系統解決方案。包含服務註冊與發現、配置中心、服務網關、智能路由、負載均衡、斷路監控跟蹤、分佈式消息隊列等等。

SpringCloud通過SpringBoot風格的封裝，屏蔽掉了複雜的配置和實現原理。最終給開發者留出了一套簡單易懂、容易部署的分佈式系統開發啊工具包。開發者可以快速的啓動服務或構建應用，同時能夠快速和雲平臺資源進行隊列。微服務是可以獨立部署、水平擴展、獨立訪問（或者有獨立的數據庫）的服務單元，Spring Cloud 就是這些微服務的大管家，採用了微服務這種架構之後，項目的數量會非常多，Spring Cloud 做爲大管家需要管理好這些微服務，自然需要很多小弟來幫忙。

Spring Cloud的優點

集大成者，Spring Cloud包含了微服務架構的方方面面。
約定大於配置，基於註解，沒有配置文件。
輕量級組件，Spring Cloud整合的組件大多比較輕量級，且都是各自領域的佼佼者。
開發簡便，Spring Cloud 對各個組件進行了大量的封裝，從而簡化了開發。
開發靈活，Spring Cloud 的組件都是解耦的，開發人員可以靈活按需選擇組件。

Spring Cloud的缺點

項目結構複雜，每個組件或者每個服務器都需要創建一個項目。
部署門檻高，項目部署需要配合Docker等容器技術進行進羣部署，學習成本高。

7.1、Spring Cloud Netflix 第一代

Netflix是美國的一家公司，提供流媒體播放。

針對多種 Netflix 組件提供的開發工具包，其中包括 Eureka、Ribbon、Feign、Hystrix、Zuul、Archaius 等。

Netflix Eureka：一個基於 Rest 服務的服務治理組件，包括服務註冊中心、服務註冊與服務發現機制的實現，實現了雲端負載均衡和中間層服務器的故障轉移。
Netflix Ribbon：客戶端負載均衡的服務調用組件。
Netflix Hystrix：容錯管理工具，實現斷路器模式，通過控制服務的節點，從而對延遲和故障提供更強大的容錯能力。
Netflix Feign：基於 Ribbon 和 Hystrix 的聲明式服務調用組件。
Netflix Zuul：微服務網關，提供動態路由，訪問過濾等服務。
Netflix Archaius：配置管理 API，包含一系列配置管理 API，提供動態類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。

7.2、Spring Cloud Alibaba 第二代

和Spring Cloud一樣，Spring Cloud Alibaba也是一套微服務解決方案。Spring Cloud Alibaba致力於提供微服務開發的一站式解決方案。此項目包含開發分佈式應用微服務的必須組件，方便開發者通過Spring Cloud 編程模型輕鬆使用這些組件來開發分佈式應用服務。

依託 Spring Cloud Alibaba，只需要添加一些註解和少量配置，就可以將 Spring Cloud 應用接入阿里微服務解決方案，通過阿里中間件來迅速搭建分佈式應用系統。

阿里開源組件

Nacos：阿里巴巴開源產品，一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。
Sentinel：面向分佈式服務架構的輕量級流量控制產品，把流量作爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。
RocketMQ：一款開源的分佈式消息系統，基於高可用分佈式集羣技術，提供低延時的、高可靠的消息發佈與訂閱服務。
Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架，用於實現服務通信。
Seata：阿里巴巴開源產品，一個易於使用的高性能微服務分佈式事務解決方案。

阿里商業化組件

Alibaba Cloud ACM：一款在分佈式架構環境中對應用配置進行集中管理和推送的應用配置中心產品。
Alibaba Cloud OSS：阿里雲對象存儲服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、安全、低成本、高可靠的雲存儲服務。您可以在任何應用、任何時間、任何地點存儲和訪問任意類型的數據。
Alibaba Cloud SchedulerX：阿里中間件團隊開發的一款分佈式任務調度產品，提供秒級、精準、高可靠、高可用的定時（基於 Cron 表達式）任務調度服務。
Alibaba Cloud SMS：覆蓋全球的短信服務，友好、高效、智能的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。

7.2.1、常用組件

Spring Cloud Netflix Eureka：服務註冊中心。
Spring Cloud Zookeeper：服務註冊中心。
Spring Cloud Consul：服務註冊和配置管理中心。
Spring Cloud Netflix Ribbon：客戶端負載均衡。
Spring Cloud Netflix Hystrix：服務容錯保護。
Spring Cloud Netflix Feign：聲明式服務調用。
Spring Cloud OpenFeign(可替代 Feign)：OpenFeign 是 Spring Cloud 在 Feign 的基礎上支持了 Spring MVC 的註解，如 @RequesMapping等等。OpenFeign 的 @FeignClient 可以解析 SpringMVC 的 @RequestMapping 註解下的接口，並通過動態代理的方式產生實現類，實現類中做負載均衡並調用其他服務。
Spring Cloud Netflix Zuul：API 網關服務，過濾、安全、監控、限流、路由。
Spring Cloud Gateway(可替代 Zuul)：Spring Cloud Gateway 是 Spring 官方基於 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術開發的網關，Spring Cloud Gateway 旨在爲微服務架構提供一種簡單而有效的統一的 API 路由管理方式。Spring Cloud Gateway 作爲 Spring Cloud 生態系中的網關，目標是替代 Netflix Zuul，其不僅提供統一的路由方式，並且基於 Filter 鏈的方式提供了網關基本的功能，例如：安全，監控/埋點，和限流等。
Spring Cloud Security：安全認證。
Spring Cloud Config：分佈式配置中心。配置管理工具，支持使用 Git 存儲配置內容，支持應用配置的外部化存儲，支持客戶端配置信息刷新、加解密配置內容等。
Spring Cloud Bus：事件、消息總線，用於在集羣（例如，配置變化事件）中傳播狀態變化，可與 Spring Cloud Config 聯合實現熱部署。
Spring Cloud Stream：消息驅動微服務。
Spring Cloud Sleuth：分佈式服務跟蹤。
Spring Cloud Alibaba Nacos：阿里巴巴開源產品，一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。
Spring Cloud Alibaba Sentinel：面向分佈式服務架構的輕量級流量控制產品，把流量作爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。
Spring Cloud Alibaba RocketMQ：一款開源的分佈式消息系統，基於高可用分佈式集羣技術，提供低延時的、高可靠的消息發佈與訂閱服務。
Spring Cloud Alibaba Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架，用於實現服務通信。
Spring Cloud Alibaba Seata：阿里巴巴開源產品，一個易於使用的高性能微服務分佈式事務解決方案。

7.3、Spring Cloud版本說明

SpringCloud不是使用數字命名版本號，而是使用的英文單詞(地鐵站名字)命名，是爲了避免總版本號與子項目的版本號混淆。

7.3.1、命名規則

採用倫敦的地鐵站名稱來作爲版本號的命名，根據首字母排序，字母順序靠後的版本號越大。

Spring 官方詳細的版本查看接口：https://start.spring.io/actuator/info

7.3.2、發佈計劃

版本號	版本	說明
BUILD-XXX	開發版	開發團隊內部使用
M	里程碑版	MileStone，M1 表示第 1 個里程碑版本，一般同時標註 PRE，表示預覽版
版	候選發佈版	Release Candidate，正式發佈版的前一個觀察期，不添加新功能，主要着重於除錯
SR	正式發佈版	Service Release，SR1 表示第 1 個正式版本，一般同時標註 GA，表示穩定版本
GA	穩定版	經過全面測試並可對外發行稱之爲GA（General Availability）

7.3.3、子項目版本說明

例如：Spring Cloud Alibaba 2.1.0.RELEASE

主版本號。當功能模塊有較大更新或者整體架構發生變化時，主版本號會更新。
1：次版本號。次版本表示只是局部的一些變動。
0：修改版本號。一般是 bug 的修復或者是小的變動。
RELEASE：希臘字母版本號。標註當前版本的軟件處於哪個開發階段。

7.3.4、希臘版本字母說明

Base：設計階段。只有相應的設計沒有具體的功能實現。
Alpha：軟件的初級版本。存在較多的 bug。
Bate：表示相對 Alpha 有了很大的進步，消除了嚴重的 bug，還存在一些潛在的 bug。
Gamma：是 Beta 版做過一些修改，成爲正式發佈的候選版本（Release Candidate）
Release：該版本表示最終版。

(〇)SpringCloud之SpringCloud是什麼

SpringCloud是什麼

1、微服務是什麼

2、微服務架構的演變

2.1、單體應用

2.2、垂直應用

2.3、SOA面向服務架構

2.4、微服務架構

2.5、總結

3、微服務設計原則

3.1、AKF拆分原則

3.2、前後端分離原則

3.2.1未分離

3.2.2、半分離

3.2.3、已分離

3.3、無狀態服務

3.4、Restful通信風格

3.5、CAP原則與BASE理論

4、微服務架構帶來的問題

5、微服務架構技術生態體系

5.1、服務網關

5.2、服務調用

5.3、負載均衡

5.4、服務容錯

5.5、鏈路追蹤

5.6、配置中心

5.7、安全認證

5.7.1、單點登錄(SSO)

5.7.2、分佈式Session方案

5.7.3、客戶端Token方案

5.7.4、客戶端Token與API網關結合

5.7.5、總結

6、微服務架構技術支持

6.1、Spring Cloud

6.2、其它

7、SpringCloud

7.1、Spring Cloud Netflix 第一代

7.2、Spring Cloud Alibaba 第二代

7.2.1、常用組件

7.3、Spring Cloud版本說明

7.3.1、命名規則

7.3.2、發佈計劃

7.3.3、子項目版本說明

7.3.4、希臘版本字母說明