Spring Cloud構建微服務架構（四）分散式配置中心（續）

先來回顧一下，在前文中我們完成了什麼：

構建了config-server，連線到Git倉庫
在Git上建立了一個config-repo目錄，用來儲存配置資訊
構建了config-client，來獲取Git中的配置資訊

在本文中，我們繼續來看看Spring Cloud Config的一些其他能力。

高可用問題

傳統作法

通常在生產環境，Config Server與服務註冊中心一樣，我們也需要將其擴充套件為高可用的叢集。在之前實現的config-server基礎上來實現高可用非常簡單，不需要我們為這些服務端做任何額外的配置，只需要遵守一個配置規則：將所有的Config Server都指向同一個Git倉庫，這樣所有的配置內容就通過統一的共享檔案系統來維護，而客戶端在指定Config Server位置時，只要配置Config Server外的均衡負載即可，就像如下圖所示的結構：

註冊為服務

雖然通過服務端負載均衡已經能夠實現，但是作為架構內的配置管理，本身其實也是可以看作架構中的一個微服務。所以，另外一種方式更為簡單的方法就是把config-server也註冊為服務，這樣所有客戶端就能以服務的方式進行訪問。通過這種方法，只需要啟動多個指向同一Git倉庫位置的config-server就能實現高可用了。

配置過程也非常簡單，具體如下：

config-server配置

在pom.xml的dependencies節點中引入如下依賴，相比之前的config-server就，加入了spring-cloud-starter-eureka，用來註冊服務

12345678910

<dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId

> </dependency></dependencies>

在application.properties中配置引數eureka.client.serviceUrl.defaultZone以指定服務註冊中心的位置，詳細內容如下：

123456789

spring.application.name=config-serverserver.port=7001# 配置服務註冊中心eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/# git倉庫配置spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/SpringCloud-Learning/spring.cloud.config.server.git.searchPaths=Chapter1-1-8/config-repospring.cloud.config.server.git.username=usernamespring.cloud.config.server.git.password=password

在應用主類中，新增@EnableDiscoveryClient註解，用來將config-server註冊到上面配置的服務註冊中心上去。

12345678910

@EnableDiscoveryClient@EnableConfigServer@SpringBootApplicationpublic class Application { public static void main(String[] args) { new SpringApplicationBuilder(Application.class).web(true).run(args); }}

啟動該應用，並訪問http://localhost:1111/，可以在Eureka Server的資訊面板中看到config-server已經被註冊了。

config-client配置

同config-server一樣，在pom.xml的dependencies節點中新增spring-cloud-starter-eureka依賴，用來註冊服務：

1234567891011121314

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency></dependencies>

在bootstrap.properties中，按如下配置：

12345678

spring.application.name=didispaceserver.port=7002eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/spring.cloud.config.discovery.enabled=truespring.cloud.config.discovery.serviceId=config-serverspring.cloud.config.profile=dev

其中，通過eureka.client.serviceUrl.defaultZone引數指定服務註冊中心，用於服務的註冊與發現，再將spring.cloud.config.discovery.enabled引數設定為true，開啟通過服務來訪問Config Server的功能，最後利用spring.cloud.config.discovery.serviceId引數來指定Config Server註冊的服務名。這裡的spring.application.name和spring.cloud.config.profile如之前通過URI的方式訪問時候一樣，用來定位Git中的資源。

在應用主類中，增加@EnableDiscoveryClient註解，用來發現config-server服務，利用其來載入應用配置

123456789

@EnableDiscoveryClient@SpringBootApplicationpublic class Application { public static void main(String[] args) { new SpringApplicationBuilder(Application.class).web(true).run(args); }}

沿用之前我們建立的Controller來載入Git中的配置資訊

12345678910111213

@RefreshScope@RestControllerpublic class TestController { @Value("${from}") private String from; @RequestMapping("/from") public String from() { return this.from; }}

完成了上述配置之後，我們啟動該客戶端應用。若啟動成功，訪問http://localhost:1111/，可以在Eureka Server的資訊面板中看到該應用已經被註冊成功了。

訪問客戶端應用提供的服務：http://localhost:7002/from，此時，我們會返回在Git倉庫中didispace-dev.properties檔案配置的from屬性內容：”git-dev-1.0”。

配置重新整理

有時候，我們需要對配置內容做一些實時更新的場景，那麼Spring Cloud Config是否可以實現呢？答案顯然是可以的。下面，我們看看如何進行改造來實現配置內容的實時更新。

在改造程式之前，我們先將config-server和config-client都啟動起來，並訪問客戶端提供的REST APIhttp://localhost:7002/from來獲取配置資訊，可以獲得返回內容為：git-dev-1.0。接著，我們可以嘗試使用Git工具修改當前配置的內容，比如，將config-repo/didispace-dev.properties中的from的值從from=git-dev-1.0修改為from=git-dev-2.0，再訪問http://localhost:7002/from，可以看到其返回內容還是git-dev-1.0。

下面，我們將在config-client端增加一些內容和操作以實現配置的重新整理：

在config-clinet的pom.xml中新增spring-boot-starter-actuator監控模組，其中包含了/refresh重新整理API。

1234	<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId></dependency>

重新啟動config-clinet，訪問一次http://localhost:7002/from，可以看到當前的配置值
修改Git倉庫config-repo/didispace-dev.properties檔案中from的值
再次訪問一次相關推薦 Spring Cloud構建微服務架構（四）分散式配置中心（續）先來回顧一下，在前文中我們完成了什麼：構建了config-server，連線到Git倉庫在Git上建立了一個config-repo目錄，用來儲存配置資訊構建了config-client，來獲取Git中的配置資訊在本文中，我們繼續來看看Spring Cloud Spring Cloud構建微服務架構（四）斷路器（Hystrix）在微服務架構中，根據業務來拆分成一個個的服務，服務與服務之間可以相互呼叫（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign來呼叫。為了保證其高可用，單個服務通常會叢集部署。由於網路原因或者自身的原因，服務並不能保證100%可用，如 Spring Cloud構建微服務架構—服務消費（Ribbon） ble DG 沒有客戶 BE pla cati str 主類 Spring Cloud RibbonSpring Cloud Ribbon是基於Netflix Ribbon實現的一套客戶端負載均衡的工具。它是一個基於HTTP和TCP的客戶端負載均衡器。它可以通過在客戶端中 Spring Cloud構建微服務架構：服務消費（基礎）消費 ring str frame emp default class a template pom.xml 使用LoadBalancerClient在Spring Cloud Commons中提供了大量的與服務治理相關的抽象接口，包括DiscoveryClient、這裏我 Spring Cloud構建微服務架構：服務容錯保護（Hystrix服務降級） tro sco load 服務架構延遲正常 map ati href 動手試一試在開始使用Spring Cloud Hystrix實現斷路器之前，我們先拿之前實現的一些內容作為基礎，其中包括： eureka-server工程：服務註冊中心，端口：1001 eurek Spring Cloud構建微服務架構：服務消費（Ribbon） Spring Cloud Ribbon Spring Cloud Ribbon是基於Netflix Ribbon實現的一套客戶端負載均衡的工具。它是一個基於HTTP和TCP的客戶端負載均衡器。它可以通過在客戶端中配置ribbonServerList來設定服務端列表去輪詢訪問以達到均衡負載的作用。當Rib Spring Cloud構建微服務架構：服務消費（Feign） Spring Cloud Feign Spring Cloud Feign是一套基於Netflix Feign實現的宣告式服務呼叫客戶端。它使得編寫Web服務客戶端變得更加簡單。我們只需要通過建立介面並用註解來配置它既可完成對Web服務介面的繫結。它具備可插拔的註解支援，包括Feign註解、JAX-RS註解 Spring Cloud構建微服務架構：服務註冊與發現（Eureka、Consul） Spring Cloud簡介 Spring Cloud是一個基於Spring Boot實現的雲應用開發工具，它為基於JVM的雲應用開發中涉及的配置管理、服務發現、斷路器、智慧路由、微代理、控制匯流排、全域性鎖、決策競選、分散式會話和叢集狀態管理等操作提供了一種簡單的開發方式。 Spring Cloud包含 Spring Cloud構建微服務架構：服務註冊與發現（Eureka） 1. Spring Cloud簡介 Spring Cloud是一個基於Spring Boot實現的雲應用開發工具，它為基於JVM的雲應用開發中涉及的配置管理、服務發現、斷路器、智慧路由、微代理、控制匯流排、全域性鎖、決策競選、分散式會話和叢集狀態管理等操作提供了 Spring Cloud構建微服務架構：分散式服務跟蹤（收集原理）【Dalston版】在本節內容之前，我們已經對如何引入Sleuth跟蹤資訊和搭建Zipkin服務端分析跟蹤延遲的過程做了詳細的介紹，相信大家對於Sleuth和Zipkin已經有了一定的感性認識。接下來，我們介紹一下關於Zipkin收集跟蹤資訊的過程細節，以幫助我們更好地理解Sleuth生產跟蹤資訊 Spring Cloud構建微服務架構服務容錯保護（Hystrix斷路器）【Dalston版】重新受限釋放示例計時 sch nac 故障 span 前言在前兩篇《Spring Cloud構建微服務架構：服務容錯保護（Hystrix服務降級）》和《Spring Cloud構建微服務架構：服務容錯保護（Hystrix依賴隔離）》中，我們對Hystrix提供的 Spring Cloud構建微服務架構服務容錯保護（Hystrix服務降級）【Dalston版】前言在微服務架構中，我們將系統拆分成了一個個的服務單元，各單元應用間通過服務註冊與訂閱的方式互相依賴。由於每個單元都在不同的程序中執行，依賴通過遠端呼叫的方式執行，這樣就有可能因為網路原因或是依賴服務自身問題出現呼叫故障或延遲，而這些問題會直接導致呼叫方的對外服務也出現延遲，若此時呼叫方的請求不斷 Spring Cloud構建微服務架構分散式配置中心（高可用與動態重新整理）【Dalston版】高可用問題傳統作法通常在生產環境，Config Server與服務註冊中心一樣，我們也需要將其擴充套件為高可用的叢集。在之前實現的config-server基礎上來實現高可用非常簡單，不需要我們為這些服務端做任何額外的配置，只需要遵守一個配置規則：將所有的Config Server都指向同一 Spring Cloud構建微服務架構服務網關（基礎）【Dalston版】 web tco str tab 程序 art amp res 統一通過之前幾篇Spring Cloud中幾個核心組件的介紹，我們已經可以構建一個簡略的（不夠完善）微服務架構了。比如下圖所示： alt 我們使用Spring Cloud Netflix中的Eureka實現了 Spring Cloud構建微服務架構分散式配置中心（加密解密）在微服務架構中，我們通常都會採用DevOps的組織方式來降低因團隊間溝通造成的巨大成本，以加速微服務應用的交付能力。這就使得原本由運維團隊控制的線上資訊將交由微服務所屬組織的成員自行維護，其中將會包括大量的敏感資訊，比如：資料庫的賬戶與密碼等。很顯然，如果我們直接將敏感資訊以明文的方式儲存於微服務應用的 Spring Cloud構建微服務架構分布式配置中心（加密解密） pac 控制臺數字簽名 rsa 運維 space strong secret 分布在微服務架構中，我們通常都會采用DevOps的組織方式來降低因團隊間溝通造成的巨大成本，以加速微服務應用的交付能力。這就使得原本由運維團隊控制的線上信息將交由微服務所屬組織的成員自行維護 Spring Cloud構建微服務架構（二）分散式配置中心 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <versio Spring Cloud構建微服務架構（六）高可用服務註冊中心近期因工作原因減緩了更新頻率，同時為了把Spring Cloud中文社群搭建起來也費了不少時間，幾乎每天都在擠牙膏般的湊時間出來做一些有意義的事。未能按原計劃更新博文，在此對持續關注我部落格的朋友們深表歉意。之前在寫spring Cloud系列文章的時候，列過一個較粗的計劃，現在由於收到不少反饋和問 Spring Cloud構建微服務架構：分散式服務跟蹤（跟蹤原理）通過上一篇《分散式服務跟蹤（入門）》的例子，我們已經通過Spring Cloud Sleuth往微服務應用中添加了實現分散式跟蹤具備的基本要素。下面通過本文來詳細說說實現分散式服務跟蹤的一些要點。分散式系統中的服務跟蹤在理論上並不複雜，它主要包括下面兩個關鍵點：為了實現請求跟 Spring Cloud構建微服務架構（七）訊息匯流排先回顧一下，在之前的Spring Cloud Config的介紹中，我們還留了一個懸念：如何實現對配置資訊的實時更新。雖然，我們已經能夠通過/refresh介面和Git倉庫的Web Hook來實現Git倉庫中的內容修改觸發應用程式的屬性更新。但是，若所有觸發操作均需要我