Spring Cloud 是一個基于 Spring Boot 實現(xiàn)的微服務(wù)框架，它包含了實現(xiàn)微服務(wù)架構(gòu)所需的各種組件。

鹽城網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)公司從2013年成立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)公司。

注：Spring Boot 簡單理解就是簡化 Spring 項目的搭建、配置、組合的框架。因為與構(gòu)建微服務(wù)本身沒有直接關(guān)系，所以本文不對 Spring Boot 進行展開。另外本文有一些例子涉及到 Spring 和 Spring Boot，建議先了解一下 Spring 和 Spring Boot 再閱讀本文。 本文的閱讀對象主要是沒有接觸過服務(wù)架構(gòu)，想對其有一個宏觀的了解的同學(xué)。

本文將從 Spring Cloud 出發(fā)，分兩小節(jié)講述微服務(wù)框架的「五臟六腑」：

第一小節(jié)「服務(wù)架構(gòu)」旨在說明的包括兩點，一服務(wù)架構(gòu)是什么及其必要性；二是服務(wù)架構(gòu)的基本組成。為什么第一節(jié)寫服務(wù)架構(gòu)而不是微服務(wù)架構(gòu)呢？原因主要是微服務(wù)架構(gòu)本身與服務(wù)架構(gòu)有著千絲萬縷的關(guān)系，服務(wù)架構(gòu)是微服務(wù)架構(gòu)的根基。 第二小節(jié)「五臟六腑」則將結(jié)合 Spring Cloud 這個特例來介紹一個完整的微服務(wù)框架的組成。 「服務(wù)架構(gòu)」 為了方便理解，我先講一個小故事：（改編自一知乎答主）

Martin（微服務(wù)提出者也叫 Martin）剛來到公司時是一個基層員工，它上面有經(jīng)理、老板，那個時候所有人都聽老板的指揮。

但是過了兩年，公司的人越來越多，原來的模式下整個公司的運作效率太低，管理也很混亂。

于是已經(jīng)踏上中層崗位的 Martin 建議老板進行部門劃分（服務(wù)化），專門的部門只做專門的事情（單一職責(zé)）。例如研發(fā)部門只做研發(fā)，人事部門只做招聘。

老板聽取了 Martin 的意見，對公司的組織架構(gòu)進行了調(diào)整。

有一天，Martin 發(fā)現(xiàn)公司的部門越來越多，各個部門并不能完全知道對方所做的事情，這對跨部門協(xié)作（服務(wù)調(diào)用）帶來了困難。

行政部門會（注冊中心）來記錄所有的部門，每當(dāng)有新的部門行政都會記錄下來（服務(wù)注冊），然后公布出來讓所有部門知道（服務(wù)發(fā)現(xiàn)）。

在新的組織架構(gòu)下，公司的效率逐步提高。老板也給 Martin 發(fā)了大量獎金作為獎勵，Martin 從此贏取白富美走向了人生巔峰。

這是一個公司組織架構(gòu)演變的故事，主要講的是隨著公司規(guī)模的擴大，組織從集中化管理到分布化管理的過程。

映射到我們的信息系統(tǒng)里來也是一樣的，隨著我們的系統(tǒng)越來越復(fù)雜，變得難以管理，也有人想到去拆分然后治理。在解決復(fù)雜問題上，分治可以說是一個屢試不爽的辦法。

服務(wù)化即是拆解的一種手段。而上面圓括號里面的內(nèi)容其實就對應(yīng)了一個服務(wù)化架構(gòu)的最小組成元素，分別是服務(wù)、服務(wù)調(diào)用、注冊中心、服務(wù)注冊、服務(wù)發(fā)現(xiàn)。有了這些基本的組成要素，就可以實現(xiàn)一個最簡單的服務(wù)架構(gòu)。

面向服務(wù)的架構(gòu)和微服務(wù)架構(gòu) 面向服務(wù)的架構(gòu)（SOA）和微服務(wù)架構(gòu)是目前兩種主流的服務(wù)化架構(gòu)，都符合上面的例子，也有上面提到的所有組件。這兩種服務(wù)架構(gòu)有很多可以講的，但是與本文的相關(guān)性不大，本文不做會過多展開，只簡單介紹一下兩者的區(qū)別。

準(zhǔn)確地說微服務(wù)是去 ESB（企業(yè)服務(wù)總線）的 SOA。ESB 借鑒了計算機組成原理中的通信模型 —— 總線，所有需要和外部系統(tǒng)通信的系統(tǒng)，通過 ESB 進行標(biāo)準(zhǔn)化地轉(zhuǎn)換從而消除協(xié)議、異構(gòu)系統(tǒng)之間的差異，這樣就可以利用現(xiàn)有的系統(tǒng)構(gòu)建一個全新的松耦合的異構(gòu)的分布式系統(tǒng)。微服務(wù)架構(gòu)去掉 ESB，本質(zhì)上是一種去中心化的思想。

「五臟六腑」 「心臟」 順著上一節(jié)的思路，從最簡單、最核心的問題出發(fā)，假設(shè)服務(wù) A 要調(diào)用服務(wù) B，會有什么問題？

服務(wù)在哪？（服務(wù)治理問題） 怎么調(diào)用？（服務(wù)調(diào)用問題） 這兩個是最核心的問題，也是任何微服務(wù)框架首要解決的兩個問題。

為了解決第一個問題 Spring Cloud 提供了 Eureka、Zookeeper、Cloud Foundry、Consul 等服務(wù)治理框架的集成。它們的工作模式是將所有的微服務(wù)注冊到一個 Server 上，然后通過心跳進行服務(wù)健康監(jiān)測。這樣服務(wù) A 調(diào)用 B 時可以從注冊中心拿到可用的服務(wù) B 的地址、端口進行調(diào)用。

第二個服務(wù)調(diào)用有人可能認(rèn)為就是一個簡單的 HTTP 或者 RPC 調(diào)用，不是什么問題。但是在分布式的場景下，服務(wù)調(diào)用需要考慮的因素會更多。比如一個服務(wù)有多個實例，此時請求進來了交給誰處理，請求的負(fù)載怎么平衡到各個實例，都是比較棘手的問題。Spring Cloud 提供了兩種服務(wù)調(diào)用的方式：一種是 Ribbon + restTemplate，另一種是 Feign。

其中 Ribbon 是基于 HTTP 和 TCP 客戶端的負(fù)載均衡器，restTemplate 是 Spring 提供的 Restful 遠(yuǎn)程調(diào)用的模板，兩者結(jié)合就可以達到遠(yuǎn)程調(diào)用的負(fù)載均衡。

而 Feign 是一個更加聲明式的 HTTP 客戶端，開發(fā)者可以像調(diào)用本地方法一樣調(diào)用它，完全感覺不到是遠(yuǎn)程調(diào)用，結(jié)合 Ribbon 也可以做負(fù)載均衡。

既然兩個問題都得到了解決，我們就用一個例子來進一步說明一下，例子包含了微服務(wù)中最基本的三個角色（注冊中心、服務(wù)提供者、服務(wù)消費者)：

注冊中心 注解 @EnableEurekaServer 表示該 Spring Boot 應(yīng)用是一個注冊中心。

cdn.xitu.io/2019/3/5/1694dff37558155e?imageView2/0/w/1280/h/960/format/webp/ignore-error/1">

eureka.client.registerWithEureka: false 和fetchRegistry: false 來表明自己是一個 eureka server。

service-hello 服務(wù) 注解 @EnableEurekaClient 表示他是一個 Eureka 客戶端，它會在注冊中心注冊自己。

注解 @RestController 表示這是一個控制器，@RequestMapping("/hello") 表示匹配到請求 '/hello' 時會調(diào)用該方法進行響應(yīng)。

注冊中心的地址為 http://localhost:8080/eureka/，也就是上面我們定義的。服務(wù)名為 service-hello，將會被調(diào)用者使用。

eureka:

服務(wù)消費者 service-ribbon 假設(shè) service-ribbon 端口為 8082，當(dāng)我們訪問 http://localhost:8080/hello 時，HelloControler 接收到請求，并調(diào)用 HelloService 中的 helloService 方法，HelloService 中通過定義的 restTemplate 去調(diào)用 http://service-hello/hello。此處要注意的是 @LoadBalanced 注解，它表示啟用負(fù)載均衡。

至此其實一個微服務(wù)應(yīng)用的雛形已經(jīng)搭建出來了，服務(wù)治理、服務(wù)調(diào)用可以說是「五臟六腑」中的「心臟」。

「心臟」的依托 接下來我們要進一步思考的是「五臟六腑」中其余的部分，因為少了它們?nèi)艘彩腔畈痪玫?。下面通過一個問題或需求對應(yīng)一個組件的方式進行介紹。

服務(wù)“雪崩”與斷路器 由于網(wǎng)絡(luò)等原因，服務(wù)并不能保證 100% 可用，如果單個服務(wù)出現(xiàn)問題，調(diào)用這個服務(wù)就會出現(xiàn)線程阻塞，此時若有大量的請求涌入，Servlet 容器的線程資源會被消耗殆盡，導(dǎo)致服務(wù)癱瘓。

由于服務(wù)與服務(wù)之間存在依賴，故障會在調(diào)用鏈路上傳播，導(dǎo)致整個微服務(wù)系統(tǒng)崩潰，這就是服務(wù)故障的“雪崩”效應(yīng)。

為了解決這個問題，Spring Cloud 提供了對 Hystrix 斷路器的集成，當(dāng)服務(wù)調(diào)用失敗的頻次達到一定閾值，斷路器將被開啟，降級的策略可以開發(fā)者制定，一般是返回一個固定值。這樣就能夠避免連鎖故障。

此外 Spring Cloud 還提供 Hystrix Dashboard 和 Hystrix Turbine，幫助我們進行監(jiān)控和聚合監(jiān)控。

服務(wù)暴露與路由網(wǎng)關(guān) 微服務(wù)中的服務(wù)很多，直接暴露給用戶一是不安全，二是對用戶不友好。因此在微服務(wù)和面向服務(wù)的架構(gòu)中，通常會有一個路由網(wǎng)關(guān)的角色，來負(fù)責(zé)路由轉(zhuǎn)發(fā)和過濾。對應(yīng)到 Spring Cloud 中有 Zuul 和 Gateway 兩個組件可用。

路由網(wǎng)關(guān)接收了所有的用戶請求，有著很高的負(fù)載，因此它通常是一個集群。用戶的請求會先經(jīng)過一層負(fù)載均衡被發(fā)到路由網(wǎng)關(guān)。

服務(wù)配置與配置中心 在微服務(wù)應(yīng)用中，服務(wù)數(shù)量巨多，而每個服務(wù)不同環(huán)境都有著不同的配置，為了方便服務(wù)配置文件統(tǒng)一管理，實時更新，所以需要分布式配置中心組件。需要注意的是此處的配置與注冊中心注冊的配置信息是兩個概念，此處的配置是服務(wù)本身的一些配置信息，如下圖：

Spring Cloud 提供了 Spring Cloud Config 組件，它支持配置服務(wù)放在配置服務(wù)的內(nèi)存中（即本地），也支持放在遠(yuǎn)程 Git 倉庫中，幫助我們管理服務(wù)的配置信息。

信息同步與消息總線 前一個問題講到了每個服務(wù)都有一些配置信息，那么配置信息更新了我們該怎么辦，手動一個個去更新？當(dāng)然不是，Spring Cloud 提供了 Spring Cloud Bus 組件，它通過輕量消息代理連接各個分布的節(jié)點。當(dāng)配置信息更新的時候，我們只要更新一個節(jié)點的配置，這個更新就會被廣播到這個分布式系統(tǒng)中。

問題定位與鏈路追蹤 在微服務(wù)系統(tǒng)中，服務(wù)之間可以相互調(diào)用，因此我們一個請求可能會一條調(diào)用鏈，而整個系統(tǒng)會存在一張調(diào)用網(wǎng)，其中任意一個服務(wù)調(diào)用失敗或網(wǎng)絡(luò)超時都可能導(dǎo)致整個請求失敗。因為調(diào)用關(guān)系的復(fù)雜，這給問題的定位造成了極大的困難，這也是必須提供服務(wù)鏈路追蹤的原因。

Spring Cloud 為我們提供了 Spring Cloud Sleuth 組件，它能夠跟進一個請求到底有哪些服務(wù)參與，參與的順序是怎樣的，從而達到每個請求的步驟清晰可見。借助服務(wù)鏈路追蹤，我們可以快速定位問題。

至此，Spring Cloud 的所有基礎(chǔ)組件都介紹完了。但是目前所有的組件介紹都是分散的，它們組合起來，完整的樣子是什么樣的？如下圖：

偷懶偷了張圖，圖中漏掉了 Config Server 和鏈路追蹤組件。但是結(jié)合上文的介紹，我們大致可以腦補出這兩個東西在圖中的位置。Config Server 是一個與所有服務(wù)相連的服務(wù)集群，鏈路追蹤組件則集成在每個服務(wù)中。

小結(jié) 服務(wù)治理為心臟，路由網(wǎng)關(guān)、消息中心、斷路器、鏈路追蹤、配置中心等為依托，構(gòu)造了整個微服務(wù)框架的「五臟六腑」。當(dāng)然，一個微服務(wù)系統(tǒng)遠(yuǎn)比本文所寫的復(fù)雜得多，尤其是在不同的業(yè)務(wù)場景之下，因此想要更深入地了解它就需要我們不斷地去實踐。而作為前端，我了解這些內(nèi)容一是為了更好地了解整個請求的流程，二是為了后續(xù)在 SOA 中接入 Node 子服務(wù)積累相關(guān)知識。

最后分享一句有趣的調(diào)侃 Spring 的話：在 Spring 中沒有什么是一個注解解決不了的，如果有，那么就用兩個注解。