Spring Cloud 理論篇

微服務

在 jsp 時代，應用先後端耦合，先後端 all in 一臺服務器，隨着流量的增大，代碼數量的增長，單體應用再也不適合互聯網的發展，微服務順應提出。

微服務是一種用於構建應用的架構方案。區別於更爲傳統的單體式方案，將應用拆分紅多個核心功能。每一個功能都被稱爲一項服務，能夠單獨構建和部署，這意味着各項服務在工做（和出現故障）時不會相互影響。

參考：https://www.redhat.com/zh/top...

Spring Cloud 版本

在微服務大哥的帶領下，各類架構層出不窮，有 Dubbo、gRPC、Thrift、SpringCloud 等等，其中 Spring Cloud 背靠 Spring 生態，脫穎而出。Spring Cloud 框架是在 Springboot 框架基礎上編寫的，所以在技術選型的時候，咱們須要注意 Spring Cloud 版本要與 Springboot 版本對應。

Spring Cloud 社區活躍，已經出了好幾個版本，生命力旺盛。值得一提的是他的版本號。SpringCloud 不是使用數字做爲版本號，而是將倫敦地鐵站做爲版本號，這讓我想起被地鐵支配的恐懼。

目前 SprinCloud官網主推薦版本是 Hoxton SR1。Spring Cloud 與 Spring Boot 有明確的版本對應關係。

Spring Cloud	Spring Boot
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x
Camden	1.4.x
Brixton	1.3.x
Angel	1.2.x

從圖表能夠看出 Spring Cloud 版本號的首字母是按照字母順序排列的。
本文主要介紹的是基於 Spring Boot 1.5.x 的 Dalston 版本的 Spring Cloud。

Spring Cloud 是什麼

Spring boot 是一個身懷絕技的武林高手，能上九天攬月下五洋捉鱉，反正就是牛，他喜歡結交武林各路英雄豪傑，有 MyBatis 、Redis、RabbitMQ、Kafaka、Elasticsearch 等等各路高手，他們喜歡行俠仗義，助人爲樂，慢慢的以 Spring boot 爲大佬的幫派愈來愈多，有一天 Spring boot 和兄弟們說，要不咱們成立一個門派把，就叫 Spring Cloud 。

你們一呼百應。可是成立的門派後，須要管理啊，因此 Spring Cloud 成立了 Eureka 分舵（服務中心），負責對各個分舵同步門派的大事件，有新成員（提供者）加入門派，也須要到 Eureka 分舵報道，其餘分舵（消費者）須要協助，也像 Eureka 分舵請求支援。分舵也培養新分舵，出現了幾個職能相同的分舵（服務帶集羣），Eureka 分舵看到分舵愈來愈多，本身也開始培養新分舵（服務中心集羣）。同時也創建了一個 Ribbon 分舵（客戶端負載均衡），負責對各個分舵進行高效的溝通。 Spring Cloud 門派名聲愈來愈大，加入的人愈來愈多，Spring Cloud 開始成立了 Zuul 分舵（網關），負責對新加入的人員進行篩選。

江湖還在，Spring Cloud 門派也愈來愈強大，處處都是他的傳說

Spring Cloud 與 Dubbo 區別

目前來講，在 Java 領域，微服務主要是 Spring Cloud 和 Dubbo 的天下，所以，人們常常喜歡比較兩種技術，而後選擇其中一種進行搭建。

因爲 Dubbo 是國人開發的，有詳細的開發文檔，在 Spring Cloud 的萌芽時， 國人憑着滿腔熱情大力發展 Dubbo，不斷試坑，後來 Dubbo 發展停滯，Spring Cloud 的春風開始席捲神州大地。不過，目前 Dubbo 又開始轉機，捐給了 Apache 。

技術維度	Dubbo	Spring Cloud
服務註冊中心	Zookeeper	Spring Cloud Netflix Eurrke
服務調用方式	RPC	REST API
服務監控	Dubbo-monitor	spring boot admin
斷路器	不完善	Spirng Cloud Netflix Hystrix
服務網關	無	Spring Cloud Netflix Zuul
分佈式配置	無	Spring Cloud Config

Eureka 組件

Eureka 音譯尤里卡，是 Spring Cloud 的註冊中心。在分佈式系統中，包含不少個節點，這些節點大致分爲消費者和提供者。

服務端和客戶端就是經過 Eureka 進行管理的。舉一個例子，Eureka 就比如小區的快遞箱，快遞就是服務端，取快遞的人就是客戶端。咱們何時能夠取快遞呢，等快遞箱向咱們發送短信，咱們就能夠去取快遞了。這就是 Eureka 的做用。這樣看來服務中心 Eureka 是十分重要的，爲了保證高可用，避免註冊中心掛掉，咱們兩眼一抹黑的尷尬局面，通常來講， Eureka 會作集羣，保證高可用。同理可得，服務中心咱們也須要集羣，保證高可用。

Eureka 做爲 Spring Cloud 框架的註冊中心，與之對應的是 Dubbo 框架的Zookeeper。他倆有什麼區別呢？這裏須要引入一個 CAP 定理。所謂 CAP 定理，分佈式系統的三個指標 C（一致性）、A（可用性）、P（分區容錯性）不能夠同時知足了。

通常來講，分區容錯沒法避免，所以能夠認爲 CAP 的 P 老是成立。CAP 定理告訴咱們，剩下的 C 和 A 沒法同時作到

參考：https://www.ruanyifeng.com/bl...

而 Eureka 的設計原則是 AP，便可用性和分區容錯性。他保證了註冊中心的可用性，但捨棄了數據一致性，各節點上的數據有多是不一致的（會最終一致）。ZK 的設計原則是 CP，即強一致性和分區容錯性。他保證數據的強一致性，但捨棄了可用性，若是出現網絡問題可能會影響 ZK 的選舉，致使 ZK 註冊中心的不可用。

參考：https://www.infoq.cn/article/...*3wtN2PcqTDyokh

Ribbon

微服務劃分紅幾個節點，他們分佈在不一樣的虛擬機，通信就成了一個難點，經過咱們會想到 HttpClient，若是是 Spring的話，咱們能夠用 RestTemplate，可是在集羣環境下，他們並不能作到負載均衡。所以，Ribbon 出現了。Ribbon 是一款在客戶端實行負載均衡的工具。Ribbon 其實現原理就是根據在配置文件中列出的機器，自動按照某種規則（輪詢，隨機）去鏈接這些機器。使用者也能夠自定義本身的負載均衡算法。負載均衡目的是達到高可用。

Feign

Feign 是有一款客戶端負載均衡工具。既然有了 Ribbon ，爲何還要有 Feign 呢？ 在實際使用 Ribbon 組件中，咱們會發現 Ribbon 會讓咱們硬編碼，十分不靈活。所以，在 Ribbon 的基礎下，面向接口編程的 Feign 組件 就出現了。Feign 讓咱們能夠編寫出優雅的代碼，所以，實際中，Feign 獲得大力使用。

Hystrix

Hystrix 是一個用於處理分佈式系統的延遲和容錯的開源庫，在分佈式系統裏，許多依賴不可避免的會調用失敗，好比超時、異常等，Hystrix 可以保證在一個依賴出問題的狀況下，不會致使總體服務失敗，避免級聯故障，以提升分佈式系統的彈性。

Hystrix 斷路器是一種開關裝置，當某個服務單元發生故障以後，經過斷路器的故障監控，向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方沒法處理的異常，這樣就保證了服務調用方不會長時間、沒必要要佔用，從而避免了故障在分佈式系統中的蔓延，乃至雪崩。

提到服務雪崩，咱們能夠經過一張圖來理解。假設咱們有三個服務調用 A B C。當其中下游的 C 服務發生故障，就有可能引發 服務雪崩。爲了解決 服務雪崩，咱們就須要引入 Hystrix 組件。

Hystrix 主要是經過服務熔斷和服務降級來解決服務雪崩問題。那麼問題來了，服務熔斷和服務降級的區別又是什麼？

簡單來講服務熔斷屬於服務降級的一種，而服務降級有不少種降級方式！如開關降級、限流降級、熔斷降級。

參考：https://www.cnblogs.com/rjzhe...

Zuul

Zuul中文是神獸的意思。在Spring Cloud 中，Zuul是一項網關服務，可提供動態路由，監視，彈性，安全性等。

簡單的話，Zuul 就是樓下保安亭的大爺，全部進入大樓的人，都須要大爺檢查，獲得大爺的許可。 咱們能夠經過一張圖理解。

Spring Cloud Config

實際工做中，咱們可能會有幾十上百的微服務節點，每個節點有須要有配置信息，好比數據庫的鏈接，服務中心的地址等等，當中信息變化的時候，咱們可能面臨手動一臺一臺修改的囧境。爲了解決上述問題，咱們可否借鑑 Git 的思想，有一個標準的配置，當咱們配置修改，咱們只須要同步刷新一下便可，不用手動搬運呢？答案是有的，咱們能夠經過 Spring Cloud Config 達到同步更新配置信息。