如何使用Spring Boot、Spring Cloud、Docker和Netflix的一些開源工具來構建一個微服務架構。本文通過使用Spring Boot、Spring Cloud和Docker構建的概念型應用示例，提供了了解常見的微服務架構模式的起點。

該程式碼可以在GitHub上（https://github.com/sqshq/PiggyMetrics）獲得，並且在Docker Hub上提供了映象。您只需要一個命令即可啟動整個系統。

我選擇了一個老專案作為這個系統的基礎，它的後端以前是單一應用。此應用提供了處理個人財務、整理收入開銷、管理儲蓄、分析統計和建立簡單預測等功能。 功能服務

整個應用分解為三個核心微服務。它們都是可以獨立部署的應用，圍繞著某些業務功能進行組織。

賬戶服務

包含一般使用者輸入邏輯和驗證：收入/開銷記錄、儲蓄和賬戶設定。

方法	路徑	描述	使用者驗證	UI可用
GET	/accounts/{account}	獲取指定賬戶資料
GET	/accounts/current	獲取當前賬戶資料	x	x
GET	/accounts/demo	獲取演示賬戶資料（預先填入收入/開銷記錄等）		x
PUT	/accounts/current	儲存當前賬戶資料	x	x
POST	/accounts/	註冊新賬戶	x

統計服務

計算主要的統計引數，並捕獲每一個賬戶的時間序列。資料點包含基於貨幣和時間段正常化後的值。該資料可用於跟蹤賬戶生命週期中的現金流量動態。

方法	路徑	描述	使用者驗證	UI可用
GET	/statistics/{account}	獲取指定賬戶統計資料
GET	/statistics/current	獲取當前賬戶的統計資料	x	x
GET	/statistics/demo	獲取演示賬戶統計資料	x
PUT	/statistics/{account}	建立或更新指定賬戶的時間序列資料點。

通知服務

儲存使用者的聯絡資訊和通知設定（如提醒和備份頻率）。安排工作人員從其它服務收集所需的資訊並向訂閱的客戶傳送電子郵件。

方法	路徑	描述	使用者驗證	UI可用
GET	/notifications/settings/current	獲取當前賬戶的通知i設定	x	x
PUT	/notifications/settings/current	儲存當前賬戶的通知設定	x	x

注意

• 每一個微服務擁有自己的資料庫，因此沒有辦法繞過API直接訪問持久資料。

• 在這個專案中，我使用MongoDB作為每一個服務的主資料庫。擁有一個多種類持久化架構（polyglot persistence architecture）也是很有意義的。

• 服務間（Service-to-service）通訊是非常簡單的：微服務僅使用同步的REST API進行通訊。現實中的系統的常見做法是使用互動風格的組合。例如，執行同步的GET請求檢索資料，並通過訊息代理（broker）使用非同步方法執行建立/更新操作，以便解除服務和緩衝訊息之間的耦合。然而，這帶給我們是最終的一致性。

基礎設施服務

分散式系統中常見的模式，可以幫助我們描述核心服務是怎樣工作的。Spring Cloud提供了強大的工具，可以增強Spring Boot應用的行為來實現這些模式。我會簡要介紹一下：

配置服務

Spring Cloud Config是分散式系統的水平擴充套件集中式配置服務。它使用了當前支援的本地儲存、Git和Subversion等可拔插儲存庫層（repository layer）。

在此專案中，我使用了native profile，它簡單地從本地classpath下載入配置檔案。您可以在配置服務資源（http://t.cn/ROygD1c）中檢視shared目錄。現在，當通知服務請求它的配置時，配置服務將響應回shared/notification-service.yml和shared/application.yml（所有客戶端應用之間共享）。

客戶端使用

只需要使用sprng-cloud-starter-config依賴構建Spring Boot應用，自動配置將會完成其它工作。

現在您的應用中不需要任何嵌入的properties，只需要提供有應用名稱和配置服務url的bootstrap.yml即可：

spring:
application:
name: notification-service
cloud:
config:
  uri: http://config:8888
  fail-fast: true

使用Spring Cloud Config，您可以動態更改應用配置

比如，EmailService bean使用了@RefreshScope註解。這意味著您可以更改電子郵件的內容和主題，而無需重新構建和重啟通知服務應用。

首先，在配置伺服器中更改必要的屬性。然後，對通知服務執行重新整理請求：curl -H "Authorization: Bearer #token#" -XPOST http://127.0.0.1:8000/notifications/refresh。

您也可以使用webhook來自動執行此過程（http://t.cn/ROyeWaz）。

注意

• 動態重新整理存在一些限制。@RefreshScope不能和@Configuraion類一同工作，並且不會作用於@Scheduled方法。

• fail-fast屬性意味著如果Spring Boot應用無法連線到配置服務，將會立即啟動失敗。當您一起啟動所有應用時，這非常有用。

• 下面有重要的安全提示

授權服務

負責授權的部分被完全提取到單獨的伺服器，它為後端資源服務提供OAuth2令牌。授權伺服器用於使用者授權以及在周邊內進行安全的機器間通訊。

在此專案中，我使用密碼憑據作為使用者授權的授權型別（因為它僅由本地應用UI使用）和客戶端憑據作為微服務授權的授權型別。

Spring Cloud Security提供了方便的註解和自動配置，使其在伺服器端或者客戶端都可以很容易地實現。您可以在文件（http://t.cn/ROye1MN）中瞭解到更多資訊，並在授權伺服器程式碼（http://t.cn/ROyeFrV）中檢查配置明細。

從客戶端來看，一切都與傳統的基於會話的授權完全相同。您可以從請求中檢索Principal物件、檢查使用者角色和其它基於表示式訪問控制和@PreAuthorize註解的內容。

PiggyMetrics（帳戶服務、統計服務、通知服務和瀏覽器）中的每一個客戶端都有一個範圍：用於後臺服務的伺服器、用於瀏覽器展示的UI。所以我們也可以保護控制器避免受到外部訪問，例如：

@PreAuthorize("#oauth2.hasScope('server')")
@RequestMapping(value = "accounts/{name}", method = RequestMethod.GET)
public List<DataPoint> getStatisticsByAccountName(@PathVariable String name) {
return statisticsService.findByAccountName(name);
}

API閘道器

您可以看到，有三個核心服務。它們向客戶端暴露外部API。在現實系統中，這個數量可以非常快速地增長，同時整個系統將變得非常複雜。實際上，一個複雜頁面的渲染可能涉及到數百個服務。

理論上，客戶端可以直接向每個微服務直接傳送請求。但是這種方式是存在挑戰和限制的，如果需要知道所有端點的地址，分別對每一段資訊執行http請求，將結果合併到客戶端。另一個問題是，這不是web友好協議，可能只在後端使用。

通常一個更好的方法是使用API閘道器。它是系統的單個入口點，用於通過將請求路由到適當的後端服務或者通過呼叫多個後端服務並聚合結果來處理請求。此外，它還可以用於認證、insights、壓力測試、金絲雀測試（canary testing）、服務遷移、靜態響應處理和主動變換管理。

Netflix開源這樣的邊緣服務（http://t.cn/ROyF46G），現在用Spring Cloud，我們可以用一個@EnabledZuulProxy註解來啟用它。在這個專案中，我使用Zuul儲存靜態內容（UI應用），並將請求路由到適當的微服務。以下是一個簡單的基於字首（prefix-based）路由的通知服務配置：

zuul:
routes:
notification-service:
    path: /notifications/**
    serviceId: notification-service
    stripPrefix: false

這意味著所有以/notification開頭的請求將被路由到通知服務。您可以看到，裡面沒有硬編碼的地址。Zuul使用服務發現機制來定位通知服務例項以及斷路器和負載均衡器，如下所述。

服務發現

另一種常見的架構模式是服務發現。它允許自動檢測服務例項的網路位置，由於自動擴充套件、故障和升級，它可能會動態分配地址。

服務發現的關鍵部分是註冊。我使用Netflix Eureka進行這個專案，當客戶端需要負責確定可以用的服務例項（使用註冊伺服器）的位置和跨平臺的負載均衡請求時，Eureka就是客戶端發現模式的一個很好的例子。

使用Spring Boot，您可以使用spring-cloud-starter-eureka-server依賴、@EnabledEurekaServer註解和簡單的配置屬性輕鬆構建Eureka註冊中心（Eureka Registry）。

使用@EnabledDiscoveryClient註解和帶有應用名稱的bootstrap.yml來啟用客戶端支援：

spring:
application:
name: notification-service

現在，在應用啟動時，它將向Eureka伺服器註冊並提供元資料，如主機和埠、健康指示器URL、主頁等。Eureka接收來自從屬於某服務的每個例項的心跳訊息。如果心跳失敗超過配置的時間表，該例項將從登錄檔中刪除。

此外，Eureka還提供了一個簡單的介面，您可以通過它來跟蹤執行中的服務和可用例項的數量：http://localhost:8761

負載均衡器、斷路器和Http客戶端

Netflix OSS提供了另一套很棒的工具。

Ribbon

Ribbon是一個客戶端負載均衡器，可以很好地控制HTTP和TCP客戶端的行為。與傳統的負載均衡器相比，每次線上呼叫都不需要額外的跳躍——您可以直接聯絡所需的服務。

它與Spring Cloud和服務發現是整合在一起的，可開箱即用。Eureka客戶端提供了可用伺服器的動態列表，因此Ribbon可以在它們之間進行平衡。

Hystrix

Hystrix是斷路器模式的一種實現，它可以通過網路訪問依賴來控制延遲和故障。中心思想是在具有大量微服務的分散式環境中停止級聯故障。這有助於快速失敗並儘快恢復——自我修復在容錯系統中是非常重要的。

除了斷路器控制，在使用Hystrix，您可以新增一個備用方法，在主命令失敗的情況下，該方法將被呼叫以獲取預設值。

此外，Hystrix生成每個命令的執行結果和延遲的度量，我們可以用它來監視系統的行為。

Feign

Feign是一個宣告式HTTP客戶端，能與Ribbon和Hystrix無縫整合。實際上，通過一個spring-cloud-starter-feign依賴和@EnabledFeignClients註解，您可以使用一整套負載均衡器、斷路器和HTTP客戶端，並附帶一個合理的的預設配置。

以下是賬戶服務的示例：

@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);
}

• 您需要的只是一個介面

• 您可以在Spring MVC控制器和Feign方法之間共享@RequestMapping部分

• 以上示例僅指定所需要的服務ID——statistics-service，這得益於Eureka的自動發現（但顯然您可以使用特定的URL訪問任何資源）。

監控儀表盤

在這個專案配置中，Hystrix的每一個微服務都通過Spring Cloud Bus（通過AMQP broker）將指標推送到Turbine。監控專案只是一個使用了Turbine和Hystrix儀表盤的小型Spring Boot應用。

讓我們看看系統行為在負載下：賬戶服務呼叫統計服務和它在一個變化的模擬延遲下的響應。響應超時閾值設定為1秒。

日誌分析

集中式日誌記錄在嘗試查詢分散式環境中的問題時非常有用。Elasticsearch、Logstash和Kibana技術棧可讓您輕鬆搜尋和分析您的日誌、利用率和網路活動資料。在我的另一個專案（http://github.com/sqshq/ELK-docker）中已經有現成的Docker配置。

安全

高階安全配置已經超過了此概念性專案的範圍。為了更真實地模擬真實系統，請考慮使用https和JCE金鑰庫來加密微服務密碼和配置伺服器的properties內容（有關詳細資訊，請參閱文件，http://t.cn/ROyFT4t）。

基礎設施自動化

部署微服務比部署單一的應用的流程要複雜得多，因為它們相互依賴。擁有完全基礎設定自動化是非常重要的。我們可以通過持續交付的方式獲得以下好處：

• 隨時釋出軟體的能力。

• 任何構建都可能最終成為一個發行版本。

• 構建工件（artifact）一次，根據需要進行部署。

這是一個簡單的持續交付工作流程，在這個專案的實現：

在此配置（http://t.cn/ROyFmkQ）中，Travis CI為每一個成功的Git推送建立了標記映象。因此，每一個微服務在Docker Hub上的都會有一個latest映象，而較舊的映象則使用Git提交的雜湊進行標記。如果有需要，可以輕鬆部署任何一個，並快速回滾。

如何執行全部？

這真的很簡單，我建議您嘗試一下。請記住，您將要啟動8個Spring Boot應用、4個MongoDB例項和RabbitMq。確保您的機器上有4GB的記憶體。您可以隨時通過閘道器、註冊中心、配置、認證服務和賬戶中心執行重要的服務。

執行之前

• 安裝Docker和Docker Compose。

• 配置環境變數：CONFIG_SERVICE_PASSWORD, NOTIFICATION_SERVICE_PASSWORD, STATISTICS_SERVICE_PASSWORD, ACCOUNT_SERVICE_PASSWORD, MONGODB_PASSWORD

生產模式

在這種模式下，所有最新的映象都將從Docker Hub上拉取。只需要複製docker-compose.yml並執行docker-compose up -d即可。

開發模式

如果您想自己構建映象（例如，在程式碼中進行一些修改），您需要克隆所有倉庫（repository）並使用Mavne構建工件（artifact）。然後，執行docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

docker-compose.dev.yml繼承了docker-compose.yml，附帶額外配置，可在本地構建映象，並暴露所有容器埠以方便開發。

重要的端點（Endpoint）

• localhost:80 —— 閘道器

• localhost:8761 —— Eureka儀表盤

• localhost:9000 —— Hystrix儀表盤

• localhost:8989 —— Turbine stream（Hystrix儀表盤來源）

• localhost:15672 —— RabbitMq管理

注意

所有Spring Boot應用都需要執行配置伺服器才能啟動。得益於Spring Boot的fail-fast屬性和docker-compsoe的restart:always選項，我們可以同時啟動所有容器。這意味著所有依賴的容器將嘗試重新啟動，直到配置伺服器啟動執行為止。

此外，服務發現機制在所有應用啟動後需要一段時間。在例項、Eureka伺服器和客戶端在其本地快取中都具有相同的元資料之前，任何服務都不可用於客戶端發現，因此可能需要3次心跳。預設的心跳週期為30秒。

原文連結：https://dzone.com/articles/microservice-architecture-with-spring-cloud-and-do

Spring Cloud實戰訓練營

本次培訓內容包括：微服務架構及概述、微服務架構專案實戰目標、Spring Boot概述、Spring Cloud簡介與入門、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等，點選識別下方二維碼加微信好友瞭解具體培訓內容。

點選閱讀原文連結即可報名。