使用Spring Cloud Netflix技術(shù)棧實施微服務(wù)架構(gòu)

KILLKISS 2017-02-24

展開全文

前言

系統(tǒng)一旦走向分布式，其復(fù)雜程度成倍增長，傳統(tǒng)單體應(yīng)用只考慮業(yè)務(wù)邏輯的開發(fā)方式已經(jīng)不再適用。正因其復(fù)雜性，目前只有業(yè)務(wù)需求大的大型互聯(lián)網(wǎng)公司才會（被迫）采用，而且需要投入大量的技術(shù)力量來開發(fā)基礎(chǔ)設(shè)施，也造成了小公司“用不起”分布式架構(gòu)的情況?，F(xiàn)在這一局面正在逐漸被打破，因為Netflix開源了其經(jīng)過實戰(zhàn)考驗的一系列基礎(chǔ)設(shè)施構(gòu)件，加上spring Cloud的大力支持，開發(fā)分布式系統(tǒng)已經(jīng)不再像以前那樣可怕了。

統(tǒng)一的配置管理

微服務(wù)意味著要將單體應(yīng)用中的業(yè)務(wù)拆分成一個個子服務(wù)，每個服務(wù)的粒度相對較小，因此系統(tǒng)中會出現(xiàn)大量的服務(wù)。由于每個服務(wù)都需要必要的配置信息才能運行，所以一套集中式的、動態(tài)的配置管理設(shè)施是必不可少的。Spring Cloud提供了Config Server來解決這個問題。Config Server的主要功能如下：

集中化的配置文件管理
不再需要在每個服務(wù)部署的機器上編寫配置文件，服務(wù)會向配置中心統(tǒng)一拉取配置自己的信息。
動態(tài)化的配置更新
當配置發(fā)生變動時，服務(wù)不需要重啟即可感知到配置的變化并應(yīng)用新的配置。
將配置信息以HTTP REST接口的形式暴露
這使得非Java語言的服務(wù)也能享受到上面兩點功能。

Config Server的架構(gòu)圖如下：
這里寫圖片描述

工作流程如下：

配置中心感知到配置變化(如，git倉庫發(fā)生commit提交)，向Bus投遞消息
Bus向服務(wù)廣播消息
服務(wù)收到消息后，主動向配置中心拉取新配置并應(yīng)用

其中配置中心可集群部署實現(xiàn)高可用。

服務(wù)的注冊發(fā)現(xiàn)和LB

Spring Cloud Netflix通過Eureka Server實現(xiàn)服務(wù)注冊中心，通過Ribbon實現(xiàn)軟負載均衡：
這里寫圖片描述

Zone

Eureka支持Region和Zone的概念。其中一個Region可以包含多個Zone。Eureka在啟動時需要指定一個Zone名，即當前Eureka屬于哪個zone, 如果不指定則屬于defaultZone。Eureka Client也需要指定Zone, Client(當與Ribbon配置使用時)在向Server獲取注冊列表時會優(yōu)先向自己Zone的Eureka發(fā)請求，如果自己Zone中的Eureka全掛了才會嘗試向其它Zone。當獲取到遠程服務(wù)列表后，Client也會優(yōu)先向同一個Zone的服務(wù)發(fā)起遠程調(diào)用。Region和Zone可以對應(yīng)于現(xiàn)實中的大區(qū)和機房，如在華北地區(qū)有10個機房，在華南地區(qū)有20個機房，那么分別為Eureka指定合理的Region和Zone能有效避免跨機房調(diào)用，同時一個地區(qū)的Eureka壞掉不會導(dǎo)致整個該地區(qū)的服務(wù)都不可用。

Ribbon軟負載均衡

Ribbon在工作時分成兩步，第一步先選擇 Eureka Server, 它優(yōu)先選擇在同一個Zone且負載較少的server, 第二步再根據(jù)用戶指定的策略，在從server取到的服務(wù)注冊列表中選擇一個地址。其中Ribbon提供了三種策略：輪詢、斷路器和根據(jù)響應(yīng)時間加權(quán)。

聲明式HTTP REST客戶端Feign

Feign與Apache Http Client這類客戶端最大的不同，是它允許你通過定義接口的形式構(gòu)造HTTP請求，不需要手動拼參數(shù)，使用起來與正常的本地調(diào)用沒有什么區(qū)別：

@FeignClient(name = "ea")
public interface AdvertGroupRemoteService {

    @RequestMapping(value = "/group/{groupId}", method = RequestMethod.GET)
    AdvertGroupVO findByGroupId(@PathVariable("groupId") Integer adGroupId);

}1
2
3
4
5
6
7
1
2
3
4
5
6
7

這里我們只需要調(diào)用AdvertGroupRemoteService.findByGroupId()方法就能完成向目標主機發(fā)HTTP請求并封裝返回結(jié)果的效果。

斷路器、資源隔離與自我修復(fù)

斷路器(Cricuit Breaker)是一種能夠在遠程服務(wù)不可用時自動熔斷(打開開關(guān))，并在遠程服務(wù)恢復(fù)時自動恢復(fù)(閉合開關(guān))的設(shè)施，Spring Cloud通過Netflix的Hystrix組件提供斷路器、資源隔離與自我修復(fù)功能。下面介紹一下在分布式系統(tǒng)中為什么需要斷路器。

在微服務(wù)架構(gòu)中，對于客戶端的一個請求，我們可能需要調(diào)用多個子(微)服務(wù)，如圖所示：
圖片來自Hystrix官方文檔

上圖中的請求需要調(diào)用A, P, H, I 四個服務(wù)，如果一切順利則沒有什么問題，關(guān)鍵是如果I服務(wù)超時會出現(xiàn)什么情況呢？
這里寫圖片描述

當服務(wù)I由于某種原因無法響應(yīng)時，用戶請求就會卡在服務(wù) I 的遠程調(diào)用上，假如超時失敗時間設(shè)置為2秒，那么在這2秒內(nèi)容器的當前線程就會一直被堵塞在該調(diào)用中。我們假設(shè)容器最大線程數(shù)為100, 如果此時又有另外99個請求都需要調(diào)用服務(wù) I, 那么這99個線程同樣會被堵塞，這樣就會因為容器線程耗盡而導(dǎo)致該應(yīng)用無法響應(yīng)其它任何請求。因為一個服務(wù)掛掉而導(dǎo)致整個應(yīng)用不可用顯然是無法接受的。那么 Hystrix 是如何解決這個問題的呢？

資源隔離

首選，Hystrix對每一個依賴服務(wù)都配置了一個線程池，對依賴服務(wù)的調(diào)用會在線程池中執(zhí)行。例如，我們設(shè)計服務(wù) I 的線程池大小為20, 那么 Hystrix會最多允許有20個容器線程調(diào)用服務(wù) I, 如果超出20，Hystrix會拒絕并快速失敗。這樣即使服務(wù) I 長時間未響應(yīng)，容器最多也只能堵塞20個線程，剩余80個線程仍然可以處理用戶請求。

快速失敗

快速失敗是防止資源耗盡的關(guān)鍵一點。當 Hystrix 發(fā)現(xiàn)在過去某段時間內(nèi)對服務(wù) I 的調(diào)用出錯率達到某個閥值時，Hystrix 就會“熔斷”該服務(wù)，后續(xù)任何向服務(wù) I 的請求都會快速失敗，而不是白白讓調(diào)用線程去等待。

自我修復(fù)

處于熔斷狀態(tài)的服務(wù)，在經(jīng)過一段時間后，Hystrix會讓其進入“半關(guān)閉”狀態(tài)，即允許少量請求通過，然后統(tǒng)計調(diào)用的成功率。如果這個請求都能成功，Hystrix 會恢復(fù)該服務(wù)，從而達到自我修復(fù)的效果。其中，在服務(wù)被熔斷到進入半關(guān)閉狀態(tài)之間的時間，就是留給開發(fā)人員排查錯誤并恢復(fù)故障的時間，開發(fā)人員可以通過監(jiān)控措施得到提醒并線上排查。

監(jiān)控方案

監(jiān)控是保障分布式系統(tǒng)健康運行必不可少的方案?；赟pring Cloud，我們可以從兩個緯度進行監(jiān)控：Hystrix斷路器的監(jiān)控和每個服務(wù)監(jiān)控狀況的監(jiān)控。

下圖是 Hystrix 提供的 Dashboard 圖形化監(jiān)控:
這里寫圖片描述
可見圖中監(jiān)控信息應(yīng)有盡有（調(diào)用成功率、平時響應(yīng)時間、調(diào)用頻次、斷路器狀態(tài)等）。我們可以通過編程的方式定時獲取該信息，并在斷路器熔斷時通過短信、郵件等方式通知開發(fā)者。

Hystrix的監(jiān)控數(shù)據(jù)默認是保存在每個實例的內(nèi)存中的，Spring Boot提供了多種方式，可以導(dǎo)入到Redis、TSDB以供日后分析使用。

除此之外，Spring Cloud還提供了對單個實例的監(jiān)控：
這里寫圖片描述

其中包含了接口調(diào)用頻次，響應(yīng)時間，JVM狀態(tài)，動態(tài)日志等各種開發(fā)者關(guān)心的信息。

總結(jié)

以上是Spring Cloud Netflix為微服務(wù)架構(gòu)提供的支持，Spring Cloud項目還有許多其它子項目有著更強大的功能，通過這些組件，我們能以 Spring Boot 簡潔的風格快速搭建微服務(wù)架構(gòu)，并讓開發(fā)人員專注于業(yè)務(wù)，讓分布式對開發(fā)者盡量透明。

歡迎訪問Spring Cloud論壇交流經(jīng)驗：http://bbs./

前言

系統(tǒng)一旦走向分布式，其復(fù)雜程度成倍增長，傳統(tǒng)單體應(yīng)用只考慮業(yè)務(wù)邏輯的開發(fā)方式已經(jīng)不再適用。正因其復(fù)雜性，目前只有業(yè)務(wù)需求大的大型互聯(lián)網(wǎng)公司才會（被迫）采用，而且需要投入大量的技術(shù)力量來開發(fā)基礎(chǔ)設(shè)施，也造成了小公司“用不起”分布式架構(gòu)的情況。現(xiàn)在這一局面正在逐漸被打破，因為Netflix開源了其經(jīng)過實戰(zhàn)考驗的一系列基礎(chǔ)設(shè)施構(gòu)件，加上spring Cloud的大力支持，開發(fā)分布式系統(tǒng)已經(jīng)不再像以前那樣可怕了。