SpringCloud學習 -筆記

前提

此筆記是根據《瘋狂Spring Cloud微服務架構實戰》編寫，圖片也是來源這本書。若需要詳細的學習，請購買原書本.

架構要求

在大數據、高并發的環境下，系統架構需要面對更為嚴苛的挑戰，起碼滿足一下要求.

• 高性能

  應用程序基本要求

• 獨立性

  其中一個模板出現bug或其他問題，不可影響其他模塊、整個應用使用

• 容易擴展

  應用每一個節點都可以根據實際需求擴展 .

• 便于管理

  對于各個模塊的資源，都可以輕松管理、升級、減少維護成本

• 狀態監控與警報

  對整個應用程序進行監控、當某一個節點出現問題，能及時發出警報

微服務

Microservice

微服務是一種架構風格，將單體應用劃分為小型的服務單元，微服務之間只用HTTP的 API 進行資源訪問與操作

Netflix OSS(Netflix Open Source Software Center)

框架源自互聯網影片提供商，最近幾年成立自己的開源中心。這個開源組織專注大數據、云計算方面及時，提供多個開源框架。這些框架包括大數據工具、構建工具、基于云平臺的服務工具。Netflix所提供的這些框架，很好遵循微服務所推崇的理念，實現去中心化的服務管理、服務容錯等機制。

Spirng Cloud不是一個具體的框架，相當一個工具箱，提供各類工具，可以幫助我們快速構建分布式系統。

Spring Cloud主要模塊

Spring Cloud Netflix模塊主要封裝Netfiix以下的項目

• Eureka
  基于REST服務的分布式中間件，主要用于服務管理。

• Hystrix
  容錯框架，通過添加延遲閥值以及容錯的邏輯，幫助我們控制分布式系統間組件的交互

• Feign
  一個REST客戶端，目的是為了簡化Web Service客戶端的開發

• Ribbon
  負載均衡框架，在微服務集群中為客戶端的通信提供支持，它主要實現中間層應用程序的負載均衡

• Zuul
  為微服務集群提供代理、過濾、路由等功能

• Spirng Cloud Config

  為分布式系統提供配置服務器和配置客戶端，通過它們的配置，可以很好地管理集群中的配置文件

• Spring Cloud Sleuth

  服務跟蹤框架，可以與Zipkin、Apache Htrace和ELK等數據分析、服務跟蹤系統進行整合，為服務跟蹤、解決問題提供便利

• Spring Cloud Stream

  用于構建消息驅動微服務的框架，在Spring Boot基礎上，整合Spring Integration來連接消息代理中間件

• Srping Cloud Bus

  連接RabbitMQ、Kafka等消息代理的集群消息

源碼地址

書本Demo下載

搭建開發環境

這里不展示JDK、maven安裝和配置，直接下載一個Idea，自帶有默認maven

spring boot也不展示，請具備spring boot基礎學習

微服務發布與調用-Eureka

本章講述Spirng Cloud中Eureka的使用，Eureka在服務器上發布、調用微服務，Eureka的配置以及Eureka集群

Eureka 介紹

Eureka提供基于REST的服務，在集群主要用于服務管理。

Eureka提供基于Java語言的客戶端組件，客戶端組件實現負載均衡功能，為業務組件的集群部署創造條件。

使用Eureka，將業務組件注冊到Eureka容器中，組件可進行集群部署，Eureka維護這些服務的列表并自動檢查它們的狀態.

Eureka架構圖

Eureka Demo項目實踐

結構圖

啟動Eureka服務器項目、其次Eureka客戶端提供者項目（提供接口）、最后Eureka客戶端服務調用者項目(通過Eureka服務器項目調用提供者的接口)

源碼地址

Eureka 集群搭建 實踐

結構圖

源碼地址

Eureka 健康

• spirng-actuator 健康檢查
• 服務自檢
• 服務查詢
• 元數據使用
• 心跳自我保護模式

源碼地址

負載均衡-Ribbon

Ribbon介紹

Ribbon是Netflix下的負載均衡項目，它在集群中為各個各個客戶端的通信提供了支持，主要是想中間層應用程序的負載均衡。一下特性
- 負載均衡器，可支持插拔式的負載均衡規則
- 對多種協議提供支持。Http、TCP、UDP
- 集成負載均衡功能的客戶端

Ribbon 主要三大子模塊
- ribbon-core：該模塊為Ribbon項目的核心，主要包括負載均衡器接口定義、客戶端接口定義、內置的負載均衡實現等API
- ribbon-eureka：為Eureka客戶端提供負載均衡實現類
- ribbon-httpclient： 對Apache的HttpClient進行封裝，該模塊提供含有負載均衡功能的REST客戶端

Ribbon Demo項目實踐

源碼地址

Ribbon 負載均衡規則

使用負載均衡器ILoaderBalancer，可定制負載均衡規則

Ribbon自帶的負載均衡規則

• RoundRobinRule
  系統默認的規則，通過簡單輪詢服務列表選擇服務器，其他規則在很多情況下仍然使用RoundRobinRule
• AvailabilityFilteringRule
  該規則會忽略以下服務器
  
  1. 無法連接的服務器。默認情況下，如果3次連接失敗，該服務器會被置為“短路”狀態，該狀態持續30秒；如果再次連接失敗，“短路”狀態持續時間將會以集合級數增加。可以通過修改niws.loadbalancer.clientName.connection-FailureCountThreshold屬性配置連接失敗次數
  2. 并發數過高的服務器。如果連接到改服務器的并發數過高，也會被這個規則忽略，可以通過修改clientName.ribbon.ActiveConnectionsLimit屬性設定最高并發數
• WeightedResponseTimeRule
  為每個服務器賦予一個權重值，服務器的相應時間越長，該權重值就越少，這個規則會隨機選擇服務器，權重值有可能會決定服務器的選擇。
• ZoneAvoidanceRule
  該規則以區域、可用服務器為基礎進行服務器選擇。使用Zone對服務器進行分類，可用理解為機構或者機房。
• BastAvailableRule
  忽略“短路”的服務器，并選擇并發數較低的服務器
• RandomeRule
  隨機選擇可用的服務器
• RetryRule
  含有重試的選擇邏輯，如果使用RoundRobinRule選擇的服務器無法連接，將重新選擇服務器

源碼地址

ping機制

可自定義Ping規則

使RestTemplate具備負載均衡能力

RestTemplate負載均衡能力介紹

使用@LoadBalanced注解的RestTemplate將具有負載均衡功能
Spring容器啟動時，會將這些加上@LoadBalanced注解的RestTemplate添加攔截器, 攔截器使用LoadBalancerClient處理請求

源碼地址

REST客戶端Feign

REST客戶端

CXF是目前一個較為流行的WEB service框架，使用CXF可以發布和調用使用各種協議的服務，包括SOAP協議、XML/HTTP等。

Restlet是一個輕量級的REST框架,可發布和調用REST風格的WEB service

Fegin是Github開源項目，目的簡化Web Service客戶端的開發。在使用Fegin，可使用注解修飾接口，被注解修飾接口具有訪問Web Service能力。Fegin支持插件式的編碼器和解碼器，可通過特性對請求和響應進行不同的封裝和解析

Feign Demo實踐

源碼地址

Spirng Cloud 整合Feign 實踐

• Spring Cloud整合

Feign 作為Spring Cloud Netflix的REST客戶端，插件式機制可以靈活整合項目中，Spring Cloud對其進行封裝，本身就具有負載均衡的能力，可以訪問集群的服務。

• 配置相關

可以自定義編碼器、解碼器、請求攔截器、接口日志（日志文件生成）、HTTP客戶端、壓縮配置（對請求和響應進行壓縮）…..等

源碼地址

Spring Cloud的保護機制

系統架構需要考慮橫向擴展、單點故障問題，對于一個龐大的應用集群，部分服務或者機器出現問題不可避免。在出現故障，如何減少故障的影響，保障集群的高可用。
微服務集群中，不管是服務器、客戶端，都支持集群部署

保護框架：Hystrix

集群容錯框架Hystrix

Hystrix 通過添加延遲閥值以及容錯的邏輯，幫助控制分布式系統間組件的交互。Hystrix通過隔離服務的訪問點、停止它們之間的級聯故障、提供可回退操作實現容錯.

容錯機制結構圖

Hystrix功能點
- 當所依賴的網絡服務發生延遲或者失敗，對訪問客戶端程序進行保護，就像容錯機制結構圖
- 分布式系統中，停止級聯故障
- 網絡服務恢復正常后，可以快速恢復客戶端的訪問能力
- 調用失敗時執行服務回退
- 可支持實時監控、報警和其他操作

Hystrix Demo實踐

Hystrix運作流程圖

源碼地址

Hystrix 命令執行

命令對象可以使用以下方法執行命令
除execute方法同步，其他都是異步執行

• toObservable

  返回一個最原始的可觀察實例，Observable是RxJava的類，使用該對象可以觀察命令的執行過程，并且將執行信息傳遞給訂閱者

• observe

  調用toObservable方法，獲取一個原始的Observable實例后，使用ReplaySubject作為原始Obervable的訂閱者

• queue

  通過toObservable方法獲取原始的Observable實例，在調用Observable的toBlocking方法得到一個BlockingObservable實例，最后調用BlockingObservable的toFuture方法返回Future實例，調用Future的get方法得到執行結果

• exexute

• 調用queue的get方法返回名的執行結果，該方法為同步執行

源碼地址

屬性配置

API

源碼地址

回退模式

回退情況
- 斷路器被打開
- 線程池、隊列、信號量滿載
- 實際執行命令失敗

源碼地址

斷路器開啟與關閉

斷路器一旦開啟，直接調用回退方法，不再執行命令，而且不會更新鏈路的健康狀況。開啟需要滿足兩個條件

1. 整個鏈路達到一定閾值，默認情況下，10秒內產生超過20次請求，則符合第一個條件
2. 滿足第一個條件的情況下，如果請求的錯誤百分之比大于閾值，則會打開斷路器，默認為50%

斷路器打開后，在一段時間內，命令不會再執行(一直觸發回退)，這段時間稱作“休眠期”。休眠期的默認值為5秒，休眠期結束后，Histrix嘗試執行一次命令，此時斷路器狀態不是開啟，也不是關閉，而是一個半開的狀態，如果這一次命令執行成功，則關閉斷路器并清空鏈路的健康信息；
如果執行失敗，斷路器會繼續保持打開的狀態

源碼地址

隔離機制

命令的真正執行，除了斷路器關閉，還需要執行命令的線程池或者信號量是否滿載。
如果滿載，命令就不會執行，而是直接觸發回退，這樣的機制，在控制命令的執行上，實現錯誤的隔離

Hystrix 提供兩種隔離策略

1. Thread : 默認值，有線程池決定命令的執行，如果線程池滿載，則不會執行命令。Hystrix使用ThreadPoolExecutor控制線程池行為，線程池的默認大小為10
2. SemaPhore : 由信號量決定命令的執行，當請求的并發數高于閾值，就不再執行命令。相對于線程策略，信號量策略開銷更小，但是該策略不支持超時以及異步，除非對調用的服務有足夠的信任，否則不建議使用該策略進行隔離。

如果對于所調用的服務有足夠的信任，可以使用信號量，減少系統開銷

源碼地址

合并請求

可以將一個時間段內的相同請求（參數不同），收集到同一個命令中執行，節省線程開銷，減少網絡連接，提升性能
至少包含以下3個條件

1. 需要有一個執行請求的命令，將全部參數進行整理，然后調用外部服務
2. 需要有一個合并處理器，用于收集請求，以及處理結果
3. 外部接口提供支持（調用的接口提供多個id提交支持）

源碼地址

請求緩存

若在一次請求中，多個地方調用同一個接口，可以考慮使用緩存
這里的一次請求緩存，請求完成后，緩存將消失。每次請求將重新生成緩存

源碼地址

Spring Cloud整合Hystrix

feign整合Hystrix

Hystrix監控

源碼地址

微服務集群網關

Zuul框架

介紹

SpirngCloud集群提供多個組件，用于進行集群內部的通信，例如服務管理組件Eureka，負載均衡組件Ribbon。如果集群提供API或者Web服務，需要與外部進行通信，比較好的方式是添加一個網管，將集群的服務都隱藏到網關后面。這種做法對于外部客戶端來說，無須關心集群的內部結構，只需關心網關的配置等信息；對于Spring Cloud集群，不必暴露過多的服務，提升集群安全性

代理層作用集群的大門，在技術選取上尤為重要，很多傳統解決方案選擇Nginx、Apache等服務器。Netflix提供了自己的解決方案：Zuul。為微服務集群提供代理、過濾、路由功能

Zuul功能

• 身份驗證和安全性
  對需要身份驗證的資源進行過濾，拒絕處理不符合身份認證的請求
• 觀察和監控
  跟蹤重要的數據，為我們展示準確的請求狀況
• 動態路由
  將請求動態路由到不同的服務集群
• 負載分配
  設置每種請求的處理能力，刪除那些超出限制的請求
• 靜態響應處理
  提供一些靜態的過濾器，直接響應一些請求，而不將它們轉發到集群內部
• 路由多樣化
  除了可以將請求路由到Spring Cloud集群外，還可以將請求路由到其他服務

Web項目中使用Zuul

第一個Demo實踐

源碼地址

過濾器運行機制

在微服務集群中使用Zuul

Demo流程

Zuul Http客戶端

路由配置

簡單路由
以http、https、完整的url配置，就是簡單路由
application.yml代碼如下

zuul:
  #所有帶有books前綴的URL請求轉發到8090訪問（不帶有books的就正常）
  routes: { books: {"url": "http://localhost:8090/"}}

簡單路由通過過濾器SimpleHostRoutingFilter使用Httpclient進行轉發，為了保證轉發性能，使用了連接池功能。

HttpClient連接池屬性

• zuul.host.maxTotalConnection
  目標主見的最大連接數，默認為200；配置該項屬性，相當于調用PoolingHttpClientConnectionManager的setMaxTotal方法
• zuul.host.maxPerRouteConnections
  每個主機的初始連接數，默認為20；配置該項屬性，相當于調用PoolingHttpClientConnectionManager的setDefaultMaxPerRoute方法

源碼地址

跳轉路由

請求url訪問網關的地址A，會跳轉到訪問地址B（forward），處理跳轉路由的過濾器為SendForwardFilter

application.yml加入代碼如下

zuul:
  routes:
  #創建一個名稱叫forwardRoutes的路由規則，所有帶有test前綴的URL請求跳轉到本項目/source/hello路徑訪問
     forwardRoutes: {path: "/test/*",url: "forward:/source/hello"}

源碼地址

Ribbon路由

《在微服務集群中使用Zuul》的例子就是使用Ribbon路由，直接以注冊的服務id做路由轉發;處理跳轉路由的過濾器為RebbonRoutingFilter

application.yml代碼如下

zuul:
  routes:
  #Ribbon路由 創建一個名稱叫eureka-invoker的路由規則，所有帶有sale前綴的URL請求轉發到服務id eureka-invoker訪問
  #若是這里的serviceId不填寫，會采用路由規則的名稱做serviceId
     eureka-invoker: {path: "/sale/**",serviceId: "eureka-invoker"}

源碼地址

自定義路由規則

在SpringBoot弄多一個配置類，設置一個Bean PatternServiceRouteMapper配置自定義路由規則

源碼地址

忽略路由規則
application.yml代碼如下

zuul:
  #忽略路由規則
  ignored-patterns: /sale/noRoute

源碼地址

Zuul的其他配置

請求頭配置

zuul:
  #全局配置 所有請求轉發都帶有 原請求的請求頭屬性
  sensitive-headers: [accept-language,cookie]
  #全局配置 所有請求頭和響應頭信息均被忽略
  ignored-headers: [accept-language]
  routes: 
     eureka-invoker:
        path: "/sale/**"
        serviceId: "eureka-invoker"
        #請求頭信息僅對當前路由規則生效 
        sensitive-headers: [accept-language,cookie]

源碼地址

路由端點
需在配置文件關閉安全認證

Zuul與Hystrix

對路由進行FallBack

源碼地址

Zuul中預加載Ribbon

客戶端相關的Bean會延遲加載，第一次調用集群服務時，才會初始化這些對象。如果想提前加載，在配置文件application.yml 代碼

zuul: 
    rebbon: 
        eager-load: 
           enable: true

Zuul的功能進階

本節內容針對Zuul原理講解

過濾器優先級

Spring Cloud為Http請求各個階段提供多個過濾器，這些過濾器的執行順序由他們各自提供的一個int值決定，提供的值越小，優先級就越高。

自定義過濾器
請結合代碼

源碼地址

動態加載過濾器

由于重啟網關代價太大，為了解決該問題，Zuul提供過濾器的動態加載功能.
使用Groovy編寫過濾器，讓Zuul動態加載

源碼地址

禁用過濾器
可在application.yml中禁用部分過濾器

請求上下文

HTTP請求的全部信息都封裝在一個RequestContext對象中，改對象繼承ConcurrentHashMap。可將RequestContext看作一個Map，RequestContext維護者當前線程的全部請求變量，例如請求的URI、serviceId、主機等信息。

本小節以RequestContext為基礎，編寫一個自定義過濾器，使用RestTemplate調用

源碼地址

@EnableZuulServer注解

除了使用@EnableZuulProxy開啟Zuul功能，還可以使用@EnableZuulServer開啟。該注解像一個“低配版”的@EnableZuulProxy，使用@EnableZuulServer，spring內置的簡單路由過濾器、Ribbon路由過濾器等都不會被啟用

如下圖

默認情況下Zuul不具備集群服務的能力，也不具備簡單路由的功能

error過濾器

各階段的過濾器執行時，拋出的異常會被捕獲，然后調用RequestContext的setThrowable方法設置異常。error階段的SendErrorFilter過濾器會判斷RequestContext是否存在異常(getThrowable是否為null)，如果存在，才會執行SendErrorFilter過濾器

SendErrorFilter執行時，會將異常信息設置到HttpServletRequest中，再調用RequestDispatcher的forward方法，默認調整到/error頁面

源碼地址

動態路由*
路由規則動態刷新功能在實際應用中非常重要

微服務與消息驅動

Spring Cloud Stream介紹

Spring Cloud Stream是一個用于構建消息驅動微服務的框架，該框架在SpirngBoot的基礎上整合了Spring Intergration來連接消息代理中間件.支持多個消息中間件的自定義配置，同時吸收這些消息中間件的部分概念，例如持久化訂閱、消費者分組和分區等概念

Stream框架的組成部分

1. Stream框架自己的應用模型
2. 綁定器抽象層，可以與消息代理中間件進行綁定。通過綁定器API，實現插件式的綁定器
3. 持久化訂閱的支持
4. 消費者組的支持
5. Topic分區的支持

消息代理中間件
如ActiveMQ、Kafka、RabbitMQ框架

RabbitMQ框架

RabbitMQ是一個輕量級消息代理中間件，支持多種消息通信協議，支持分布式部署，同事支持運行于多個操作系統，具有靈活高可用等特性。

RabbitMQ支持多種協議，其中最為重要是高級消息隊列協議AMQP，基于此協議，消息客戶端和消息代理中間件不收開發語言、具體產品的約束。

AMQP模式大概

下載與運行
- 下載64位Erlang、RabbitMQ

• 安裝Erlang后
  建立一個環境變量 ERLANG_HOME 指向Erlang目錄F:\JAVA\erl9.3

• RabbitMQ默認安裝目錄，不能有空格

• 管理員身份運行 開始–>所有程序–>RabbitMQ Service-start

• 管理員身份運行 開始–>所有程序–>RabbitMQ Server–>RabbitMQ Command Prompt (sbin dir)

輸入命令

#查看插件狀態
rabbitmq-plugins list
#啟用插件管理
rabbitmq-plugins enable rabbitmq_management

• 訪問地址,賬號密碼都為：guest

編寫生產者

源碼地址

編寫消費者

源碼地址

交換器、綁定與隊列

生產者不會直接將消息發給隊列，只會將消息發送給交換器，交換器一邊從生產者接收消息，一邊將消息發送給各個隊列

交換器與隊列之間的連接叫做“綁定Binding”。每一個綁定都有一個名字，叫做binding key。當消息發送過來時，消息會帶有一個路由的標識，叫做routing key

交換器根據binding key、routing key決定將消息發送給哪個隊列。RabbitMQ提供4種類型的交換器

• durect
  根據生產者傳過來的routing key是否相等binding key，決定將消息發送給哪個隊列
• topic
  根據生產傳過來的routing key 是否匹配一定的表達式，決定消息發送給哪個或者哪些隊列
• fanout
  將消息發送給交換器知道的全部隊列，這種交換器會忽略設置的routing key
• headers
  根據消息的頭信息決定將消息發送給哪個隊列

Apache Kafka框架

用于處理數據流的分布式消息框架，擁有水平擴展、容錯、高效等特性
- 構建系統間進行實時數據傳輸的通道
- 構建對數據流進行轉換或相應的實時應用

Kafka整體結構與RabbitMQ類似

運行Kafka服務器

下載與運行

編寫生產者

源碼地址

編寫消費者

源碼地址

消費者組

消費者為自己添加一個消費者組的標記，每一條發布到Topic的記錄，都會被交付給消費者組的一個消費者實例。
如果多個消費者實例擁有相同的消費者組，那么這些記錄分配到個個消費者實力上，已達到負載均衡的目的。
如果所有消費者都有不同的消費者組，那么每一條記錄都會廣播到全部的消費者進行處理。

如果消費者A、B 同屬一個消費者組，那么生產者發送一條消息，僅會交給其中一個消費者處理；如果兩個消費者不屬于同一個消費者組，那么該消息會發給他們（每一個進行處理）

開發消息微服務

程序實踐

源碼地址

編寫生產者
源碼地址

編寫消費者
源碼地址

更換綁定器

在Maven將Rabbit的依賴改為Kakfa的依賴即可

Sink、Source與Processor

為簡化開發，Spring Cloud Stream內置3個接口:Sink、Source、Processo綁定通道

源碼地址

消費者組

消費組相同，僅有一個消費者處理。消費組不同，則全部消費者處理

源碼地址

集群配置中心

Spring Cloud Config

Spirng Cloud Config
為分布式系統提供服務器、客戶端配置，可以很好管理集群中的配置文件

配置服務器功能

提供訪問配置的服務接口
對屬性進行加密和解密
簡單地嵌入Spring Boot的應用中

配置客戶端功能

綁定配置服務器，使用遠程的屬性初始化Spring容器
對屬性進行加密和解密
屬性改變時，可以對他們進行重新加載
提供與配置相關的幾個管理端點
在初始化引導程序的上下文，進行綁定配置服務器和屬性解密等工作，也可以實現其他工作

應用結構

引導程序簡介
Spring Cloud程序進行容器初始化先建立一個“引導上下文”（Boostrap Context），再創建主應用的上下文。

我們的主應用程序上下文通常讀取的是application.yml文件，而引導文件則會讀取bootstrap.yml 文件。因為application.yml配置會在bootstrap.yml后加載，所以如果兩份配置文件同時存在，且存在key相同的配置，則application.yml會覆蓋bootstrap.yml

• 引導上下文在主應用上下文前創建，是主應用上下文的父上下文
• 默認情況下，配置客戶端的引導上下文在創建會讀取遠程配置（去配置服務器中讀取）

SpringCloudConfig讀取git項目的配置

源碼地址

刷新配置
若git文件發生變化，Config客戶端需要刷新讀取配置

客戶端需加入依賴spring-boot-starter-actuator
然后調用項目url+ /refresh。如：localhost:8081/actuator/refresh

此例子測試失敗

刷新Bean

配置刷新后，獲取的屬性也需要刷新
通過注解@RefreshBrean刷新

此例子測試失敗

程配置（去配置服務器中讀取）

配置的加密和解密

實際應用涉及很多敏感數據，這些數據會被加密保存git倉庫，最常見就是數據庫密碼。SpringCloudConfig為這些敏感數據提供加密和解密的功能，加密后的密文在傳輸給客戶端會進行解密。配置服務器支持對稱加密和非對稱加密，對稱加密使用AES算法，非對稱加密使用RSA算法

為服務器安裝JCE
下載地址
解壓的jar，放到JavaHome/jre/lib/security/目錄替換

加密和解密端點

此例子測試失敗

其他配置

服務器健康指示器

在server端的application.yml屬性spring.cloud.config.server.health.repositories配置

此例子測試失敗

客戶端的錯誤提前與重試機制

實際應用可能有一些特殊需求，客戶端比較關心配置服務器是否能連接上，啟動時如果無法連接，寧可自己啟動失敗.

此例子測試失敗

安全配置

加入spring-boot-starter-security依賴
然后查看服務端控制臺輸出的密碼設置到客戶端配置中

源碼地址

訪問服務器配置
上面的例子可以通過localhost:8060/config-dev.properties 訪問

相應的規則如下

 /{application}/{profile}[/{label}]

 /{application}-{profile}.yml

 /label/{application}-{profile}.yml

 /{application}-{profile}.properties

 /label/{application}-{profile}.properties

application表示客戶端的應用名稱(spring.application.name)，profile表示客戶端所使用的配置，label表示配置的分支

整合使用

介紹SpringCloudConfig與其他框架的整合（Eureka、Zuul、SpringCloud Bus）

下面的SVN換Git

源碼地址

整合Spring CloudBus刷新配置
下面的SVN換Git

此例子到最后沒給出具體操作，導致使用MQ的那一步刷新是失敗的

源碼地址

微服務跟蹤

使用SpringCloud搭建服務集群、不論是Eureka服務器、服務實例、配置服務器、網關等節點，都可以橫向擴展。一旦集群數量過多，并且存在復雜的依賴關系，管理將會變成一件很麻煩的事件.
每個服務依賴其他服務，如果出現異常、超時情況，排查問題變得非常困難。

服務跟蹤系統 Spring Cloud Sleuth

• Trace
  表示整個跟蹤過程，從用戶發起請求到最終的響應. 一次跟蹤包含多個跨度，這些跨度以樹狀結構進行保存
• Span
  跨度，表示一次調用的過程，一次跟蹤包含多次調用過程。假設用戶向A服務發送請求，A服務又要調用B服務，那么此時將會產生連個跨度：用戶調用A服務、A服務調用B服務
  
  整個跟蹤過程中，這些跨度是樹狀結構的

事件標識，用于記錄事件的存在，主要為

• Client Sent: cs
  表示客戶端發送請求，這個標識意味著跨度的開始。例如前面的A服務向B服務發送請求，A服務就是客戶端
• Server receivd: sr
  表示服務端收到請求，并開始進行處理
• Server sent: ss
  表示服務器端完成請求的處理，并對客戶端做出響應
• Client Received
  表示客戶端接收到響應，意味著整個跨度的結束

Sleuth 整合Zipkin

Zipkin 是一個分布式跟蹤系統，主要用于手機、管理微服務產生的數據。ZipKin的設計基于Google Dapper。Zipkin在得到這些數據后，提供數據查詢、分析的功能

構建Zipkin服務器項目

源碼地址

使用Mysql保存數據

使用介紹

使用消息采集數據

使用介紹

Sleuth 整合ELK

Elastic為數據存儲、分析提供一整套解決方案，其中最著名就是ELK系統。
包括以下三個項目

• Elasticsearch
  是一個分布式數據倉庫，提供RESTful倉庫，提供RESTful服務，可用于數據存儲
• Logstash
  主要用于數據收集、轉換、可將數據保存到指定的數據倉庫中
• Kibana
  是可視化的數據管理平臺、主要用于操作Elasticsearch的數據，提供多種圖表展示數據，支持動態報表

ELK與微服務集群的關系圖

下載并安裝、啟動ELK三個組件

使用Kibana分析Json日志文件

項目日志使用Logback轉JSON

此Demo沒興趣，直接跳過

微服務數據庫實戰

Spring Data

Srping Data框架目標是為數據的訪問提供一個通用的模型

不管訪問數據庫使用什么技術，訪問什么類型數據庫，使用了Srping Data都可以用同樣方式、代碼實現訪問.(包括關系型數據庫、非關系型數據庫)

Spring Data功能

• 提供數據與對象映射的抽象層，同一個對象可以映射為不同數據庫的數據
• 根據數據存儲接口的方法名，自動實現數據查詢
• 為各個領域模型提供最基本的實現，如CRUD功能
• 可在原有邏輯基礎上，實現自定義的數據庫操作邏輯

Spring Data模塊

• Spring Data JPA
  該模塊提供 基本的數據操作功能，可減少數據訪問層的開發工作量
• Spring Data MongoDB
  使用該模塊可輕松操作MongoDB的數據
• Srping Data Redis
  使用該模塊可操作Redis數據庫，并且操作過程進行極大的簡化

Spring Data與JPA

JPA

Jave Persistence API的簡稱，是Sun早期推出的持久層規范，目前實現框架有HIbernate、OpenJPA等

Demo 直接跳過，Spring Boot早就提供的例子

Spring Data與MongoDB

Demo 直接跳過，Spring Boot早就提供的例子

Spring Data與Redis

可通過注解方式，Spring 提供的CRUD接口，將實體持久化到Redis