邊做邊學，基於Spring Cloud的微服務架構最佳實踐

本文節選自開源無伺服器PaaSRainbond文檔，原文請戳鏈接

概述

微服務是可以獨立部署、水平擴展、獨立訪問（或者有獨立的資料庫）的服務單元，Spring Cloud則是用來管理微服務的一系列框架的有序集合。利用Spring Boot的開發便利性，Spring Cloud巧妙簡化了分散式系統基礎設施的開發，例如服務發現註冊、配置中心、消息匯流排、負載均衡、斷路器等，都可以用Spring Boot的開發風格做到一鍵啟動和部署。

Spring Cloud並沒有重複造輪子，而是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝，屏蔽掉了複雜的配置和實現原理，最終為開發者提供了一套簡單易懂、易部署、易維護的分散式系統開發工具包。

Spring Cloud有很多組件，其中最核心的組件有：Eureka（註冊中心）、Hystrix（斷路器）、Config（配置中心）、Zuul（代理、網關）等等。

接下來，我們不妨通過幾個demo來了解Spring Cloud是如何一步步構建起來的。

示例源碼請戳源碼

如何搭建Eureka

如何搭建Hystrix

如何搭建Config

如何搭建Zuul

如何搭建Eureka

組件介紹

註冊中心Eureka是一個基於REST的服務，用於各個服務之間的互相發現。任何服務需要其它服務的支持都需要通過它獲取；同樣的，所有的服務都需要來這裡註冊，方便以後其它服務來調用。Eureka的好處是你不需要知道找什麼服務，只需要到註冊中心來獲取，也不需要知道提供支持的服務在哪裡、是幾個服務來支持的，直接來這裡獲取就可以了。如此一來，便提升了穩定性，也降低了微服務架構搭建的難度。

項目描述

正常調用服務A請求服務B：

有了服務中心之後，服務A不能直接調用服務B，而是A,B通過在註冊中心中註冊服務，然後互相發現，服務A通過註冊中心來調用服務B：

以上只是2個服務之間的相互調用，如果有十幾個甚至幾十個服務，其中任何的一個項目改動，就可能牽連到好幾個項目的重啟，很麻煩而且容易出錯。通過註冊中心來獲取服務，你不需要關注你調用的項目IP地址，由幾台伺服器組成，每次直接去註冊中心獲取可以使用的服務去調用既可。

部署到雲幫

註冊服務

1、pom中添加依賴

2、添加啟動代碼中添加註解

3、配置文件

在默認設置下，該服務註冊中心也會將自己作為客戶端來嘗試註冊它自己，所以我們需要禁用它的客戶端註冊行為，在添加以下配置：

：表示是否將自己註冊到Eureka Server，默認為true。

：表示是否從Eureka Server獲取註冊信息，默認為true。

：設置與Eureka Server交互的地址，查詢服務和註冊服務都需要依賴這個地址。默認是http://localhost:8761/eureka；多個地址可使用 , 分隔。

啟動工程後，訪問：http://localhost:8000/，可以看到下面的頁面，其中還沒有發現任何服務

服務提供者(B)

1、pom包配置

創建一個springboot項目，pom.xml中添加如下配置：

2、配置文件

application.properties配置如下：

3、啟動類

啟動類中添加註解

4、服務提供

提供hello服務：

添加註解後，項目就具有了服務註冊的功能。啟動工程後，就可以在註冊中心的頁面看到SPRING-CLOUD-PRODUCER服務。

到此服務提供者配置就完成了。

服務消費者（A）

1、pom包配置

和服務提供者一致

2、配置文件

application.properties配置如下：

3、啟動類

啟動類添加和註解：

:啟用服務註冊與發現

：啟用feign進行遠程調用

Feign是一個聲明式Web Service客戶端。使用Feign能讓編寫Web Service客戶端更加簡單, 它的使用方法是定義一個介面，然後在上面添加註解，同時也支持JAX-RS標準的註解。Feign也支持可拔插式的編碼器和解碼器。Spring Cloud對Feign進行了封裝，使其支持了Spring MVC標準註解和HttpMessageConverters。Feign可以與Eureka和Ribbon組合使用以支持負載均衡。

4、feign調用實現

name:遠程服務名，及spring.application.name配置的名稱

此類中的方法和遠程服務中contoller中的方法名和參數需保持一致。

5、web層調用遠程服務

將HelloRemote注入到controller層，像普通方法一樣去調用即可。

到此，最簡單的一個服務註冊與調用的例子就完成了。

測試

依次啟動spring-cloud-eureka、spring-cloud-producer、spring-cloud-consumer三個項目。

先輸入： 檢查spring-cloud-producer服務是否正常

返回：

說明spring-cloud-producer正常啟動，提供的服務也正常。

瀏覽器中輸入：

返回：

說明客戶端已經成功的通過feign調用了遠程服務hello，並且將結果返回到了瀏覽器。

{}

部署在雲幫，需要驗證必須保證一下3點：

埠開啟了功能

consumer關聯了producer

和添加在所產生的url後

之後組件的驗證同理。

如何搭建Hystrix

組件介紹

在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務雪崩效應。而使用Hystrix(熔斷器)就可以避免這種問題。

熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，會強迫其以後的多個調用快速失敗，不再訪問遠程伺服器，從而防止應用程序不斷地嘗試執行可能會失敗的操作，使得應用程序繼續執行而不用等待修正錯誤，或者浪費CPU時間去等到長時間的超時產生。熔斷器也可以使應用程序能夠診斷錯誤是否已經修正，如果已經修正，應用程序會再次嘗試調用操作。

當Hystrix Command請求後端服務失敗數量超過一定比例(默認50%), 斷路器會切換到開路狀態(Open). 這時所有請求會直接失敗而不會發送到後端服務. 斷路器保持在開路狀態一段時間後(默認5秒), 自動切換到半開路狀態(HALF-OPEN). 這時會判斷下一次請求的返回情況, 如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN). Hystrix的斷路器就像我們家庭電路中的保險絲, 一旦後端服務不可用, 斷路器會直接切斷請求鏈, 避免發送大量無效請求影響系統吞吐量, 並且斷路器有自我檢測並恢復的能力。

項目描述

通過將Hystrix組件添加到服務消費者，實現熔斷效果，只需要在Eureka的demo基礎加入Hystrix即可。

Hystrix是作用在服務調用端的，因此需要添加在A上。

部署到Rainbond

Hystrix服務

因為熔斷只是作用在服務調用這一端，因此我們根據上一篇的示例代碼只需要改動消費者（A）服務相關代碼就可以。因為，Feign中已經依賴了Hystrix所以在maven配置上不用做任何改動。

1、配置文件

application.properties添加這一條：

2、創建回調類

創建HelloRemoteHystrix類繼承與HelloRemote實現回調的方法：

3、添加fallback屬性

在類添加指定fallback類，在服務熔斷的時候返回fallback類中的內容：

4、測試

那我們就來測試一下看看效果吧。

依次啟動spring-cloud-eureka、spring-cloud-producer、spring-cloud-consumer三個項目。

瀏覽器中輸入：

返回：

說明加入熔斷相關信息後，不影響正常的訪問。接下來我們手動停止spring-cloud-producer項目再次測試：

瀏覽器中輸入：

返回：

根據返回結果說明熔斷成功。

如何搭建Config

組件介紹

業務描述

目前Config支持git和svn作為存放配置文件的倉庫，本次示例使用git倉庫來存放配置文件。這裡的Config-client 就相當於服務A和服務B,他們的配置文件都集中存放，通過Config-server來獲取各自的配置文件。

部署到Rainbond

git倉庫

首先在github上面創建了一個文件夾config-repo用來存放配置文件，為了模擬生產環境，我們創建以下三個配置文件：

每個配置文件中都寫一個屬性neo.hello,屬性值分別是 hello im dev/test/pro 。下面我們開始配置server端

config-server端

1、添加依賴

只需要加入spring-cloud-config-server包引用既可。

2、配置文件

Spring Cloud Config也提供本地存儲配置的方式。我們只需要設置屬性，Config Server會默認從應用的目錄下檢索配置文件。也可以通過屬性來指定配置文件的位置。雖然Spring Cloud Config提供了這樣的功能，但是為了支持更好的管理內容和版本控制的功能，還是推薦使用git的方式。

3、啟動類

啟動類添加，激活對配置中心的支持

到此server端相關配置已經完成

4、測試server端

首先我們先要測試server端是否可以讀取到github上面的配置信息，直接訪問：

返回信息如下：

上述的返回的信息包含了配置文件的位置、版本、配置文件的名稱以及配置文件中的具體內容，說明server端已經成功獲取了git倉庫的配置信息。

如果直接查看配置文件中的配置信息可訪問：，返回：

修改配置文件中配置信息為：,再次在瀏覽器訪問，返回：。說明server端會自動讀取最新提交的內容

倉庫中的配置文件會被轉換成web介面，訪問可以參照以下的規則：

//[/]

/-.yml

//-.yml

/-.properties

//-.properties

以neo-config-dev.properties為例子，它的application是neo-config，profile是dev。client會根據填寫的參數來選擇讀取對應的配置。

Config-client端

主要展示如何在業務項目中去獲取server端的配置信息

1、添加依賴

引入spring-boot-starter-web包方便web測試

2、配置文件

需要配置兩個配置文件，application.properties和bootstrap.properties

application.properties如下：

bootstrap.properties如下：

spring.application.name：對應部分

spring.cloud.config.profile：對應部分

spring.cloud.config.label：對應git的分支。如果配置中心使用的是本地存儲，則該參數無用

spring.cloud.config.uri：配置中心的具體地址

spring.cloud.config.discovery.service-id：指定配置中心的service-id，便於擴展為高可用配置集群。

上面這些與spring-cloud相關的屬性必須配置在bootstrap.properties中，config部分內容才能被正確載入。因為config的相關配置會先於application.properties，而bootstrap.properties的載入也是先於application.properties。

3、啟動類

啟動類添加，激活對配置中心的支持

啟動類只需要註解就可以

4、web測試

使用註解來獲取server端參數的值

啟動項目後訪問：，返回：說明已經正確的從server端獲取到了參數。到此一個完整的服務端提供配置服務，客戶端獲取配置參數的例子就完成了。

如何搭建Zuul

組件介紹

在微服務架構中，後端服務往往不直接開放給調用端，而是通過一個API網關根據請求的url，路由到相應的服務。當添加API網關後，在第三方調用端和服務提供方之間就創建了一面牆，這面牆直接與調用方通信進行許可權控制，後將請求均衡分發給後台服務端。而用來進行代理調度的組件就是Zuul。

項目描述

在項目中，只有Zuul提供對外訪問，Gateway通過請求的url的不同，將請求調度到不同的後端服務

部署到Rainbond

Gateway

1、添加依賴

引入包

2、配置文件

3、啟動類

啟動類添加，支持網關路由。

4、測試

啟動項目，先輸入：

返回：

說明調度成功。

小結

至此，我們就完成了Eureka、Hystrix、Config、Zuul等幾個Spring Cloud最核心組件的搭建，更多內容敬請關注Rainbond文檔。

或參考雲框架項目，[雲框架]基於Spring Cloud的微服務架構。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！