原文/項(xiàng)目 地址：https://github.com/sqshq/PiggyMetrics

由于最近公司業(yè)務(wù)需要，需要搭建基于spring Cloud的微服務(wù)系統(tǒng)。遍訪各大搜索引擎，發(fā)現(xiàn)國(guó)內(nèi)資料少之又少，也難怪，國(guó)內(nèi)Dubbo正統(tǒng)治著天下。但是，一個(gè)技術(shù)總有它的瓶頸，Dubbo也有它捉襟見肘的地方。所幸霸主Spring也推出了一整套微服務(wù)解決方案，各個(gè)子項(xiàng)目也巧妙地解決了分布式系統(tǒng)開發(fā)過(guò)程中的各種各樣的問(wèn)題?？戳撕芏鄧?guó)內(nèi)的資料，最早的幾份文檔也是互相借用，恐怕究竟是什么都說(shuō)不清楚了。擼主在github上面發(fā)現(xiàn)幾個(gè)很好的相關(guān)項(xiàng)目，就想翻譯來(lái)看看。這篇其實(shí)是項(xiàng)目說(shuō)明，但是里面很多知識(shí)點(diǎn)是百度找不到的，下面就來(lái)看看吧，想要部署來(lái)看看的可以去下載：

這個(gè)項(xiàng)目的名字叫：Piggy Metrics，一個(gè)供個(gè)人處理財(cái)務(wù)的解決方案。

簡(jiǎn)介
這是一款概念性的應(yīng)用程序，基于Spring Boot，Spring Cloud和Docker 簡(jiǎn)單演示了微服務(wù)的架構(gòu)模式，順便說(shuō)一句，它還有一個(gè)非常漂亮整潔的用戶界面。下面是它的界面演示：

功能服務(wù)

PiggyMetrics被分解為三個(gè)核心微服務(wù)。這些服務(wù)都是圍繞某些業(yè)務(wù)能力組織的可獨(dú)立部署的應(yīng)用程序。

賬戶服務(wù)
包含一般用戶輸入邏輯和驗(yàn)證：收入/費(fèi)用項(xiàng)目，儲(chǔ)蓄和帳戶設(shè)置。

統(tǒng)計(jì)服務(wù)
對(duì)主要統(tǒng)計(jì)參數(shù)執(zhí)行計(jì)算，并為每個(gè)帳戶的時(shí)間序列。數(shù)據(jù)點(diǎn)包含基準(zhǔn)貨幣和時(shí)間段的值。此數(shù)據(jù)用于跟蹤帳戶生命周期中的現(xiàn)金流動(dòng)動(dòng)態(tài)（尚未在UI中實(shí)現(xiàn)的花式圖表）。

通知服務(wù)
存儲(chǔ)用戶聯(lián)系信息和通知設(shè)置（如提醒和備份頻率）。計(jì)劃工作人員從其他服務(wù)收集所需的信息，并向訂閱的客戶發(fā)送電子郵件。

**小結(jié)：

• 每個(gè)微服務(wù)都有自己的數(shù)據(jù)庫(kù)，因此沒(méi)有辦法繞過(guò)API和直接訪問(wèn)數(shù)據(jù)庫(kù)。
• 在這個(gè)項(xiàng)目中，使用MongoDB作為每個(gè)服務(wù)的主數(shù)據(jù)庫(kù)。它是支持多種編程語(yǔ)言持久性架構(gòu)（包括最適合服務(wù)需求的數(shù)據(jù)庫(kù)類型）。
• Service-to-service的通信是相當(dāng)簡(jiǎn)單的：各個(gè)微服務(wù)之間的通信只使用同步的REST API。在現(xiàn)實(shí)世界中通常的做法是使用交互風(fēng)格的組合。例如，執(zhí)行同步GET請(qǐng)求以檢索數(shù)據(jù)，并通過(guò)消息代理使用異步方法進(jìn)行創(chuàng)建/更新操作，以便分離服務(wù)和緩沖消息，這為我們帶來(lái)了一致性。

基礎(chǔ)服務(wù)設(shè)施

在分布式系統(tǒng)中有一些常見的架構(gòu)，這可以幫助我們理解核心服務(wù)的工作原理。Spring Cloud提供了強(qiáng)大的工具來(lái)增強(qiáng)基于Spring Boot的應(yīng)用程序，以此來(lái)實(shí)現(xiàn)這些架構(gòu)。

Config service
Spring Cloud Config是用于分布式系統(tǒng)的水平可擴(kuò)展的集中式配置服務(wù)。支持本地存儲(chǔ)、Git和Subversion。

在這個(gè)項(xiàng)目中，使用native profile，它從本地類路徑加載配置文件?？梢圆榭?code>shared在Config服務(wù)資源中的目錄?，F(xiàn)在，當(dāng)通知服務(wù)請(qǐng)求其配置時(shí)，配置服務(wù)以shared/notification-service.yml和shared/application.yml響應(yīng)（在所有客戶端應(yīng)用程序之間共享）。

客戶端使用
只需構(gòu)建具有spring-cloud-starter-config依賴的Spring Boot應(yīng)用程序，自動(dòng)配置將完成其余所有工作。

現(xiàn)在，不需要在應(yīng)用程序中使用任何嵌入式屬性。只需提供bootstrap.yml應(yīng)用程序名稱和配置服務(wù)url：

spring：
   application：
     name：notification-service 
  cloud：
     config：
       uri：http：// config：8888 
      fail-fast：true
1
2
3
4
5
6
7
1
2
3
4
5
6
7

使用Spring Cloud Config，可以動(dòng)態(tài)地更新配置。
例如，EmailService bean已注釋@RefreshScope。這意味著，可以更改電子郵件文本和主題，而不需要重新部署啟動(dòng)通知服務(wù)。

首先，在Config服務(wù)器中更改所需的屬性。然后，對(duì)Notification服務(wù)執(zhí)行刷新請(qǐng)求： curl -H "Authorization: Bearer #token#" -XPOST http://127.0.0.1:8000/notifications/refresh

此外，也可以使用Repository webhooks自動(dòng)執(zhí)行此過(guò)程

**小結(jié)：

• 動(dòng)態(tài)更新有一些限制。@RefreshScope不與@Configuration類一起使用，并且不影響@Scheduled方法
• fail-fast屬性意味著Spring Boot如果它無(wú)法連接到Config
  Service就將啟動(dòng)失敗，這在批量啟動(dòng)時(shí)非常有用。
• 安全注意事項(xiàng)請(qǐng)往下看

Auth service
授權(quán)的責(zé)任完全抽取到單獨(dú)的服務(wù)器，它為后端資源服務(wù)授予OAuth2令牌。Auth服務(wù)器用于用戶授權(quán)以及在外圍內(nèi)的安全的機(jī)器對(duì)機(jī)器通信。

在這個(gè)項(xiàng)目中，我使用Password credentials授權(quán)類型的用戶授權(quán)（因?yàn)樗挥杀镜豍iggyMetrics UI使用）和Client Credentials授予微服務(wù)權(quán)限。

Spring云安全提供了方便的注釋和自動(dòng)配置，使得從服務(wù)器端和客戶端端都很容易實(shí)現(xiàn)。您可以在文檔中了解更多信息，并在Auth Server代碼中檢查配置詳細(xì)信息。

從客戶端，一切工作與傳統(tǒng)的基于會(huì)話的授權(quán)完全相同。您可以Principal從請(qǐng)求中檢索對(duì)象，檢查用戶的角色和其他使用基于表達(dá)式的訪問(wèn)控制和@PreAuthorize注釋的東西。

PiggyMetrics（帳戶服務(wù)，統(tǒng)計(jì)服務(wù)，通知服務(wù)和瀏覽器）中的每個(gè)客戶端都有一個(gè)范圍：server用于后端服務(wù)，以及ui- 用于瀏覽器。因此，我們還可以保護(hù)控制器免受外部訪問(wèn)，例如：

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

API Gateway
可以看到，有三個(gè)核心服務(wù)，它們向客戶端公開外部API。在現(xiàn)實(shí)世界的系統(tǒng)中，這個(gè)數(shù)字可以快速增長(zhǎng)以及整個(gè)系統(tǒng)的復(fù)雜性。實(shí)際上，上百個(gè)服務(wù)可能涉及到渲染一個(gè)復(fù)雜的網(wǎng)頁(yè)。

在理論上，客戶端可以直接向每個(gè)微服務(wù)器發(fā)出請(qǐng)求。但是顯然，這個(gè)選項(xiàng)有挑戰(zhàn)和限制，如需要知道所有端點(diǎn)地址，分別執(zhí)行每個(gè)信息的http請(qǐng)求，在客戶端合并結(jié)果。另一個(gè)問(wèn)題是非web友好的協(xié)議，可能在后端使用。

通常一個(gè)更好的方法是使用API??網(wǎng)關(guān)。它是進(jìn)入系統(tǒng)的單個(gè)入口點(diǎn)，用于通過(guò)將它們路由到適當(dāng)?shù)暮蠖朔?wù)來(lái)處理請(qǐng)求，或者通過(guò)調(diào)用多個(gè)后端服務(wù)并聚合結(jié)果。此外，它可以用于身份驗(yàn)證，洞察，壓力和金絲雀測(cè)試，服務(wù)遷移，靜態(tài)響應(yīng)處理，主動(dòng)流量管理。

Netflix打開了這樣一個(gè)邊緣服務(wù)，現(xiàn)在使用Spring Cloud，我們可以使用一個(gè)@EnableZuulProxy注釋啟用它。在這個(gè)項(xiàng)目中，我使用Zuul來(lái)存儲(chǔ)靜態(tài)內(nèi)容（ui應(yīng)用程序），并將請(qǐng)求路由到適當(dāng)?shù)奈⒎?wù)。這是一個(gè)簡(jiǎn)單的基于前綴的路由配置Notification服務(wù)：

zuul：
   routes：
     notification-service：
         path：/ notifications / ** 
        serviceId：notification-service 
        stripPrefix：false
1
2
3
4
5
6
1
2
3
4
5
6

這意味著所有開始的請(qǐng)求/notifications都將路由到Notification服務(wù)。沒(méi)有硬編碼的地址，你可以看到。Zuul使用服務(wù)發(fā)現(xiàn)機(jī)制來(lái)定位通知服務(wù)實(shí)例，以及斷路器和負(fù)載平衡器，如下所述。

Service discovery
另一個(gè)公知的架構(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è)表。我在這個(gè)項(xiàng)目中使用Netflix Eureka。當(dāng)客戶端負(fù)責(zé)確定可用服務(wù)實(shí)例（使用注冊(cè)表服務(wù)器）和負(fù)載平衡請(qǐng)求的位置時(shí)，Eureka是客戶端發(fā)現(xiàn)模式的一個(gè)很好的例子。

使用Spring Boot，您可以輕松地使用spring-cloud-starter-eureka-server依賴關(guān)系，@EnableEurekaServer注釋和簡(jiǎn)單配置屬性來(lái)構(gòu)建Eureka注冊(cè)表。

支持@EnableDiscoveryClient注釋的客戶端支持bootstrap.yml應(yīng)用程序名稱：

spring：
   application：
     name：notification-service
1
2
3
1
2
3

現(xiàn)在，在應(yīng)用程序啟動(dòng)時(shí)，它將注冊(cè)到Eureka服務(wù)器并提供元數(shù)據(jù)，如主機(jī)和端口，運(yùn)行狀況指示器URL，主頁(yè)等。Eureka從屬于一個(gè)服務(wù)的每個(gè)實(shí)例接收心跳消息。如果心跳故障切換到可配置的時(shí)間表，則實(shí)例將從注冊(cè)表中刪除。

此外，Eureka提供了一個(gè)簡(jiǎn)單的界面，您可以跟蹤運(yùn)行的服務(wù)和可用實(shí)例數(shù)： http://localhost:8761

負(fù)載均衡器，斷路器和Http客戶端
Netflix OSS提供了另一個(gè)偉大的工具集。

Ribbon
Ribbon是一個(gè)客戶端負(fù)載均衡器，它為您提供了對(duì)HTTP和TCP客戶端行為的大量控制。與傳統(tǒng)的負(fù)載均衡器相比，每個(gè)線上調(diào)用不需要額外的跳躍 - 您可以直接聯(lián)系所需的服務(wù)。

開箱即用，它與Spring Cloud和服務(wù)發(fā)現(xiàn)本身集成。Eureka Client提供了可用服務(wù)器的動(dòng)態(tài)列表，以便Ribbon可以在它們之間進(jìn)行平衡。

Hystrix
Hystrix是斷路器模式的實(shí)現(xiàn)，它提供了對(duì)通過(guò)網(wǎng)絡(luò)訪問(wèn)的依賴性的延遲和故障的控制。主要思想是在具有大量微服務(wù)的分布式環(huán)境中停止級(jí)聯(lián)故障。這有助于快速失敗，并盡快恢復(fù) - 自愈的容錯(cuò)系統(tǒng)的重要方面。

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

此外，Hystrix生成每個(gè)命令的執(zhí)行結(jié)果和延遲的指標(biāo)，我們可以用它來(lái)監(jiān)視系統(tǒng)行為。

Feign
Feign是一個(gè)聲明式Http客戶端，它與Ribbon和Hystrix無(wú)縫集成。實(shí)際上，使用一個(gè)spring-cloud-starter-feign依賴項(xiàng)和@EnableFeignClients注釋，您擁有一組完整的負(fù)載平衡器，斷路器和Http客戶端，并具有合理的即用型默認(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);

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

• 你需要的只是一個(gè)接口
• 你可以用@RequestMapping在Spring MVC控制器和Feign方法之間共享部分
• 上面的示例指定只需要的服務(wù)id -
  statistics-service，由于通過(guò)Eureka自動(dòng)發(fā)現(xiàn)（但顯然，您可以訪問(wèn)任何資源與特定的網(wǎng)址）

監(jiān)視儀表板
在這個(gè)項(xiàng)目配置中，Hystrix的每個(gè)微服務(wù)通過(guò)Spring Cloud Bus（使用AMQP代理）將指標(biāo)推送到Turbine。監(jiān)控項(xiàng)目只是一個(gè)小的Spring啟動(dòng)應(yīng)用程序與渦輪和Hystrix儀表板。

看下面如何讓它運(yùn)行。

讓我們看看我們的系統(tǒng)在負(fù)載下的行為：帳戶服務(wù)調(diào)用統(tǒng)計(jì)服務(wù)，它的響應(yīng)具有不同的模仿延遲。響應(yīng)超時(shí)閾值設(shè)置為1秒。

0 ms delay	500 ms delay	800 ms delay	1100 ms delay
表現(xiàn)良好的系統(tǒng)。吞吐量約為22請(qǐng)求/秒。統(tǒng)計(jì)服務(wù)中的活動(dòng)線程數(shù)較少。中位服務(wù)時(shí)間約為50 ms。	活動(dòng)線程的數(shù)量在增加。我們可以看到紫色線程池拒絕的數(shù)量，因此約30-40％的錯(cuò)誤，但電路仍然關(guān)閉。	半開狀態(tài)：故障命令的比率大于50％，斷路器啟動(dòng)。在睡眠窗口的時(shí)間后，下一個(gè)請(qǐng)求被允許通過(guò)。	100％的請(qǐng)求失敗。電路現(xiàn)在永久打開。在睡眠時(shí)間后重試不會(huì)再次閉合電路，因?yàn)閱蝹€(gè)請(qǐng)求太慢。

日志分析
當(dāng)嘗試在分布式環(huán)境中識(shí)別問(wèn)題時(shí)，集中式日志記錄可能非常有用。Elasticsearch，Logstash和Kibana堆棧使您可以輕松搜索和分析您的日志，利用率和網(wǎng)絡(luò)活動(dòng)數(shù)據(jù)。我的其他項(xiàng)目中描述的即開即用 docker配置。

安全
高級(jí)安全配置超出了此概念驗(yàn)證項(xiàng)目的范圍。對(duì)于真實(shí)系統(tǒng)的更真實(shí)的模擬，考慮使用https，JCE密鑰庫(kù)加密微服務(wù)密碼和配置服務(wù)器屬性內(nèi)容（有關(guān)詳細(xì)信息，請(qǐng)參閱文檔）。

基建自動(dòng)化

部署微服務(wù)及其相互依賴性，比部署單片應(yīng)用程序要復(fù)雜得多。擁有完全自動(dòng)化的基礎(chǔ)設(shè)施非常重要。我們可以通過(guò)持續(xù)交付方法實(shí)現(xiàn)以下優(yōu)勢(shì)：

• 隨時(shí)釋放軟件的能力
• 任何構(gòu)建可能最終都是發(fā)布
• 構(gòu)建工件一次 - 根據(jù)需要部署

這里是一個(gè)簡(jiǎn)單的連續(xù)交付工作流，在這個(gè)項(xiàng)目中實(shí)現(xiàn)：

在此配置中，Travis CI為每個(gè)成功的git push建立標(biāo)記的映像。因此，latest對(duì)于Docker Hub上的每個(gè)微服務(wù)總有圖像，并且用git提交哈希標(biāo)記的舊圖像。它很容易部署任何一個(gè)，并快速回滾，如果需要。

如何運(yùn)行所有的東西？
記住，你要啟動(dòng)8個(gè)Spring Boot應(yīng)用程序，4個(gè)MongoDB實(shí)例和RabbitMq。確保您4 Gb的計(jì)算機(jī)上有可用的RAM。您可以始終運(yùn)行重要的服務(wù)，雖然：網(wǎng)關(guān)，注冊(cè)表，配置，Auth服務(wù)和帳戶服務(wù)。

在你開始之前
- 安裝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和打docker-compose up -d。

開發(fā)模式
如果你想自己構(gòu)建圖像（例如在代碼中有一些變化），你必須使用maven克隆所有的倉(cāng)庫(kù)和構(gòu)建工件。然后，運(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ā)。

重要端口

http://DOCKER-HOST:80 - Gateway
http://DOCKER-HOST:8761 - Eureka Dashboard
http://DOCKER-HOST:9000/hystrix - Hystrix Dashboard
http://DOCKER-HOST:8989 - Turbine stream (source for the Hystrix Dashboard)
http://DOCKER-HOST:15672 - RabbitMq management (default login/password: guest/guest)
1
2
3
4
5
1
2
3
4
5

小結(jié)

所有Spring Boot應(yīng)用程序都需要運(yùn)行Config Server進(jìn)行啟動(dòng)。但是我們可以同時(shí)啟動(dòng)所有容器，因?yàn)閒ail-fastSpring Boot屬性和docker restart: always-compose選項(xiàng)。這意味著所有依賴的容器將嘗試重新啟動(dòng)，直到Config Server啟動(dòng)并運(yùn)行。

此外，在所有應(yīng)用程序啟動(dòng)后，服務(wù)發(fā)現(xiàn)機(jī)制需要一些時(shí)間。任何服務(wù)都不可用于客戶端發(fā)現(xiàn)，直到實(shí)例，Eureka服務(wù)器和客戶端都在其本地緩存中具有相同的元數(shù)據(jù)，因此可能需要3個(gè)心跳。默認(rèn)心跳周期為30秒。