項目名稱
piggymetrics
轉發+關注，然後私信回覆關鍵字 “項目”即可獲得《piggymetrics》的源碼地址
項目簡介
這是一個教程項目，演示了使用Spring Boot，Spring Cloud和Docker的微服務架構模式。順便說一下，擁有漂亮的用戶界面。
功能服務
PiggyMetrics被分解爲三個核心微服務。它們都是圍繞某些業務領域組織的可獨立部署的應用程序。
開戶服務
包含一般用戶輸入邏輯和驗證：收入/支出項目，儲蓄和賬戶設置。
統計服務
對主要統計參數執行計算，並捕獲每個賬戶的時間序列。數據點包含以標準化爲基礎貨幣和時間段的值。此數據用於跟蹤賬戶生命週期中的現金流動態。
通知服務
存儲用戶的聯繫信息和通知設置（如提醒和備份頻率）。計劃工從其他服務收集所需的信息，並將電子郵件發送給訂閱的客戶。
筆記
- 每個微服務都有自己的數據庫，因此無法繞過API並直接訪問持久性數據。
- 在這個項目中，作者將MongoDB用作每個服務的主數據庫。具有多語言持久性體系結構（選擇最適合服務需求的db類型）也可能是有意義的。
- 服務到服務的通信已大大簡化：微服務僅使用同步REST API進行通話。實際系統中的常見做法是使用交互樣式的組合。例如，執行同步GET請求以檢索數據，並通過消息代理使用異步方法進行創建/更新操作，以使服務和消息分離。但是，這將我們帶到了最終的一致性世界。
基礎設施服務
分佈式系統中有一堆常見的模式，可以幫助我們使描述的核心服務正常工作。Spring Cloud提供了功能強大的工具，這些工具可以增強Spring Boot應用程序的行爲以實現這些模式。我會簡單介紹一下。
配置服務
Spring Cloud Config是用於分佈式系統的水平可擴展的集中式配置服務。它使用當前可支持本地存儲，Git和Subversion的可插入存儲庫層。
在此項目中，我使用native profile，它只是從本地類路徑加載配置文件。您可以shared在Config服務資源中看到目錄。現在，當Notification-service請求其配置時，Config服務將使用
shared/notification-service.yml和進行響應shared/application.yml（在所有客戶端應用程序之間共享）。
客戶端使用
只要構建
spring-cloud-starter-config依賴項的Spring Boot應用程序，其餘的工作就由自動配置完成。
現在，您在應用程序中不需要任何嵌入式屬性。只需提供bootstrap.yml應用程序名稱和配置服務網址即可：
春季：
應用程序：
名稱：通知服務
雲：
配置：
uri：http：// config：8888
fail-fast：true
藉助Spring Cloud Config，您可以動態更改應用程序配置。
例如，EmailService bean用註釋@RefreshScope。這意味着，您可以更改電子郵件文本和主題，而無需重建和重新啓動Notification Service應用程序。
首先，更改配置服務器中的必需屬性。然後，執行對通知服務的刷新請求： curl -H "Authorization: Bearer #token#" -XPOST
http://127.0.0.1:8000/notifications/refresh
另外，您可以使用Repository webhooks自動執行此過程
筆記
- 但是，對於動態刷新有一些限制。@RefreshScope不適用於@Configuration類，也不影響@Scheduled方法
- fail-fast 屬性意味着如果Spring Boot應用程序無法連接到Config Service，它將立即啓動失敗。
- 有顯著的安全注意事項如下
驗證服務
授權職責已完全提取到單獨的服務器，該服務器爲後端資源服務授予OAuth2令牌。Auth Server用於用戶授權以及外圍內部安全的機器對機器通信。
在此項目中，我將Password credentials授予類型用於用戶授權（因爲僅用於本機PiggyMetrics UI），而將Client Credentials授予類型用於微服務授權。
Spring Cloud Security提供了方便的批註和自動配置，以使其在服務器和客戶端均易於實現。您可以在文檔中瞭解更多信息，並在Auth Server代碼中查看配置詳細信息。
從客戶端來看，一切工作都與傳統的基於會話的授權完全相同。您可以Principal從請求中檢索對象，並使用基於表達式的訪問控制和@PreAuthorize註釋檢查用戶的角色以及其他內容。
PiggyMetrics中的每個客戶端（賬戶服務，統計服務，通知服務和瀏覽器）都有一個範圍：server後端服務，以及ui-瀏覽器。因此，我們還可以保護控制器免受外部訪問，例如：
@PreAuthorize（“＃oauth2.hasScope（ '服務器'） ”）
@RequestMapping（值 = “賬戶/ {名稱} ”，方法 = RequestMethod 。 GET）
公共 列表< 數據點 > getStatisticsByAccountName（@PathVariable 字符串名稱）{
返回 statisticsService 。findByAccountName（name）;
}
API網關
如您所見，有三個核心服務，它們向客戶端公開外部API。在現實世界的系統中，此數字以及整個系統的複雜性都可以非常迅速地增長。實際上，渲染一個複雜的網頁可能涉及數百種服務。
從理論上講，客戶端可以直接向每個微服務發出請求。但是很明顯，此選項存在挑戰和侷限性，例如必須知道所有端點地址，分別對每條信息執行http請求，將結果合併到客戶端。另一個問題是可能在後端使用的非Web友好協議。
通常，更好的方法是使用API網關。它是系統的單個入口點，用於通過將請求路由到適當的後端服務或調用多個後端服務並彙總結果來處理請求。此外，它還可用於身份驗證，洞察力，壓力和金絲雀測試，服務遷移，靜態響應處理，主動流量管理。
Netflix開源了這種邊緣服務，現在有了Spring Cloud，我們可以使用一個@EnableZuulProxy註釋啓用它。在這個項目中，我使用Zuul存儲靜態內容（ui應用程序）並將請求路由到適當的微服務。這是通知服務的基於前綴的簡單路由配置：
zuul：
路由：
通知服務：
路徑：/ notifications / **
serviceId：通知服務
stripPrefix：false
這意味着所有以開頭的請求/notifications都將路由到Notification Service。如您所見，沒有硬編碼的地址。Zuul使用服務發現機制來定位Notification服務實例以及如下所述的Circuit Breaker和Load Balancer。
服務發現
另一個衆所周知的體系結構模式是服務發現。它允許自動檢測服務實例的網絡位置，由於自動縮放，故障和升級，該服務實例可以動態分配地址。
服務發現的關鍵部分是註冊表。我在這個項目中使用Netflix Eureka。當客戶端負責確定可用服務實例的位置（使用註冊表服務器）並在它們之間負載均衡請求時，Eureka是客戶端發現模式的一個很好的例子。
使用Spring Boot，您可以輕鬆構建具有
spring-cloud-starter-eureka-server依賴項，@EnableEurekaServer註釋和簡單配置屬性的Eureka Registry 。
客戶端支持已啓用，並@EnableDiscoveryClient帶有bootstrap.yml帶有應用程序名稱的註釋：
春天：
應用程序：
名稱：通知服務
現在，在應用程序啓動時，它將向Eureka Server註冊並提供元數據，例如主機和端口，運行狀況指示器URL，主頁等。Eureka從屬於服務的每個實例接收心跳消息。如果心跳在可配置的時間表上進行故障轉移，則該實例將從註冊表中刪除。
此外，Eureka還提供了一個簡單的界面，您可以在其中跟蹤正在運行的服務和許多可用實例： http://localhost:8761
負載均衡器，斷路器和Http客戶端
Netflix OSS提供了另一套很棒的工具。
色帶
Ribbon是客戶端負載平衡器，可讓您對HTTP和TCP客戶端的行爲進行大量控制。與傳統的負載平衡器相比，無需每次通過線路調用都需要額外的約點-您可以直接聯繫所需的服務。
開箱即用，它與Spring Cloud和Service Discovery本地集成。Eureka Client提供了可用服務器的動態列表，因此Ribbon可以在它們之間進行平衡。
Hystrix
Hystrix是Circuit Breaker模式的實現，它可以控制通過網絡訪問的依賴項引起的延遲和故障。主要思想是在具有大量微服務的分佈式環境中停止級聯故障。這有助於快速故障並儘快恢復-自我修復的容錯系統的重要方面。
除了斷路器控制之外，使用Hystrix，您還可以添加一個後備方法，如果主命令失敗，該方法將被調用以獲取默認值。
此外，Hystrix會針對每個命令生成有關執行結果和延遲的度量，我們可以使用這些度量來監視系統行爲。
假裝
Feign是一個聲明性的Http客戶端，它與Ribbon和Hystrix無縫集成。實際上，有了一個
spring-cloud-starter-feign依賴項和@EnableFeignClients註釋，您便擁有了一整套負載均衡器，斷路器和Http客戶端，並具有明智的隨時可用的默認配置。
這是來自賬戶服務的示例：
@FeignClient（名稱 = “ statistics-service ”）
公共 接口 StatisticsServiceClient {
@RequestMapping（方法 = RequestMethod 。 PUT，值 = “ /統計/ {帳戶名} ”，消耗 = 的MediaType 。 APPLICATION_JSON_UTF8_VALUE）
空隙 updateStatistics（@PathVariable（“帳戶名”）的字符串 帳戶名，帳戶 的帳戶）;
}
- 您所需的一切只是一個界面
- 您可以@RequestMapping在Spring MVC控制器和Feign方法之間共享一部分
- 上面的示例僅指定了所需的服務id- statistics-service，這要歸功於通過Eureka的自動發現（但顯然您可以使用特定的URL訪問任何資源）
監控儀表板
在此項目配置中，每個帶有Hystrix的微服務都通過Spring Cloud Bus（帶有AMQP代理）將指標推送到Turbine。Monitoring項目只是一個帶有Turbine和Hystrix Dashboard的小型Spring引導應用程序。
參見下面的如何啓動和運行它。
讓我們看看負載下的系統行爲：帳戶服務調用了統計信息服務，並且其響應具有不同的模擬延遲。響應超時閾值設置爲1秒。
日誌分析
在嘗試確定分佈式環境中的問題時，集中日誌記錄可能非常有用。Elasticsearch，Logstash和Kibana堆棧使您可以輕鬆搜索和分析日誌，利用率和網絡活動數據。作者的另一個項目中介紹了現成的Docker配置。
分佈式跟蹤
分析分佈式系統中的問題可能很困難，例如，跟蹤從一個微服務傳播到另一個微服務的請求。試圖找出請求如何在系統中傳輸可能是一個很大的挑戰，特別是如果您對微服務的實現沒有任何瞭解的時候。即使有日誌記錄，也很難說出哪個動作與單個請求相關。
Spring Cloud Sleuth通過提供對分佈式跟蹤的支持來解決此問題。它將兩種類型的ID添加到日誌記錄中：traceId和spanId。spanId代表基本的工作單位，例如發送HTTP請求。traceId包含一組形成樹狀結構的跨度。例如，對於分佈式大數據存儲，跟蹤可能由PUT請求形成。通過對每個操作使用traceId和spanId，我們可以知道應用程序在處理請求時的時間和位置，從而使讀取日誌變得更加容易。
日誌如下，注意[appname,traceId,spanId,exportable]Slf4J MDC中的條目：
2018-07-26 23:13:49.381 WARN [gateway,3216d0de1384bb4f,3216d0de1384bb4f,false] 2999 --- [nio-4000-exec-1] o.s.c.n.z.f.r.s.AbstractRibbonCommand : The Hystrix timeout of 20000ms for the command account-service is set lower than the combination of the Ribbon read and connect timeout, 80000ms.
2018-07-26 23:13:49.562 INFO [account-service,3216d0de1384bb4f,404ff09c5cf91d2e,false] 3079 --- [nio-6000-exec-1] c.p.account.service.AccountServiceImpl : new account has been created: test
- appname：從屬性記錄跨度的應用程序的名稱 spring.application.name
- traceId：這是分配給單個請求，作業或操作的ID
- spanId：發生的特定操作的ID
- exportable：是否應將日誌導出到Zipkin
安全
高級安全配置超出了此概念驗證項目的範圍。爲了更真實地模擬真實系統，請考慮使用https，JCE密鑰庫來加密微服務密碼和Config服務器屬性內容
基礎設施自動化
相互依賴地部署微服務比部署整體應用程序要複雜得多。擁有完全自動化的基礎架構非常重要。我們可以通過持續交付方法獲得以下好處：
- 隨時發佈軟件的能力
- 任何構建都可能最終成爲發行版
- 一次構建工件-根據需要進行部署
這是在此項目中實現的簡單連續交付工作流程：
在此配置中，Travis CI爲每次成功的git push構建標記的圖像。因此，latest在Docker Hub上總是有每個微服務的映像和較舊的映像，並用git commit hash標記。如果需要，可以輕鬆部署其中任何一個並快速回滾。
如何運行所有東西？
請記住，您將啓動8個Spring Boot應用程序，4個MongoDB實例和RabbitMq。確保4 Gb計算機上有可用的RAM。但是，您始終可以只運行重要的服務：網關，註冊表，配置，身份驗證服務和帳戶服務。
在你開始前
- 安裝Docker和Docker Compose。
- 更改.env文件中的環境變量值以提高安全性或保持原樣。
- 確保構建項目： mvn package [-DskipTests]
生產方式
在這種模式下，所有最新映像都將從Docker Hub中提取。只需複製docker-compose.yml並點擊docker-compose up
開發模式
如果您想自己構建映像（例如，對代碼進行一些更改），則必須克隆所有存儲庫並使用maven構建工件。然後跑docker-compose -f docker-compose.yml -f docker-compose.dev.yml up
docker-compose.dev.yml繼承docker-compose.yml有可能在本地構建映像並公開所有容器端口以方便開發。
如果你想開始IntelliJ IDEA的應用程序，您需要可以使用EnvFile插件或手動上市，出口環境變量.env文件（確保它們分別出口：printenv）
重要終點
- http：// localhost：80-網關
- http：// localhost：8761-尤里卡儀表板
- HTTP：//本地主機：9000 /錐 -蝟控制板（汽輪機流鏈接：http://turbine-stream-service:8080/turbine/turbine.stream）
- http：// localhost：15672 -RabbitMq管理（默認登錄名/密碼：guest / guest）
筆記
所有Spring Boot應用程序都需要已運行的Config Server才能啓動。但是由於depends_ondocker-compose選項，我們可以同時啓動所有容器。
另外，所有應用程序啓動後，服務發現機制都需要一些時間。在實例，Eureka服務器和客戶端在其本地緩存中都具有相同的元數據之前，客戶端無法發現任何服務，因此可能需要3個心跳。默認心跳週期爲30秒。
轉發+關注，然後私信回覆關鍵字 “項目”即可獲得《piggymetrics》的源碼地址