微服務治理
Spring Cloud 工具套件為微服務治理提供了全面的技術支援。這些治理工具主要包括服務的注冊與發現、負載均衡管理、動态路由、服務降級和故障轉移、鍊路跟蹤、服務監控等。微服務治理的主要功能元件如下：
- 注冊管理服務元件Eureka,提供服務注冊和發現的功能。
- 負載均衡服務元件Ribbon,提供負載均衡排程管理的功能。
- 邊緣代理服務元件Zuul，提供網關服務和動态路由的功能。
- 斷路器元件Hystrix,提供容錯機制、服務降級、故障轉移等功能。
- 聚合服務事件流元件Turbine，可用來監控叢集中服務的運作情況。
- 日志收集元件Sleuth,通過日志收集提供對服務間調用進行跟蹤管理的功能。
- 配置管理服務元件Config,提供統一的配置管理服務功能。
有關這些元件的工作原理，我們可以通過一一個服務調用序列圖進行說明，如圖5-1 所示。
在這個序列圖中，Eureka 管理每個注冊的微服務執行個體，并為其建立中繼資料清單。當一個服務消費者需要調用微服務時，Ribbon将依據微服務的執行個體清單實行負載均衡排程。這種排程預設使用輪詢算法，從執行個體清單中取出一一個可用的執行個體，然後Zuul依據執行個體的中繼資料,對服務進行路由。在路由的過程中,Hystrix會檢查這個微服務執行個體的斷路器狀态。如果斷路器處于閉合狀态，則提供正常的服務;如果斷路器處打開狀态，則說明服務已經出現故障，Hystrix 将根據執行個體的配置情況進行故障轉移、服務降級等。
此外，其他一些元件也對微服務的治理起到一定的輔助作用。例如，Turbine可以對微服務的斷路器實作全面監控，Config可以建構-一個線上更新的配置管理中心，Sleuth和Zipkin結合使用可以組建一個跟蹤伺服器，等等。通過這些元件和服務的使用，可進一步加大微服務治理的力度。
鑒于在新版本的Spring Cloud中，Eureka 已經不再更新，是以這裡使用一個功能更加強大的，由第三方提供的Consul來建立注冊中心。當然，這個注冊中心在Spring Cloud工具集中，同樣提供了對相關元件的支援。
使用 Consul 建立注冊中心
Consul 是一個功能非常強大，性能相當穩定的注冊中心，而且還包 了統 配置管理功能。另外，它在 Docker 中運作和搭建叢集時，更加容易整合。
Consul 的安裝并不複雜， 讀者可從 Consul 官網中根據自己使用的作業系統，選擇相關的版本進行下載下傳。下載下傳解壓縮後 ，可以使用如下指令用開發模式啟動
consul agent -dev
啟動後即可通過浏覽器打開其控制台，連結位址如下：
http:l/localhost:8500
如能看到如圖 5-2 示的圖 ，則說明注冊中心已經啟動就緒 Consul 預設的服務端口為8500 ，控制台管理和服務接入都使用這一端口。
為了能夠将配置資訊儲存在磁盤檔案中，這裡使用了類似于生産環境中的啟動參數，如下所示：
consul agent - server - bind=127 . 0 . 0.l - client=0.0.0 . 0 -bootstrap-expect=3-data-dir=/Users/apple/consul_data/application/data/- node=server
這些配置參數的意義如下。
- -server 表示以服務端身份啟動。
- -bind 表示綁定到哪個 位址(有些伺服器會綁定多塊網卡，可以通過 bind 參數強制指定綁定的 位址)
- -client ：指定用戶端通路的 位址( Consul 有豐富的 AP 接口，這裡的用戶端指的是浏覽器或調用方) ' 0.0 0.0 表示不限用戶端 位址。
- -bootstrap expect=3 ：表示 Serv 叢集最低節點數為 ，低于這個值将無法正常工作(注：ZooKeeper 類似，通常叢集數為奇數，以友善選舉。 onsul 采用的是 Raft 算法)。如果不使用叢集，則可以設定為1.
- -d ata-d 表示指定資料的存放目錄(該目錄必須存在)。
- -node 表示節點在 We 中顯示的名稱。
其中， data-dir 可以設定配置資訊儲存的位址，可以根據所使用的機器裝置輸入一個已經存在的目錄路徑。
服務注冊與發現
微服務在 Consul 中進行注冊後，就能夠被其他服務發現了。有關服務注冊的過程，主要需要完成以下步驟。
1. 侬賴引用
引用與 Co ul 相關的服務發現和配置管理依賴包，代碼如下所示：
org . springframework . cloudspring-cloud-starter co sul discoveryorg spri gframework cloudspri ng-cloud-starter- consul- config
其中， discovery 元件提供了服務注冊與發現的功能， onfig 元件是 遠端配置管理工具。
2. 連接配接設定
連接配接注冊中 的配置，在配置檔案 boot tr p. yml 中進行設定，這個配置檔案将在系統加載Application.yml 之前被加載，代碼如下所示：
spring :cloud :consul :host : 127.0 . 0 . 1port : 8500discovery :serviceName : ${spring . application . name}healthCheckPath : /actuator/healthhealthCheckinterval : 15stags :urlprefix-/${spr ng application . name}ins tance Id :${spring . application . name} : ${vcap.application.instance id ♀｛ spr ng application . instance id ♀｛ random value}}}
在上面的配置中 host port 根據實際情況進行設定，其他參數無須更改。 serviceName是微服務的 名稱，它所 用的變量需要在配置檔案中 進行設定，代碼如下所示：
s pri ng :application :name : catalogapi
即把微服務的名稱定義為 logapi 。這樣，當其 服務程式需要對這個微服務進行調用時，使用這個名稱進行調用即可。因而在一個注冊中心中，微服務的名稱必須具有唯一性。
3.注冊激活
在微服務應用的主程式中增加一個注解@EnableDiscoveryClien，即可激活服務注冊與發現的功能，代碼如下所示:@[email protected] class SortsRestApiApplication {public static void main(String[) args) {SpringApplication.run(SortsRestApiApplication.class, args);}}
當完成上述步驟之後，啟動微服務，即可在Consul的控制台上看到已經注冊的微服務，如圖5-3所示。
從圖5-3中可以看出，除了consul服務本身，還有一一個catalogapi 服務，這就是成功注冊的微服務。單擊catalogapi右邊的相關條款，還可以看到這個微服務健康狀态相關的詳細資料。
統一配置管理
在Consul上可以使用配置管理的功能，并且它還支援YAML的格式，配置的功能十分強大。另外，還可以将配置資訊儲存在磁盤檔案中。
想要啟用配置管理的功能，就需要在微服務的配置檔案bootstrap.yml中增加如下所示的設定:
spring：cloud:consul :config:enabled: true #預設是trueformat: YAML #表示Consul. 上面檔案的格式data-key: data #表示Consul上面的KEY值(或者說檔案的名字)，預設是datadefaultContext: ${ spring . application. name }
這樣，在微服務啟動時，就最先從Consul中讀取配置。
我們可以為每個微服務配置一些獨立的參數， 例如，資料源配置等。圖5-4是針對微服務catalogapi的資料源配置。
最終， 一個連接配接 Consul 的完整配置如下所示：
spring:appl ication:name: catalogapicloud:consul :host: 127.0.0.1port: 8500discovery:serviceName: ${spr ing. application. name}heal thCheckPath: /actuator/healthhealthCheckInterval: 15stags: urlprefix-/$ {spring . application. name }instanceId:$ { spring.application.name} :${vcap.application. instance id:$ {spring. application. instance_ id:$ {random. value}} }#配置中心config:enabled: true #預設是trueformat: YAML #表示Consul.上面檔案的格式有四種: YAML、PROPERTIES、KEY-VALUE#和FILESdata-key: data #表示Consul上面的KEY值(或者說檔案的名字)預設是datade faultContext: $ { spring . application. name }
合理發揮斷路器的作用
在微服務的互相調用中，為了提高微服務的高可用性，有時我們會啟用斷路器功能。斷路器就像電路的跳閘開關一樣，當負載過載時切斷電路，轉為降級調用或執行故障轉移操作。當負載釋放時，再提供正常通路功能。
經過多次測試，我們對啟用斷路器功能的應用使用了下列配置，在高可用和高性能之間進行了一個折中設定:
#是否開啟斷路器(false)feign.hystrix. enabled: true#是否失敗重試(true)spring.cloud. loadbalancer. retry .enabled: true#斷路器逾時配置(true)hystrix. command. default. execution. timeout. enabled: true#斷路器的逾時時間需要大于ribbon的逾時時間，否則不會觸發重試(>ConnectT imeout+ReadTimeout)hystrix. command . de fault. execution. isolation. thread. timeoutInMilliseconds:19000#并發執行的最大線程數(10)hystrix. threadpool .default.coreSize: 500#負載逾時配置ribbon. ConnectTimeout: 3000r ibbon. ReadTimeout: 15000#對所有操作請求都進行重試r ibbon. OkToRetryOnAllOperations: true#切換執行個體的重試次數r ibbon. MaxAutoRetriesNextServer: 1#對目前執行個體的重試次數ribbon.MaxAutoRetries: 0
這個配置有兩點需要注意:
(1)斷路器的逾時時間必須大于負載配置中的逾時時間之和,例如，在上面的配置中，19000> 3000 + 15000。
(2)并發執行的最大線程數預設為10個，這遠遠不夠，是以這裡設定為500個。讀者可以根據伺服器的CPU頻率和個數酌情設定。
當然，對于一個微服務來說，隻有不啟用斷路器功能，其性能才是最優的。
如何實作有效的監控
通過使用Spring Cloud工具套件提供的功能，結合第三方提供的工具，我們可以對所有微服務的運作情況進行更加有效的監控，進而為微服務提供更加安全可靠的保障。
針對這些工具的使用，我們隻需引用相關的工具元件，增加一-點簡單的設計，并進行相關的配置，就可以使用其強大的功能。
服務健康狀态監控
這裡使用一個優秀的第三方管理工具Spring Boot Admin實作服務的健康狀态監控和告警。
這一部分的内容在項目的base-admin子產品中，首先引用其工具元件的依賴，代碼如下所示:
de . codecentricspring-boot- adrnin - starter-server
該工具還提供了管理控制台通路控制功能及其WebUI設計，是以我們隻需結合使用Spring的安全元件，增加一個安全管理配置，就可以啟用這些功能。這個配置的核心代碼如下所示:
@Overrideprotected void configure (HttpSecurity http) throws Exception {SavedRequestAwareAuthenticationSuccessHandler successHandler = newSavedRequestAwareAuthent icationSuccessHandler() ;successHandler . setTargetUrlParameter ("redi rectTo") ;http. authorizeRequests (). antMatchers ("/assets/**") .permitAll (). antMatchers (" /actuator/**") .permitAll (). antMatchers ("/ login") .permitAll (). anyRequest () . authenticated().and(). formLogin() .loginPage ("/login") . successHandler (successHandler) .and()logout () . logoutUrl (" /logout") .and(). httpBasic() .and().csrf() .disable() ;}
在上面的代碼中,主要是對一-些連結進行授權，同時在登入頁面設定中使用loginPage頁面。loginPage頁面将使用由Spring Boot Admin提供的WebUI設計，運作效果如圖5-5所示。
圖5-5中的使用者名和密碼，使用了簡單實作的政策設計，可以直接在配置檔案中進行設定。
SpringBootAdmin是通過注冊中心對微服務進行監控的，是以它本身也需要接入注冊中心，而所有受監控的服務都無須進行設計。為了能夠提供完整的狀态資料，我們需在配置檔案中增加如下所示的配置:
management :e ndpoints :web :exposure :include :”* ”e ndpoi nt :health:show- details: ALWAYS
登入Sping Boot Admin控制台，就可以看到所有在注冊中心中注冊的微服務的運作情況，以及相關的一些健康資料，如線程數、記憶體使用情況等。Sping Boot Admin本身的運作狀态及相關健康資料如圖5-6所示。
重大故障告警
SpringBootAdmin還可以對其監控的服務提供告警功能，當出現重大故障，如服務當機時，可以及時以郵件方式通知運維人員。
想要實作這個功能，就必須結合使用Spring Boot Mail元件。在配置檔案中使用如下所示的配置，啟動Spring Boot Admin的郵件通知功能:
spring :boot:admin:notify:mail:to : [email protected] : [email protected] . com
上面設定的郵箱位址必須是有效的，同時還要配置SpingBootMail郵件的收發功能。這樣，當微服務重新開機或當機時，運維人員就可以收到來自Spring Boot Admin的告警通知郵件了。
斷路器儀表盤
base- microservice項目工程的base-hystrix 子產品是- - 個斷路器儀表盤設計。
斷路器儀表盤是Spring Cloud工具套件中的一一個元件，為了使用這個功能元件，我們需要引用如下所示的工具包：
org .springframework.cloudspring- cloud- starter- netflix- hystrix-dashboard
單獨的斷路器儀表盤應用程式，不用接入注冊中心，隻需在主程式中增加如下所示代碼即可使用：
@[email protected]@EnableHystrixDashboardpublic class HystrixApplication {@RequestMapping (” / ” )public String home() {return ” forward : /hystrix ” ；}...}
啟動斷路器儀表盤應用程式之後，通過下面連結打開浏覽器，即可看到如圖 5-7 所示的控制台首頁：
http://localhost : 7979
在控制台中，我們輸入一個如下所示的需要監控的服務連結位址和端口号，并加上hytrix.stream字元串，單擊Monitor Stream按鈕，即可對相關微服務實行監控:
http:/ / localhost: 8091/hystrix. stream
如果所監控的服務有請求發生，就可以看到如圖5-8所示的情況。
這隻是針對單獨一個微服務進行的監控，是以在實際中作用不是很大，隻可以為進行性能測試提供一些參考資料。
如果使用Turbine元件，就可以實作對一-組服務進行監控。這種聚合服務的斷路器儀表盤設計，在項目工程的base-turbine子產品中。這裡增加了對Turbine元件的引用，同時将這一-服務接入注冊中心之中，這樣，即可在配置檔案中指定需要監控的服務了，如下所示:
turbine:appConfig: catalogapi, catalogwebaggregator:clusterConfig: defaultclusterNameExpression: new String ("default")
在這個配置中，我們隻對catalogapi和catalogweb兩個微服務實施了監控。這樣，在啟動應用之後，在首頁控制台中輸入這個應用的連結位址和端口号，同時在後面加上turbine.stream字元串，即可開啟聚合服務的斷路器儀表盤了。
http: / /localhost:8989/ turbine .stream
如圖5-9所示，是聚合服務斷路器儀表盤的一一個監控執行個體的情況。
Zipkin 鍊路跟蹤
使用Zipkin可以實作對微服務的鍊路跟蹤功能。Zipkin 是一一個開放源代碼的分布式鍊路跟蹤系統，每個服務都向Zipkin發送實時資料, Zipkin 會根據調用關系通過Zipkin UI生成依賴關系圖。
Zipkin提供的資料存儲方式有In-Memory、MySQL Cassandra 和Elasticsearch等。
Zipkin用Trace結構表示對一次請求的追蹤,同時又把每個Trace拆分為若幹個有依賴關系的Span。在微服務應用中,一次使用者請求可能由背景若幹個微服務負責處理，而每個處理請求的微服務就可以了解為一個Span。
從網上下載下傳一個可運作的zipkin-server的jar包，建立Zipkin服務。
下載下傳成功後，在Java環境中使用下列指令運作(要求JDK的版本為1.7 及以上) :
java -jar zipkin-server-*.jar --logging.level. zipkin2=INFO
Zipkin預設使用的端口号為9411,在程式啟動成功之後，通過浏覽器使用如下連結可以打開其控制台:
http:// localhost:9411/
控制台的初次打開界面如圖5-10所示。
在一個微服務應用中，可以通過以下步驟加傳入連結路跟蹤功能。
(1)引用Spring Cloud工具套件中支援Zipkin 的元件，代碼如下所示:
org. springframework.cloudspring-cloud-starter-zipkin
(2)在配置檔案中增加如下所示的配置項:
#鍊路跟蹤| spring:sleuth:sampler :probability: 1.0zipkin:sender :type: web :base-url: http://localhost:9411/
經上述配置之後，如果服務中有請求發生，那麼就可以在Zipkin的控制台中看到相關服務的調用記錄，如調用過程中涉及的方法、服務之間的依賴關系等，如圖5-11、圖5-12和圖5-13所示。
這裡我們沒有儲存Zipkin的跟蹤資料，并且資料的傳輸也隻是簡單地使用了Web方式，是以隻能在開發時測試使用。在實際應用中，可以将跟蹤資料儲存在Elasticsearch中，同時資料:
傳輸也可以使用異步消息通信實作。當資料儲存在Elasticsearch 中時，預設以天為機關進行分割，這樣将造成Zipkin 的依賴資訊無法正常顯示。這時，需要使用另一個開源工具包zipkin-dependencies進行計算。打開GitHub官網，搜尋zipkin-dependencies，下載下傳後即可使用。
因為這個工具包在執行一次計算之後就會自動關閉，是以讀者需要根據實際情況，設定為固定時間間隔執行一次。
ELK日志分析平台
除可以對微服務的運作和互相調用進行監控和跟蹤外，微服務的輸出日志也是故障分析中最直接的入口和切實依據。但是到每個微服務的控制台上去檢視日志是很不友善的，特别是微服務，不僅使用Docker釋出，并且還分布在很多不同的伺服器上，是以這裡将使用一個日志分析平台，将所有微服務的日志收集起來，進行集中管理，并且提供統一的管理平台進行查詢和分析。
建立日志分析平台
日志分析平台ELK 是由Elasticsearch、 Logstash 和Kibana 三個服務組成的。其中，Elasticsearch負責日志存儲并提供搜尋功能，Logstash 負責日志收集，Kibana 提供Web查詢操作界面。這三個服務都是開源的，可以使用Docker進行安裝。
使用日志分析平台
在微服務工程中增加如下所示的依賴引用，即可在應用中使用日志分析平台提供的日志收集功能:
net. logstash. logback logstash- logback-encoder4. 10 dependency>
在應用中增加一個“logback.xm1”配置檔案，内容如下所示:
<?xm1 version="1.0" encoding="UTF-8"?>| ad{yyyy-MM-dd HH :mm:ss.Sss} [8thread] 8-5level glogger{50}- 8msg&n appender>192. 168.1.28: 5000 appender> root> configuration>
在上面的配置中，“ stash”配置就是連接配接日志分析平台的設定。在這個配置中，假設日志收集伺服器的IP位址為“192.168.1.28” ，讀者可以根據實際情況進行設定。
在應用啟動之後，即可通過下列連結打開Kibana 日志查詢控制台:
http://192.168.1.28:5601
在日志查詢控制台中，可以查詢每個應用的日志輸出，如圖5-14所示。
小結
本章首先講述了注冊中心的建立，以及微服務的注冊與配置。然後，以注冊中心為基礎，通過健康監控、服務告警、斷路器儀表盤和鍊路跟蹤等功能的實施，說明如何對微服務進行有效監控。同時，結合日志分析平台的使用，對所有運作的微服務應用進行全面而有效的治理。
後續的微服務的開發和實施将在這個微服務治理環境的基礎上進行，而涉及有關服務治理的引用和配置将不再做特别說明。
本文給大家講解的内容是SpringCloud微服務架構實戰：微服務治理
- 下篇文章給大家講解的是SpringCloud微服務架構實戰：類目管理微服務開發；
- 覺得文章不錯的朋友可以轉發此文關注小編；
- 感謝大家的支援！