點擊上方[全棧開發(fā)者社區(qū)]→右上角[...]→[設為星標?]

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

該代碼可以在GitHub上獲得，并且在Docker Hub上提供了鏡像。您只需要一個命令即可啟動整個系統(tǒng)。

https://github.com/sqshq/PiggyMetrics

我選擇了一個老項目作為這個系統(tǒng)的基礎，它的后端以前是單一應用。此應用提供了處理個人財務、整理收入開銷、管理儲蓄、分析統(tǒng)計和創(chuàng)建簡單預測等功能。

功能服務

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

賬戶服務

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

統(tǒng)計服務

計算主要的統(tǒng)計參數(shù)，并捕獲每一個賬戶的時間序列。數(shù)據(jù)點包含基于貨幣和時間段正常化后的值。該數(shù)據(jù)可用于跟蹤賬戶生命周期中的現(xiàn)金流量動態(tài)。

通知服務

存儲用戶的聯(lián)系信息和通知設置(如提醒和備份頻率)。安排工作人員從其它服務收集所需的信息并向訂閱的客戶發(fā)送電子郵件。

注意

• 每一個微服務擁有自己的數(shù)據(jù)庫，因此沒有辦法繞過API直接訪問持久數(shù)據(jù)。

• 在這個項目中，我使用MongoDB作為每一個服務的主數(shù)據(jù)庫。擁有一個多種類持久化架構(gòu)(polyglot persistence architecture)也是很有意義的。

• 服務間(Service-to-service)通信是非常簡單的：微服務僅使用同步的REST API進行通信。現(xiàn)實中的系統(tǒng)的常見做法是使用互動風格的組合。例如，執(zhí)行同步的GET請求檢索數(shù)據(jù)，并通過消息代理(broker)使用異步方法執(zhí)行創(chuàng)建/更新操作，以便解除服務和緩沖消息之間的耦合。然而，這帶給我們是最終的一致性。

基礎設施服務

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

配置服務

Spring Cloud Config是分布式系統(tǒng)的水平擴展集中式配置服務。它使用了當前支持的本地存儲、Git和Subversion等可拔插存儲庫層(repository layer)。

在此項目中，我使用了native profile，它簡單地從本地classpath下加載配置文件。您可以在配置服務資源中查看shared目錄。現(xiàn)在，當通知服務請求它的配置時，配置服務將響應回shared/notification-service.yml和shared/application.yml(所有客戶端應用之間共享)。

客戶端使用

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

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

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

使用Spring Cloud Config，您可以動態(tài)更改應用配置

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

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

您也可以使用webhook來自動執(zhí)行此過程。

http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_push_notifications_and_spring_cloud_bus

注意

• 動態(tài)刷新存在一些限制。@RefreshScope不能和@Configuraion類一同工作，并且不會作用于@Scheduled方法。

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

• 下面有重要的安全提示

授權(quán)服務

負責授權(quán)的部分被完全提取到單獨的服務器，它為后端資源服務提供OAuth2令牌。授權(quán)服務器用于用戶授權(quán)以及在周邊內(nèi)進行安全的機器間通信。

在此項目中，我使用密碼憑據(jù)作為用戶授權(quán)的授權(quán)類型(因為它僅由本地應用UI使用)和客戶端憑據(jù)作為微服務授權(quán)的授權(quán)類型。

Spring Cloud Security提供了方便的注解和自動配置，使其在服務器端或者客戶端都可以很容易地實現(xiàn)。您可以在文檔中了解到更多信息，并在授權(quán)服務器代碼中檢查配置明細。

授權(quán)服務器代碼：https://github.com/sqshq/PiggyMetrics/tree/master/auth-service/src/main/java/com/piggymetrics/auth

從客戶端來看，一切都與傳統(tǒng)的基于會話的授權(quán)完全相同。您可以從請求中檢索Principal對象、檢查用戶角色和其它基于表達式訪問控制和@PreAuthorize注解的內(nèi)容。

PiggyMetrics(帳戶服務、統(tǒng)計服務、通知服務和瀏覽器)中的每一個客戶端都有一個范圍：用于后臺服務的服務器、用于瀏覽器展示的UI。所以我們也可以保護控制器避免受到外部訪問，例如：

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

API網(wǎng)關

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

理論上，客戶端可以直接向每個微服務直接發(fā)送請求。但是這種方式是存在挑戰(zhàn)和限制的，如果需要知道所有端點的地址，分別對每一段信息執(zhí)行http請求，將結(jié)果合并到客戶端。另一個問題是，這不是web友好協(xié)議，可能只在后端使用。

通常一個更好的方法是使用API網(wǎng)關。它是系統(tǒng)的單個入口點，用于通過將請求路由到適當?shù)暮蠖朔栈蛘咄ㄟ^調(diào)用多個后端服務并聚合結(jié)果來處理請求。此外，它還可以用于認證、insights、壓力測試、金絲雀測試(canary testing)、服務遷移、靜態(tài)響應處理和主動變換管理。

聚合結(jié)果：http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

Netflix開源這樣的邊緣服務，現(xiàn)在用Spring Cloud，我們可以用一個@EnabledZuulProxy注解來啟用它。在這個項目中，我使用Zuul存儲靜態(tài)內(nèi)容(UI應用)，并將請求路由到適當?shù)奈⒎铡Ｒ韵率且粋€簡單的基于前綴(prefix-based)路由的通知服務配置：

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

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

服務發(fā)現(xiàn)

另一種常見的架構(gòu)模式是服務發(fā)現(xiàn)。它允許自動檢測服務實例的網(wǎng)絡位置，由于自動擴展、故障和升級，它可能會動態(tài)分配地址。

服務發(fā)現(xiàn)的關鍵部分是注冊。我使用Netflix Eureka進行這個項目，當客戶端需要負責確定可以用的服務實例(使用注冊服務器)的位置和跨平臺的負載均衡請求時，Eureka就是客戶端發(fā)現(xiàn)模式的一個很好的例子。

使用Spring Boot，您可以使用spring-cloud-starter-eureka-server依賴、@EnabledEurekaServer注解和簡單的配置屬性輕松構(gòu)建Eureka注冊中心(Eureka Registry)。

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

spring:
application:
name:?notification-service

現(xiàn)在，在應用啟動時，它將向Eureka服務器注冊并提供元數(shù)據(jù)，如主機和端口、健康指示器URL、主頁等。Eureka接收來自從屬于某服務的每個實例的心跳消息。如果心跳失敗超過配置的時間表，該實例將從注冊表中刪除。

此外，Eureka還提供了一個簡單的界面，您可以通過它來跟蹤運行中的服務和可用實例的數(shù)量：http://localhost:8761

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

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

Ribbon

Ribbon是一個客戶端負載均衡器，可以很好地控制HTTP和TCP客戶端的行為。與傳統(tǒng)的負載均衡器相比，每次線上調(diào)用都不需要額外的跳躍——您可以直接聯(lián)系所需的服務。

它與Spring Cloud和服務發(fā)現(xiàn)是集成在一起的，可開箱即用。Eureka客戶端提供了可用服務器的動態(tài)列表，因此Ribbon可以在它們之間進行平衡。

Hystrix

Hystrix是斷路器模式的一種實現(xiàn)，它可以通過網(wǎng)絡訪問依賴來控制延遲和故障。中心思想是在具有大量微服務的分布式環(huán)境中停止級聯(lián)故障。這有助于快速失敗并盡快恢復——自我修復在容錯系統(tǒng)中是非常重要的。

除了斷路器控制，在使用Hystrix，您可以添加一個備用方法，在主命令失敗的情況下，該方法將被調(diào)用以獲取默認值。

此外，Hystrix生成每個命令的執(zhí)行結(jié)果和延遲的度量，我們可以用它來監(jiān)視系統(tǒng)的行為。

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的自動發(fā)現(xiàn)(但顯然您可以使用特定的URL訪問任何資源)。

監(jiān)控儀表盤

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

讓我們看看系統(tǒng)行為在負載下：賬戶服務調(diào)用統(tǒng)計服務和它在一個變化的模擬延遲下的響應。響應超時閾值設置為1秒。

日志分析

集中式日志記錄在嘗試查找分布式環(huán)境中的問題時非常有用。Elasticsearch、Logstash和Kibana技術棧可讓您輕松搜索和分析您的日志、利用率和網(wǎng)絡活動數(shù)據(jù)。在我的另一個項目中已經(jīng)有現(xiàn)成的Docker配置。

安全

高級安全配置已經(jīng)超過了此概念性項目的范圍。為了更真實地模擬真實系統(tǒng)，請考慮使用https和JCE密鑰庫來加密微服務密碼和配置服務器的properties內(nèi)容(有關詳細信息，請參閱文檔)。

基礎設施自動化

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

• 隨時發(fā)布軟件的能力。

• 任何構(gòu)建都可能最終成為一個發(fā)行版本。

• 構(gòu)建工件(artifact)一次，根據(jù)需要進行部署。

這是一個簡單的持續(xù)交付工作流程，在這個項目的實現(xiàn)：

在此配置中，Travis CI為每一個成功的Git推送創(chuàng)建了標記鏡像。因此，每一個微服務在Docker Hub上的都會有一個latest鏡像，而較舊的鏡像則使用Git提交的哈希進行標記。如果有需要，可以輕松部署任何一個，并快速回滾。

如何運行全部？

這真的很簡單，我建議您嘗試一下。請記住，您將要啟動8個Spring Boot應用、4個MongoDB實例和RabbitMq。確保您的機器上有4GB的內(nèi)存。您可以隨時通過網(wǎng)關、注冊中心、配置、認證服務和賬戶中心運行重要的服務。

運行之前

• 安裝Docker和Docker Compose。

• 配置環(huán)境變量：CONFIG_SERVICE_PASSWORD, NOTIFICATION_SERVICE_PASSWORD, STATISTICS_SERVICE_PASSWORD, ACCOUNT_SERVICE_PASSWORD, MONGODB_PASSWORD

生產(chǎn)模式

在這種模式下，所有最新的鏡像都將從Docker Hub上拉取。只需要復制docker-compose.yml并執(zhí)行docker-compose up -d即可。

開發(fā)模式

如果您想自己構(gòu)建鏡像(例如，在代碼中進行一些修改)，您需要克隆所有倉庫(repository)并使用Mavne構(gòu)建工件(artifact)。然后，運行docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

docker-compose.dev.yml繼承了docker-compose.yml，附帶額外配置，可在本地構(gòu)建鏡像，并暴露所有容器端口以方便開發(fā)。

重要的端點(Endpoint)

• localhost:80 —— 網(wǎng)關

• localhost:8761 —— Eureka儀表盤

• localhost:9000 —— Hystrix儀表盤

• localhost:8989 —— Turbine stream(Hystrix儀表盤來源)

• localhost:15672 —— RabbitMq管理

注意

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

此外，服務發(fā)現(xiàn)機制在所有應用啟動后需要一段時間。在實例、Eureka服務器和客戶端在其本地緩存中都具有相同的元數(shù)據(jù)之前，任何服務都不可用于客戶端發(fā)現(xiàn)，因此可能需要3次心跳。默認的心跳周期為30秒。

原文：https://dzone.com/articles/microservice-architecture-with-spring-cloud-and-do
作者：Alexander Lukyanchikov ???
譯者：Oopsguy

覺得本文對你有幫助？請分享給更多人

關注「全棧開發(fā)者社區(qū)」加星標，提升全棧技能

本公眾號會不定期給大家發(fā)福利，包括送書、學習資源等，敬請期待吧！

如果感覺推送內(nèi)容不錯，不妨右下角點個在看轉(zhuǎn)發(fā)朋友圈或收藏，感謝支持。

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的winserver2016 401您无权使用所提供的凭据查看此目录或页面_不用找了，30分钟帮你搞定使用 Spring Cloud 和 Docker 轻松构建微服务架构！...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。