由於最近公司業務需要，需要搭建基於Spring Cloud的微服務系統。遍訪各大搜索引擎，發現國內資料少之又少，也難怪，國內Dubbo正統治着天下。但是，一個技術總有它的瓶頸，Dubbo也有它捉襟見肘的地方。所幸霸主Spring也推出了一整套微服務解決方案，各個子項目也巧妙地解決了分佈式系統開發過程中的各種各樣的問題。看了很多國內的資料，最早的幾份文檔也是互相借用，恐怕究竟是什麼都說不清楚了。擼主在github上面發現幾個很好的相關項目，就想翻譯來看看。這篇其實是項目說明，但是裏面很多知識點是百度找不到的，下面就來看看吧，想要部署來看看的可以去下載：

這個項目的名字叫：Piggy Metrics，一個供個人處理財務的解決方案。

簡介
這是一款概念性的應用程序，基於Spring Boot，Spring Cloud和Docker 簡單演示了微服務的架構模式，順便說一句，它還有一個非常漂亮整潔的用戶界面。下面是它的界面演示：

功能服務

PiggyMetrics被分解爲三個核心微服務。這些服務都是圍繞某些業務能力組織的可獨立部署的應用程序。

賬戶服務
包含一般用戶輸入邏輯和驗證：收入/費用項目，儲蓄和帳戶設置。

Method	Path	Description	User authenticated	Available from UI
GET	/accounts/{account}	獲取指定的帳戶數據
GET	/accounts/current	獲取當前帳戶數據	×	×
GET	/accounts/demo	獲取模擬賬戶數據（預填收入/費用項目等）		×
PUT	/accounts/current	保存當前帳戶數據	×	×
POST	/accounts/	註冊新帳號		×

統計服務
對主要統計參數執行計算，併爲每個帳戶的時間序列。數據點包含基準貨幣和時間段的值。此數據用於跟蹤帳戶生命週期中的現金流動動態（尚未在UI中實現的花式圖表）。

Method	Path	Description	User authenticated	Available from UI
GET	/statistics/{account}	獲取指定的帳戶統計信息
GET	/statistics/current	獲取當前帳戶統計信息	×	×
GET	/statistics/demo	獲取模擬帳戶統計信息		×
PUT	/statistics/{account}	創建或更新指定帳戶的時間序列數據點

通知服務
存儲用戶聯繫信息和通知設置（如提醒和備份頻率）。計劃工作人員從其他服務收集所需的信息，並向訂閱的客戶發送電子郵件。

Method	Path	Description	User authenticated	Available from UI
GET	/notifications/settings/current	獲取當前的帳戶通知設置	×	×
PUT	/notifications/settings/current	保存當前帳戶通知設置	×	×

**小結：

每個微服務都有自己的數據庫，因此沒有辦法繞過API和直接訪問數據庫。
在這個項目中，使用MongoDB作爲每個服務的主數據庫。它是支持多種編程語言持久性架構（包括最適合服務需求的數據庫類型）。
Service-to-service的通信是相當簡單的：各個微服務之間的通信只使用同步的REST API。在現實世界中通常的做法是使用交互風格的組合。例如，執行同步GET請求以檢索數據，並通過消息代理使用異步方法進行創建/更新操作，以便分離服務和緩衝消息，這爲我們帶來了一致性。

基礎服務設施

在分佈式系統中有一些常見的架構，這可以幫助我們理解核心服務的工作原理。Spring Cloud提供了強大的工具來增強基於Spring Boot的應用程序，以此來實現這些架構。

Config service
Spring Cloud Config是用於分佈式系統的水平可擴展的集中式配置服務。支持本地存儲、Git和Subversion。

在這個項目中，使用native profile，它從本地類路徑加載配置文件。可以查看shared在Config服務資源中的目錄。現在，當通知服務請求其配置時，配置服務以shared/notification-service.yml和shared/application.yml響應（在所有客戶端應用程序之間共享）。

客戶端使用
只需構建具有spring-cloud-starter-config依賴的Spring Boot應用程序，自動配置將完成其餘所有工作。

現在，不需要在應用程序中使用任何嵌入式屬性。只需提供bootstrap.yml應用程序名稱和配置服務url：

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

使用Spring Cloud Config，可以動態地更新配置。
例如，EmailService bean已註釋@RefreshScope。這意味着，可以更改電子郵件文本和主題，而不需要重新部署啓動通知服務。

首先，在Config服務器中更改所需的屬性。然後，對Notification服務執行刷新請求： curl -H "Authorization: Bearer #token#" -XPOSThttp://127.0.0.1:8000/notifications/refresh

此外，也可以使用Repository webhooks自動執行此過程

**小結：

動態更新有一些限制。@RefreshScope不與@Configuration類一起使用，並且不影響@Scheduled方法
fail-fast屬性意味着Spring Boot如果它無法連接到Config
Service就將啓動失敗，這在批量啓動時非常有用。
安全注意事項請往下看

Auth service
授權的責任完全抽取到單獨的服務器，它爲後端資源服務授予OAuth2令牌。Auth服務器用於用戶授權以及在外圍內的安全的機器對機器通信。

在這個項目中，我使用Password credentials授權類型的用戶授權（因爲它只由本地PiggyMetrics UI使用）和Client Credentials授予微服務權限。

Spring雲安全提供了方便的註釋和自動配置，使得從服務器端和客戶端端都很容易實現。您可以在文檔中瞭解更多信息，並在Auth Server代碼中檢查配置詳細信息。

從客戶端，一切工作與傳統的基於會話的授權完全相同。您可以Principal從請求中檢索對象，檢查用戶的角色和其他使用基於表達式的訪問控制和@PreAuthorize註釋的東西。

PiggyMetrics（帳戶服務，統計服務，通知服務和瀏覽器）中的每個客戶端都有一個範圍：server用於後端服務，以及ui- 用於瀏覽器。因此，我們還可以保護控制器免受外部訪問，例如：

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

API Gateway
可以看到，有三個核心服務，它們向客戶端公開外部API。在現實世界的系統中，這個數字可以快速增長以及整個系統的複雜性。實際上，上百個服務可能涉及到渲染一個複雜的網頁。

在理論上，客戶端可以直接向每個微服務器發出請求。但是顯然，這個選項有挑戰和限制，如需要知道所有端點地址，分別執行每個信息的http請求，在客戶端合併結果。另一個問題是非web友好的協議，可能在後端使用。

通常一個更好的方法是使用API網關。它是進入系統的單個入口點，用於通過將它們路由到適當的後端服務來處理請求，或者通過調用多個後端服務並聚合結果。此外，它可以用於身份驗證，洞察，壓力和金絲雀測試，服務遷移，靜態響應處理，主動流量管理。

Netflix打開了這樣一個邊緣服務，現在使用Spring Cloud，我們可以使用一個@EnableZuulProxy註釋啓用它。在這個項目中，我使用Zuul來存儲靜態內容（ui應用程序），並將請求路由到適當的微服務。這是一個簡單的基於前綴的路由配置Notification服務：

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

這意味着所有開始的請求/notifications都將路由到Notification服務。沒有硬編碼的地址，你可以看到。Zuul使用服務發現機制來定位通知服務實例，以及斷路器和負載平衡器，如下所述。

Service discovery
另一個公知的架構模式是服務發現。它允許自動檢測服務實例的網絡位置，由於自動擴展，故障和升級，可能會動態分配地址。

服務發現的關鍵部分是註冊表。我在這個項目中使用Netflix Eureka。當客戶端負責確定可用服務實例（使用註冊表服務器）和負載平衡請求的位置時，Eureka是客戶端發現模式的一個很好的例子。

使用Spring Boot，您可以輕鬆地使用spring-cloud-starter-eureka-server依賴關係，@EnableEurekaServer註釋和簡單配置屬性來構建Eureka註冊表。

支持@EnableDiscoveryClient註釋的客戶端支持bootstrap.yml應用程序名稱：

spring：
   application：
     name：notification-service

現在，在應用程序啓動時，它將註冊到Eureka服務器並提供元數據，如主機和端口，運行狀況指示器URL，主頁等。Eureka從屬於一個服務的每個實例接收心跳消息。如果心跳故障切換到可配置的時間表，則實例將從註冊表中刪除。

此外，Eureka提供了一個簡單的界面，您可以跟蹤運行的服務和可用實例數： http://localhost:8761

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

Ribbon
Ribbon是一個客戶端負載均衡器，它爲您提供了對HTTP和TCP客戶端行爲的大量控制。與傳統的負載均衡器相比，每個線上調用不需要額外的跳躍 - 您可以直接聯繫所需的服務。

開箱即用，它與Spring Cloud和服務發現本身集成。Eureka Client提供了可用服務器的動態列表，以便Ribbon可以在它們之間進行平衡。

Hystrix
Hystrix是斷路器模式的實現，它提供了對通過網絡訪問的依賴性的延遲和故障的控制。主要思想是在具有大量微服務的分佈式環境中停止級聯故障。這有助於快速失敗，並儘快恢復 - 自愈的容錯系統的重要方面。

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

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

Feign
Feign是一個聲明式Http客戶端，它與Ribbon和Hystrix無縫集成。實際上，使用一個spring-cloud-starter-feign依賴項和@EnableFeignClients註釋，您擁有一組完整的負載平衡器，斷路器和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);

}

你需要的只是一個接口
你可以用@RequestMapping在Spring MVC控制器和Feign方法之間共享部分
上面的示例指定只需要的服務id -
statistics-service，由於通過Eureka自動發現（但顯然，您可以訪問任何資源與特定的網址）

監視儀表板
在這個項目配置中，Hystrix的每個微服務通過Spring Cloud Bus（使用AMQP代理）將指標推送到Turbine。監控項目只是一個小的Spring啓動應用程序與渦輪和Hystrix儀表板。

看下面如何讓它運行。

讓我們看看我們的系統在負載下的行爲：帳戶服務調用統計服務，它的響應具有不同的模仿延遲。響應超時閾值設置爲1秒。


`0 ms delay`	`500 ms delay`	`800 ms delay`	`1100 ms delay`
表現良好的系統。吞吐量約爲22請求/秒。統計服務中的活動線程數較少。中位服務時間約爲50 ms。	活動線程的數量在增加。我們可以看到紫色線程池拒絕的數量，因此約30-40％的錯誤，但電路仍然關閉。	半開狀態：故障命令的比率大於50％，斷路器啓動。在睡眠窗口的時間後，下一個請求被允許通過。	100％的請求失敗。電路現在永久打開。在睡眠時間後重試不會再次閉合電路，因爲單個請求太慢。

日誌分析
當嘗試在分佈式環境中識別問題時，集中式日誌記錄可能非常有用。Elasticsearch，Logstash和Kibana堆棧使您可以輕鬆搜索和分析您的日誌，利用率和網絡活動數據。我的其他項目中描述的即開即用 Docker配置。

安全
高級安全配置超出了此概念驗證項目的範圍。對於真實系統的更真實的模擬，考慮使用https，JCE密鑰庫加密微服務密碼和配置服務器屬性內容（有關詳細信息，請參閱文檔）。

基建自動化

部署微服務及其相互依賴性，比部署單片應用程序要複雜得多。擁有完全自動化的基礎設施非常重要。我們可以通過持續交付方法實現以下優勢：

隨時釋放軟件的能力
任何構建可能最終都是發佈
構建工件一次 - 根據需要部署

這裏是一個簡單的連續交付工作流，在這個項目中實現：

在此配置中，Travis CI爲每個成功的git push建立標記的映像。因此，latest對於Docker Hub上的每個微服務總有圖像，並且用git提交哈希標記的舊圖像。它很容易部署任何一個，並快速回滾，如果需要。

如何運行所有的東西？
記住，你要啓動8個Spring Boot應用程序，4個MongoDB實例和RabbitMq。確保您4 Gb的計算機上有可用的RAM。您可以始終運行重要的服務，雖然：網關，註冊表，配置，Auth服務和帳戶服務。

在你開始之前
- 安裝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。

開發模式
如果你想自己構建圖像（例如在代碼中有一些變化），你必須使用maven克隆所有的倉庫和構建工件。然後，運行docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

docker-compose.dev.yml繼承docker-compose.yml具有在本地構建映像的額外可能性，並公開所有容器端口以方便開發。

重要端口

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)

小結

所有Spring Boot應用程序都需要運行Config Server進行啓動。但是我們可以同時啓動所有容器，因爲fail-fastSpring Boot屬性和docker restart: always-compose選項。這意味着所有依賴的容器將嘗試重新啓動，直到Config Server啓動並運行。

此外，在所有應用程序啓動後，服務發現機制需要一些時間。任何服務都不可用於客戶端發現，直到實例，Eureka服務器和客戶端都在其本地緩存中具有相同的元數據，因此可能需要3個心跳。默認心跳週期爲30秒。

Spring Boot、Spring Cloud、Docker的微服務系統架構實踐 -轉

功能服務

基礎服務設施

基建自動化

DAPPER 事務 TRANSACTION

設計模式學習筆記十一------迭代器模式

Idea安裝findbugs插件，以及findbugs安裝find security bugs插件

NGINX-配置沃通SSL證書步驟

TOMCAT7-REDIS-SESSION共享

Spring Boot、Spring Cloud、Docker的微服務系統架構實踐 -轉

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結