原文：https://dzone.com/articles/microservice-architecture-with-spring-cloud-and-do
作者：Alexander Lukyanchikov
譯者：Oopsguy
【編者的話】如何使用Spring Boot、Spring Cloud、Docker和Netflix的一些開源工具來構(gòu)建一個(gè)微服務(wù)架構(gòu)。本文通過使用Spring Boot、Spring Cloud和Docker構(gòu)建的概念型應(yīng)用示例，提供了了解常見的微服務(wù)架構(gòu)模式的起點(diǎn)。
該代碼可以在GitHub上獲得，并且在Docker Hub上提供了鏡像。您只需要一個(gè)命令即可啟動(dòng)整個(gè)系統(tǒng)。
我選擇了一個(gè)老項(xiàng)目作為這個(gè)系統(tǒng)的基礎(chǔ)，它的后端以前是單一應(yīng)用。此應(yīng)用提供了處理個(gè)人財(cái)務(wù)、整理收入開銷、管理儲(chǔ)蓄、分析統(tǒng)計(jì)和創(chuàng)建簡(jiǎn)單預(yù)測(cè)等功能。
功能服務(wù)
整個(gè)應(yīng)用分解為三個(gè)核心微服務(wù)。它們都是可以獨(dú)立部署的應(yīng)用，圍繞著某些業(yè)務(wù)功能進(jìn)行組織。
賬戶服務(wù)
包含一般用戶輸入邏輯和驗(yàn)證：收入/開銷記錄、儲(chǔ)蓄和賬戶設(shè)置。
統(tǒng)計(jì)服務(wù)
計(jì)算主要的統(tǒng)計(jì)參數(shù)，并捕獲每一個(gè)賬戶的時(shí)間序列。數(shù)據(jù)點(diǎn)包含基于貨幣和時(shí)間段正常化后的值。該數(shù)據(jù)可用于跟蹤賬戶生命周期中的現(xiàn)金流量動(dòng)態(tài)。
通知服務(wù)
存儲(chǔ)用戶的聯(lián)系信息和通知設(shè)置（如提醒和備份頻率）。安排工作人員從其它服務(wù)收集所需的信息并向訂閱的客戶發(fā)送電子郵件。
注意
每一個(gè)微服務(wù)擁有自己的數(shù)據(jù)庫(kù)，因此沒有辦法繞過API直接訪問持久數(shù)據(jù)。
在這個(gè)項(xiàng)目中，我使用MongoDB作為每一個(gè)服務(wù)的主數(shù)據(jù)庫(kù)。擁有一個(gè)多種類持久化架構(gòu)（polyglot persistence architecture）也是很有意義的。
服務(wù)間（Service-to-service）通信是非常簡(jiǎn)單的：微服務(wù)僅使用同步的REST API進(jìn)行通信。現(xiàn)實(shí)中的系統(tǒng)的常見做法是使用互動(dòng)風(fēng)格的組合。例如，執(zhí)行同步的GET請(qǐng)求檢索數(shù)據(jù)，并通過消息代理（broker）使用異步方法執(zhí)行創(chuàng)建/更新操作，以便解除服務(wù)和緩沖消息之間的耦合。然而，這帶給我們是最終的一致性。
基礎(chǔ)設(shè)施服務(wù)
分布式系統(tǒng)中常見的模式，可以幫助我們描述核心服務(wù)是怎樣工作的。Spring Cloud提供了強(qiáng)大的工具，可以增強(qiáng)Spring Boot應(yīng)用的行為來實(shí)現(xiàn)這些模式。我會(huì)簡(jiǎn)要介紹一下：
配置服務(wù)
Spring Cloud Config是分布式系統(tǒng)的水平擴(kuò)展集中式配置服務(wù)。它使用了當(dāng)前支持的本地存儲(chǔ)、Git和Subversion等可拔插存儲(chǔ)庫(kù)層（repository layer）。
在此項(xiàng)目中，我使用了native profile，它簡(jiǎn)單地從本地classpath下加載配置文件。您可以在配置服務(wù)資源中查看shared目錄。現(xiàn)在，當(dāng)通知服務(wù)請(qǐng)求它的配置時(shí)，配置服務(wù)將響應(yīng)回shared/notification-service.yml和shared/application.yml（所有客戶端應(yīng)用之間共享）。
客戶端使用
只需要使用sprng-cloud-starter-config依賴構(gòu)建Spring Boot應(yīng)用，自動(dòng)配置將會(huì)完成其它工作。
現(xiàn)在您的應(yīng)用中不需要任何嵌入的properties，只需要提供有應(yīng)用名稱和配置服務(wù)url的bootstrap.yml即可：
spring:
application:
name: notification-service
cloud:
config:
uri: http://config:8888
fail-fast: true
使用Spring Cloud Config，您可以動(dòng)態(tài)更改應(yīng)用配置
比如，EmailService bean使用了@RefreshScope注解。這意味著您可以更改電子郵件的內(nèi)容和主題，而無需重新構(gòu)建和重啟通知服務(wù)應(yīng)用。
首先，在配置服務(wù)器中更改必要的屬性。然后，對(duì)通知服務(wù)執(zhí)行刷新請(qǐng)求：curl -H "Authorization: Bearer #token#" -XPOST http://127.0.0.1:8000/notifications/refresh。
您也可以使用webhook來自動(dòng)執(zhí)行此過程。
注意
動(dòng)態(tài)刷新存在一些限制。@RefreshScope不能和@Configuraion類一同工作，并且不會(huì)作用于@Scheduled方法。
fail-fast屬性意味著如果Spring Boot應(yīng)用無法連接到配置服務(wù)，將會(huì)立即啟動(dòng)失敗。當(dāng)您一起啟動(dòng)所有應(yīng)用時(shí)，這非常有用。
下面有重要的安全提示
授權(quán)服務(wù)
負(fù)責(zé)授權(quán)的部分被完全提取到單獨(dú)的服務(wù)器，它為后端資源服務(wù)提供OAuth2令牌。授權(quán)服務(wù)器用于用戶授權(quán)以及在周邊內(nèi)進(jìn)行安全的機(jī)器間通信。
在此項(xiàng)目中，我使用密碼憑據(jù)作為用戶授權(quán)的授權(quán)類型（因?yàn)樗鼉H由本地應(yīng)用UI使用）和客戶端憑據(jù)作為微服務(wù)授權(quán)的授權(quán)類型。
Spring Cloud Security提供了方便的注解和自動(dòng)配置，使其在服務(wù)器端或者客戶端都可以很容易地實(shí)現(xiàn)。您可以在文檔中了解到更多信息，并在授權(quán)服務(wù)器代碼中檢查配置明細(xì)。
授權(quán)服務(wù)器代碼：https://github.com/sqshq/PiggyMetrics/tree/master/auth-service/src/main/java/com/piggymetrics/auth
從客戶端來看，一切都與傳統(tǒng)的基于會(huì)話的授權(quán)完全相同。您可以從請(qǐng)求中檢索Principal對(duì)象、檢查用戶角色和其它基于表達(dá)式訪問控制和@PreAuthorize注解的內(nèi)容。
PiggyMetrics（帳戶服務(wù)、統(tǒng)計(jì)服務(wù)、通知服務(wù)和瀏覽器）中的每一個(gè)客戶端都有一個(gè)范圍：用于后臺(tái)服務(wù)的服務(wù)器、用于瀏覽器展示的UI。所以我們也可以保護(hù)控制器避免受到外部訪問，例如：
@PreAuthorize("#oauth2.hasScope('server')")
@RequestMapping(value = "accounts/{name}", method = RequestMethod.GET)
public List<DataPoint> getStatisticsByAccountName(@PathVariable String name) {
return statisticsService.findByAccountName(name);
}
API網(wǎng)關(guān)
您可以看到，有三個(gè)核心服務(wù)。它們向客戶端暴露外部API。在現(xiàn)實(shí)系統(tǒng)中，這個(gè)數(shù)量可以非常快速地增長(zhǎng)，同時(shí)整個(gè)系統(tǒng)將變得非常復(fù)雜。實(shí)際上，一個(gè)復(fù)雜頁(yè)面的渲染可能涉及到數(shù)百個(gè)服務(wù)。
理論上，客戶端可以直接向每個(gè)微服務(wù)直接發(fā)送請(qǐng)求。但是這種方式是存在挑戰(zhàn)和限制的，如果需要知道所有端點(diǎn)的地址，分別對(duì)每一段信息執(zhí)行http請(qǐng)求，將結(jié)果合并到客戶端。另一個(gè)問題是，這不是web友好協(xié)議，可能只在后端使用。
通常一個(gè)更好的方法是使用API網(wǎng)關(guān)。它是系統(tǒng)的單個(gè)入口點(diǎn)，用于通過將請(qǐng)求路由到適當(dāng)?shù)暮蠖朔?wù)或者通過調(diào)用多個(gè)后端服務(wù)并聚合結(jié)果來處理請(qǐng)求。此外，它還可以用于認(rèn)證、insights、壓力測(cè)試、金絲雀測(cè)試（canary testing）、服務(wù)遷移、靜態(tài)響應(yīng)處理和主動(dòng)變換管理。
聚合結(jié)果：http://techblog.netflix.com/2013/01/optimizing-netflix-api.html
Netflix開源這樣的邊緣服務(wù)，現(xiàn)在用Spring Cloud，我們可以用一個(gè)@EnabledZuulProxy注解來啟用它。在這個(gè)項(xiàng)目中，我使用Zuul存儲(chǔ)靜態(tài)內(nèi)容（UI應(yīng)用），并將請(qǐng)求路由到適當(dāng)?shù)奈⒎?wù)。以下是一個(gè)簡(jiǎn)單的基于前綴（prefix-based）路由的通知服務(wù)配置：
zuul:
routes:
notification-service:
path: /notifications/**
serviceId: notification-service
stripPrefix: false
這意味著所有以/notification開頭的請(qǐng)求將被路由到通知服務(wù)。您可以看到，里面沒有硬編碼的地址。Zuul使用服務(wù)發(fā)現(xiàn)機(jī)制來定位通知服務(wù)實(shí)例以及斷路器和負(fù)載均衡器，如下所述。
服務(wù)發(fā)現(xiàn)
另一種常見的架構(gòu)模式是服務(wù)發(fā)現(xiàn)。它允許自動(dòng)檢測(cè)服務(wù)實(shí)例的網(wǎng)絡(luò)位置，由于自動(dòng)擴(kuò)展、故障和升級(jí)，它可能會(huì)動(dòng)態(tài)分配地址。
服務(wù)發(fā)現(xiàn)的關(guān)鍵部分是注冊(cè)。我使用Netflix Eureka進(jìn)行這個(gè)項(xiàng)目，當(dāng)客戶端需要負(fù)責(zé)確定可以用的服務(wù)實(shí)例（使用注冊(cè)服務(wù)器）的位置和跨平臺(tái)的負(fù)載均衡請(qǐng)求時(shí)，Eureka就是客戶端發(fā)現(xiàn)模式的一個(gè)很好的例子。
使用Spring Boot，您可以使用spring-cloud-starter-eureka-server依賴、@EnabledEurekaServer注解和簡(jiǎn)單的配置屬性輕松構(gòu)建Eureka注冊(cè)中心（Eureka Registry）。
使用@EnabledDiscoveryClient注解和帶有應(yīng)用名稱的bootstrap.yml來啟用客戶端支持：
spring:
application:
name: notification-service
現(xiàn)在，在應(yīng)用啟動(dòng)時(shí)，它將向Eureka服務(wù)器注冊(cè)并提供元數(shù)據(jù)，如主機(jī)和端口、健康指示器URL、主頁(yè)等。Eureka接收來自從屬于某服務(wù)的每個(gè)實(shí)例的心跳消息。如果心跳失敗超過配置的時(shí)間表，該實(shí)例將從注冊(cè)表中刪除。
此外，Eureka還提供了一個(gè)簡(jiǎn)單的界面，您可以通過它來跟蹤運(yùn)行中的服務(wù)和可用實(shí)例的數(shù)量：http://localhost:8761
負(fù)載均衡器、斷路器和Http客戶端
Netflix OSS提供了另一套很棒的工具。
Ribbon
Ribbon是一個(gè)客戶端負(fù)載均衡器，可以很好地控制HTTP和TCP客戶端的行為。與傳統(tǒng)的負(fù)載均衡器相比，每次線上調(diào)用都不需要額外的跳躍——您可以直接聯(lián)系所需的服務(wù)。
它與Spring Cloud和服務(wù)發(fā)現(xiàn)是集成在一起的，可開箱即用。Eureka客戶端提供了可用服務(wù)器的動(dòng)態(tài)列表，因此Ribbon可以在它們之間進(jìn)行平衡。
Hystrix
Hystrix是斷路器模式的一種實(shí)現(xiàn)，它可以通過網(wǎng)絡(luò)訪問依賴來控制延遲和故障。中心思想是在具有大量微服務(wù)的分布式環(huán)境中停止級(jí)聯(lián)故障。這有助于快速失敗并盡快恢復(fù)——自我修復(fù)在容錯(cuò)系統(tǒng)中是非常重要的。
除了斷路器控制，在使用Hystrix，您可以添加一個(gè)備用方法，在主命令失敗的情況下，該方法將被調(diào)用以獲取默認(rèn)值。
此外，Hystrix生成每個(gè)命令的執(zhí)行結(jié)果和延遲的度量，我們可以用它來監(jiān)視系統(tǒng)的行為。
Feign
Feign是一個(gè)聲明式HTTP客戶端，能與Ribbon和Hystrix無縫集成。實(shí)際上，通過一個(gè)spring-cloud-starter-feign依賴和@EnabledFeignClients注解，您可以使用一整套負(fù)載均衡器、斷路器和HTTP客戶端，并附帶一個(gè)合理的的默認(rèn)配置。
以下是賬戶服務(wù)的示例：
@FeignClient(name = "statistics-service")
public interface StatisticsServiceClient {
@RequestMapping(method = RequestMethod.PUT, value = "/statistics/{accountName}", consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)
void updateStatistics(@PathVariable("accountName") String accountName, Account account);
}
您需要的只是一個(gè)接口
您可以在Spring MVC控制器和Feign方法之間共享@RequestMapping部分
以上示例僅指定所需要的服務(wù)ID——statistics-service，這得益于Eureka的自動(dòng)發(fā)現(xiàn)（但顯然您可以使用特定的URL訪問任何資源）。
監(jiān)控儀表盤
在這個(gè)項(xiàng)目配置中，Hystrix的每一個(gè)微服務(wù)都通過Spring Cloud Bus（通過AMQP broker）將指標(biāo)推送到Turbine。監(jiān)控項(xiàng)目只是一個(gè)使用了Turbine和Hystrix儀表盤的小型Spring Boot應(yīng)用。
讓我們看看系統(tǒng)行為在負(fù)載下：賬戶服務(wù)調(diào)用統(tǒng)計(jì)服務(wù)和它在一個(gè)變化的模擬延遲下的響應(yīng)。響應(yīng)超時(shí)閾值設(shè)置為1秒。
日志分析
集中式日志記錄在嘗試查找分布式環(huán)境中的問題時(shí)非常有用。Elasticsearch、Logstash和Kibana技術(shù)棧可讓您輕松搜索和分析您的日志、利用率和網(wǎng)絡(luò)活動(dòng)數(shù)據(jù)。在我的另一個(gè)項(xiàng)目中已經(jīng)有現(xiàn)成的Docker配置。
安全
高級(jí)安全配置已經(jīng)超過了此概念性項(xiàng)目的范圍。為了更真實(shí)地模擬真實(shí)系統(tǒng)，請(qǐng)考慮使用https和JCE密鑰庫(kù)來加密微服務(wù)密碼和配置服務(wù)器的properties內(nèi)容（有關(guān)詳細(xì)信息，請(qǐng)參閱文檔）。
基礎(chǔ)設(shè)施自動(dòng)化
部署微服務(wù)比部署單一的應(yīng)用的流程要復(fù)雜得多，因?yàn)樗鼈兿嗷ヒ蕾嚒碛型耆A(chǔ)設(shè)置自動(dòng)化是非常重要的。我們可以通過持續(xù)交付的方式獲得以下好處：
隨時(shí)發(fā)布軟件的能力。
任何構(gòu)建都可能最終成為一個(gè)發(fā)行版本。
構(gòu)建工件（artifact）一次，根據(jù)需要進(jìn)行部署。
這是一個(gè)簡(jiǎn)單的持續(xù)交付工作流程，在這個(gè)項(xiàng)目的實(shí)現(xiàn)：
在此配置中，Travis CI為每一個(gè)成功的Git推送創(chuàng)建了標(biāo)記鏡像。因此，每一個(gè)微服務(wù)在Docker Hub上的都會(huì)有一個(gè)latest鏡像，而較舊的鏡像則使用Git提交的哈希進(jìn)行標(biāo)記。如果有需要，可以輕松部署任何一個(gè)，并快速回滾。
如何運(yùn)行全部？
這真的很簡(jiǎn)單，我建議您嘗試一下。請(qǐng)記住，您將要啟動(dòng)8個(gè)Spring Boot應(yīng)用、4個(gè)MongoDB實(shí)例和RabbitMq。確保您的機(jī)器上有4GB的內(nèi)存。您可以隨時(shí)通過網(wǎng)關(guān)、注冊(cè)中心、配置、認(rèn)證服務(wù)和賬戶中心運(yùn)行重要的服務(wù)。
運(yùn)行之前
安裝Docker和Docker Compose。
配置環(huán)境變量：CONFIG_SERVICE_PASSWORD, NOTIFICATION_SERVICE_PASSWORD, STATISTICS_SERVICE_PASSWORD, ACCOUNT_SERVICE_PASSWORD, MONGODB_PASSWORD
生產(chǎn)模式
在這種模式下，所有最新的鏡像都將從Docker Hub上拉取。只需要復(fù)制docker-compose.yml并執(zhí)行docker-compose up -d即可。
開發(fā)模式
如果您想自己構(gòu)建鏡像（例如，在代碼中進(jìn)行一些修改），您需要克隆所有倉(cāng)庫(kù)（repository）并使用Mavne構(gòu)建工件（artifact）。然后，運(yùn)行docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d
docker-compose.dev.yml繼承了docker-compose.yml，附帶額外配置，可在本地構(gòu)建鏡像，并暴露所有容器端口以方便開發(fā)。
重要的端點(diǎn)（Endpoint）
localhost:80 —— 網(wǎng)關(guān)
localhost:8761 —— Eureka儀表盤
localhost:9000 —— Hystrix儀表盤
localhost:8989 —— Turbine stream（Hystrix儀表盤來源）
localhost:15672 —— RabbitMq管理
注意
所有Spring Boot應(yīng)用都需要運(yùn)行配置服務(wù)器才能啟動(dòng)。得益于Spring Boot的fail-fast屬性和docker-compsoe的restart:always選項(xiàng)，我們可以同時(shí)啟動(dòng)所有容器。這意味著所有依賴的容器將嘗試重新啟動(dòng)，直到配置服務(wù)器啟動(dòng)運(yùn)行為止。
此外，服務(wù)發(fā)現(xiàn)機(jī)制在所有應(yīng)用啟動(dòng)后需要一段時(shí)間。在實(shí)例、Eureka服務(wù)器和客戶端在其本地緩存中都具有相同的元數(shù)據(jù)之前，任何服務(wù)都不可用于客戶端發(fā)現(xiàn)，因此可能需要3次心跳。默認(rèn)的心跳周期為30秒。
