javascript
Spring Cloud（一）：Spring Cloud的优势是什么？
Spring Cloud 作為一套微服務(wù)治理的框架，幾乎考慮到了微服務(wù)治理的方方面面。
本次分享主要解答這兩個問題：Spring Cloud 在微服務(wù)的架構(gòu)中都做了哪些事情？Spring Cloud 提供的這些功能對微服務(wù)的架構(gòu)提供了怎樣的便利？
我們先來簡單回顧一下，我們以往互聯(lián)網(wǎng)架構(gòu)的發(fā)展情況：
傳統(tǒng)架構(gòu)發(fā)展史
單體架構(gòu)
單體架構(gòu)在小微企業(yè)比較常見，典型代表就是一個應(yīng)用、一個數(shù)據(jù)庫、一個 Web 容器就可以跑起來，比如我們開發(fā)的開源軟件云收藏，就是標(biāo)準(zhǔn)的單體架構(gòu)。
在兩種情況下可能會選擇單體架構(gòu)：
1，在企業(yè)發(fā)展的初期，為了保證快速上線，采用此種方案較為簡單靈活。
2，傳統(tǒng)企業(yè)中垂直度較高，訪問壓力較小的業(yè)務(wù)。在這種模式下對技術(shù)要求較低，方便各層次開發(fā)人員接手，也能滿足客戶需求。
下面是單體架構(gòu)的架構(gòu)圖：
在單體架構(gòu)中，技術(shù)選型非常靈活，優(yōu)先滿足快速上線的要求，也便于快速跟進市場。
垂直架構(gòu)
在單體架構(gòu)發(fā)展一段時間后，公司的業(yè)務(wù)模式得到了認(rèn)可，交易量也慢慢的大起來，這時候有些企業(yè)為了應(yīng)對更大的流量，就會對原有的業(yè)務(wù)進行拆分，比如說：后臺系統(tǒng)、前端系統(tǒng)、交易系統(tǒng)等。
在這一階段往往會將系統(tǒng)分為不同的層級，每個層級有對應(yīng)的職責(zé)，UI 層負(fù)責(zé)和用戶進行交互、業(yè)務(wù)邏輯層負(fù)責(zé)具體的業(yè)務(wù)功能、數(shù)據(jù)庫層負(fù)責(zé)和上層進行數(shù)據(jù)交換和存儲。
下面是垂直架構(gòu)的架構(gòu)圖：
在這個階段 SSH（Struts+Spring+Hibernate）是項目的關(guān)鍵技術(shù)，Struts 負(fù)責(zé) Web 層邏輯控制、Spring 負(fù)責(zé)業(yè)務(wù)層管理 Bean、Hibernate 負(fù)責(zé)對數(shù)據(jù)庫操作進行封裝，持久化數(shù)據(jù)。
服務(wù)化架構(gòu)
如果公司進一步的做大，垂直子系統(tǒng)會變的越來越多，系統(tǒng)和系統(tǒng)之間的調(diào)用關(guān)系呈指數(shù)上升的趨勢。
在這樣的背景下，很多公司都會考慮服務(wù)的 SOA 化。SOA 代表面向服務(wù)的架構(gòu)，將應(yīng)用程序按照不同的職責(zé)劃分為不同的模塊，不同的模塊直接通過特定的協(xié)議和接口進行交互。
這樣將整個系統(tǒng)切分成很多單個組件服務(wù)來完成請求，當(dāng)流量過大時通過水平擴展相應(yīng)的組件來支撐，所有的組件通過交互來滿足整體的業(yè)務(wù)需求。
SOA 服務(wù)化的優(yōu)點是，它可以根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進行分布式部署、組合和使用。
服務(wù)層是 SOA 的基礎(chǔ)，可以直接被應(yīng)用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。
服務(wù)化架構(gòu)是一套松耦合的架構(gòu)，服務(wù)的拆分原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。
下面是服務(wù)化架構(gòu)圖：
在這個階段可以使用 Web Service 或者 Dubbo 來服務(wù)治理。
SOA 和微服務(wù)架構(gòu)
SOA 和微服務(wù)的區(qū)別
服務(wù)化架構(gòu)已經(jīng)可以解決大部分企業(yè)的需求了，那么我們?yōu)槭裁匆芯课⒎?wù)呢？
先說說它們的區(qū)別，如下幾點：
微服務(wù)架構(gòu)強調(diào)業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化，一個組件就是一個產(chǎn)品，可以獨立對外提供服務(wù)。
微服務(wù)不再強調(diào)傳統(tǒng) SOA 架構(gòu)里面比較重的 ESB 企業(yè)服務(wù)總線。
微服務(wù)強調(diào)每個微服務(wù)都有自己獨立的運行空間，包括數(shù)據(jù)庫資源。
微服務(wù)架構(gòu)本身來源于互聯(lián)網(wǎng)的思路，因此組件對外發(fā)布的服務(wù)強調(diào)了采用 HTTP Rest API 的方式來進行。
微服務(wù)的切分粒度會更小。
總結(jié)：微服務(wù)架構(gòu)是 SOA 架構(gòu)思想的一種擴展，更加強調(diào)服務(wù)個體的獨立性、拆分粒度更小。
為什么考慮 Spring Cloud？
考慮 Spring Cloud 的原因有如下幾點：
Spring Cloud 的特性
以下為 Spring Cloud 的核心特性：
這些特性都是由不同的組件來完成，在架構(gòu)的演進過程中扮演著重要的角色，接下來我們一起看看。
微服務(wù)架構(gòu)
Spring Cloud 解決的第一個問題就是：服務(wù)與服務(wù)之間的解耦。很多公司在業(yè)務(wù)高速發(fā)展的時候，服務(wù)組件也會相應(yīng)的不斷增加。
服務(wù)和服務(wù)之間有著復(fù)雜的相互調(diào)用關(guān)系，經(jīng)常有服務(wù) A 調(diào)用服務(wù) B，服務(wù) B 調(diào)用服務(wù) C 和服務(wù) D …，隨著服務(wù)化組件的不斷增多，服務(wù)之間的調(diào)用關(guān)系成指數(shù)級別的增長，極端情況如下圖所示：
這樣最容易導(dǎo)致的情況就是牽一發(fā)而動全身，經(jīng)常出現(xiàn)由于某個服務(wù)更新而沒有通知到其它服務(wù)，導(dǎo)致上線后慘案頻發(fā)。
這時候就應(yīng)該進行服務(wù)治理，將服務(wù)之間的直接依賴轉(zhuǎn)化為服務(wù)對服務(wù)中心的依賴。Spring Cloud 核心組件 Eureka 就可以解決這類問題。
Eureka
是為了解決因一個服務(wù)宕機而影響其調(diào)用服務(wù)，而導(dǎo)致雪球效應(yīng)，對服務(wù)與服務(wù)之間進行解耦。
Eureka 是 Netflix 開源的一款提供服務(wù)注冊和發(fā)現(xiàn)的產(chǎn)品，它提供了完整的 Service Registry 和 Service Discovery 實現(xiàn)。它也是 Spring Cloud 體系中最重要最核心的組件之一。
用大白話講，Eureka 就是一個服務(wù)中心，將所有的可以提供的服務(wù)都注冊到它這里來管理，其他各調(diào)用者需要的時候去注冊中心獲取，然后再進行調(diào)用，避免了服務(wù)之間的直接調(diào)用，方便后續(xù)的水平擴展、故障轉(zhuǎn)移等。如下圖：
當(dāng)然服務(wù)中心這么重要的組件一旦掛掉將會影響全部服務(wù)，因此需要搭建 Eureka 集群來保持高可用性，生產(chǎn)中建議最少兩臺。
隨著系統(tǒng)的流量不斷增加，需要根據(jù)情況來擴展某個服務(wù)，Eureka 內(nèi)部已經(jīng)提供均衡負(fù)載的功能，只需要增加相應(yīng)的服務(wù)端實例既可。
**那么在系統(tǒng)的運行期間某個實例掛了怎么辦？**Eureka 內(nèi)容有一個心跳檢測機制，如果某個實例在規(guī)定的時間內(nèi)沒有進行通訊則會自動被剔除掉，避免了某個實例掛掉而影響服務(wù)。
因此使用了 Eureka 就自動具有了注冊中心、負(fù)載均衡、故障轉(zhuǎn)移的功能。
Hystrix
在微服務(wù)架構(gòu)中通常會有多個服務(wù)層調(diào)用，基礎(chǔ)服務(wù)的故障可能會導(dǎo)致級聯(lián)故障，進而造成整個系統(tǒng)不可用的情況，這種現(xiàn)象被稱為服務(wù)雪崩效應(yīng)。
服務(wù)雪崩效應(yīng)是一種因“服務(wù)提供者”的不可用導(dǎo)致“服務(wù)消費者”的不可用，并將不可用逐漸放大的過程。
如下圖所示：A 作為服務(wù)提供者，B 為 A 的服務(wù)消費者，C 和 D 是 B 的服務(wù)消費者。A 不可用引起了 B 的不可用，并將不可用像滾雪球一樣放大到 C 和 D 時，雪崩效應(yīng)就形成了。
在這種情況下就需要整個服務(wù)機構(gòu)具有故障隔離的功能，避免某一個服務(wù)掛掉影響全局。在 Spring Cloud 中 Hystrix 組件就扮演這個角色。
Hystrix 會在某個服務(wù)連續(xù)調(diào)用N次不響應(yīng)的情況下，立即通知調(diào)用端調(diào)用失敗，避免調(diào)用端持續(xù)等待而影響了整體服務(wù)。Hystrix 間隔時間會再次檢查此服務(wù)，如果服務(wù)恢復(fù)將繼續(xù)提供服務(wù)。
Hystrix Dashboard 和 Turbine
原因：當(dāng)熔斷發(fā)生的時候需要迅速的響應(yīng)來解決問題，避免故障進一步擴散，那么對熔斷的監(jiān)控就變得非常重要。
熔斷的監(jiān)控現(xiàn)在有兩款工具：Hystrix-dashboard 和 Turbine。
Hystrix-dashboard 是一款針對 Hystrix 進行實時監(jiān)控的工具，通過 Hystrix Dashboard 我們可以直觀地看到各 Hystrix Command 的請求響應(yīng)時間, 請求成功率等數(shù)據(jù)。
但是只使用 Hystrix Dashboard 的話, 你只能看到單個應(yīng)用內(nèi)的服務(wù)信息, 這明顯不夠。
我們需要一個工具能讓我們匯總系統(tǒng)內(nèi)多個服務(wù)的數(shù)據(jù)并顯示到 Hystrix Dashboard 上，這個工具就是 Turbine。
監(jiān)控的效果圖如下：
配置中心
隨著微服務(wù)不斷的增多，每個微服務(wù)都有自己對應(yīng)的配置文件。在研發(fā)過程中有測試環(huán)境、UAT 環(huán)境、生產(chǎn)環(huán)境，因此每個微服務(wù)又對應(yīng)至少三個不同環(huán)境的配置文件。
這么多的配置文件，如果需要修改某個公共服務(wù)的配置信息，如：緩存、數(shù)據(jù)庫等，難免會產(chǎn)生混亂，這個時候就需要引入 Spring Cloud 另外一個組件：Spring Cloud Config。
Spring Cloud Config
Spring Cloud Config 是一個解決分布式系統(tǒng)的配置管理方案。它包含了 Client 和 Server 兩個部分，Server 提供配置文件的存儲、以接口的形式將配置文件的內(nèi)容提供出去，Client 通過接口獲取數(shù)據(jù)、并依據(jù)此數(shù)據(jù)初始化自己的應(yīng)用。
具體實現(xiàn)是 Server 端將所有的配置文件服務(wù)化，需要配置文件的服務(wù)實例去 Config Server 獲取對應(yīng)的數(shù)據(jù)。將所有的配置文件統(tǒng)一整理，避免了配置文件碎片化。
如果服務(wù)運行期間改變配置文件，服務(wù)是不會得到最新的配置信息，需要解決這個問題就需要引入 Refresh。它可以在服務(wù)的運行期間重新加載配置文件。
當(dāng)所有的配置文件都存儲在配置中心的時候，配置中心就成為了一個非常重要的組件。
如果配置中心出現(xiàn)問題將會導(dǎo)致災(zāi)難性的后果，因此在生產(chǎn)中建議對配置中心做集群，來支持配置中心高可用性。
Spring Cloud Bus
上面的 Refresh 方案雖然可以解決單個微服務(wù)運行期間重載配置信息的問題，但是在真正的實踐生產(chǎn)中，可能會有 N 多的服務(wù)需要更新配置。
如果每次依靠手動 Refresh 將是一個巨大的工作量，這時候 Spring Cloud 提出了另外一個解決方案：Spring Cloud Bus。
Spring Cloud Bus 通過輕量消息代理連接各個分布的節(jié)點。這會用在廣播狀態(tài)的變化（例如配置變化）或者其它的消息指令中。
Spring Cloud Bus 的一個核心思想是通過分布式的啟動器對 Spring Boot 應(yīng)用進行擴展，也可以用來建立一個或多個應(yīng)用之間的通信頻道。目前唯一實現(xiàn)的方式是用 AMQP 消息代理作為通道。
Spring Cloud Bus 是輕量級的通訊組件，也可以用在其它類似的場景中。**有了 Spring Cloud Bus 之后，當(dāng)我們改變配置文件提交到版本庫中時，會自動的觸發(fā)對應(yīng)實例的Refresh，**具體的工作流程如下：
服務(wù)網(wǎng)關(guān)
在微服務(wù)架構(gòu)模式下，后端服務(wù)的實例數(shù)一般是動態(tài)的，對于客戶端而言很難發(fā)現(xiàn)動態(tài)改變的服務(wù)實例的訪問地址信息。
因此在基于微服務(wù)的項目中為了簡化前端的調(diào)用邏輯，通常會引入 API Gateway 作為輕量級網(wǎng)關(guān)，同時 API Gateway 中也會實現(xiàn)相關(guān)的認(rèn)證邏輯從而簡化內(nèi)部服務(wù)之間相互調(diào)用的復(fù)雜度。
Spring Cloud 體系中支持 API Gateway 落地的技術(shù)就是 Zuul。Spring Cloud Zuul 路由是微服務(wù)架構(gòu)中不可或缺的一部分，提供動態(tài)路由，監(jiān)控，彈性，安全等的邊緣服務(wù)。
Zuul 是 Netflix 出品的一個基于 JVM 路由和服務(wù)端的負(fù)載均衡器。
它的具體作用就是服務(wù)轉(zhuǎn)發(fā)，接收并轉(zhuǎn)發(fā)所有內(nèi)外部的客戶端調(diào)用。使用 Zuul 可以作為資源的統(tǒng)一訪問入口，同時也可以在網(wǎng)關(guān)做一些權(quán)限校驗等類似的功能。
鏈路跟蹤
隨著服務(wù)數(shù)量越來越多，對調(diào)用鏈的分析會越來越復(fù)雜，如服務(wù)之間的調(diào)用關(guān)系、某個請求對應(yīng)的調(diào)用鏈、調(diào)用之間消費的時間等，對這些信息進行監(jiān)控就成為一個問題。
在實際的使用中，我們需要監(jiān)控服務(wù)和服務(wù)之間通訊的各項指標(biāo)，這些數(shù)據(jù)將是我們改進系統(tǒng)架構(gòu)的主要依據(jù)。
因此分布式的鏈路跟蹤就變的非常重要，Spring Cloud 也給出了具體的解決方案：Spring Cloud Sleuth 和 Zipkin。
Spring Cloud Sleuth 為服務(wù)之間調(diào)用提供鏈路追蹤。通過 Sleuth 可以很清楚的了解到一個服務(wù)請求經(jīng)過了哪些服務(wù)，每個服務(wù)處理花費了多長時間。從而讓我們可以很方便的理清各微服務(wù)間的調(diào)用關(guān)系。
Zipkin 是 Twitter 的一個開源項目，允許開發(fā)者收集 Twitter 各個服務(wù)上的監(jiān)控數(shù)據(jù)，并提供查詢接口。
總結(jié)
我們從整體上來看一下 Spring Cloud 各個組件如何來配套使用。
從上圖可以看出 Spring Cloud 各個組件相互配合，合作支持了一套完整的微服務(wù)架構(gòu)：
Eureka 負(fù)責(zé)服務(wù)的注冊與發(fā)現(xiàn)，很好地將各服務(wù)連接起來。
Hystrix 負(fù)責(zé)監(jiān)控服務(wù)之間的調(diào)用情況，連續(xù)多次失敗進行熔斷保護。
Hystrix dashboard，Turbine 負(fù)責(zé)監(jiān)控 Hystrix 的熔斷情況，并給予圖形化的展示。
Spring Cloud Config 提供了統(tǒng)一的配置中心服務(wù)。
當(dāng)配置文件發(fā)生變化的時候，Spring Cloud Bus 負(fù)責(zé)通知各服務(wù)去獲取最新的配置信息。
所有對外的請求和服務(wù)，我們都通過Zuul來進行轉(zhuǎn)發(fā)，起到 API 網(wǎng)關(guān)的作用。
最后我們使用 Sleuth+Zipkin 將所有的請求數(shù)據(jù)記錄下來，方便我們進行后續(xù)分析。
Spring Cloud 從設(shè)計之初就考慮了絕大多數(shù)互聯(lián)網(wǎng)公司架構(gòu)演化所需的功能，如服務(wù)發(fā)現(xiàn)注冊、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等。
這些功能都是以插拔的形式提供出來，方便我們系統(tǒng)架構(gòu)在演進的過程中，可以合理的選擇需要的組件進行集成，從而在架構(gòu)演進的過程中會更加平滑、順利。
微服務(wù)架構(gòu)是一種趨勢，Spring Cloud 提供了標(biāo)準(zhǔn)化的、全站式的技術(shù)方案，意義可能會堪比當(dāng)前 Servlet 規(guī)范的誕生，有效推進服務(wù)端軟件系統(tǒng)技術(shù)水平的進步。
原文：https://blog.csdn.net/zhangweiwei2020/article/details/78672814
總結(jié)
以上是生活随笔為你收集整理的Spring Cloud（一）：Spring Cloud的优势是什么？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 图像处理网站
- 下一篇： HTML+JavaScript飞机大战小