《Spring Cloud》學習（一） 服務治理！

　　前言：以前網上學習過Spring Cloud，對於工做上須要是足夠了，總歸對於一些方面只知其一;不知其二，最近可貴有些閒暇時間，有幸讀了崔永超先生的《Spring Cloud 微服務實戰》，一方面記錄下本身的學習歷程和讀後感，一方面分享下本身對Spring Cloud微服務的一些看法，寫下此文。
　　注意：本文着重於描述Spring Cloud運行的機制和原理部分，不會涉及到過多的代碼，不會演示如何搭建註冊發現，高性能註冊中心，配置負載均衡等等，可是會對其內部運行機制及原理進行必定的詳解。因此本文默認讀者有必定的Spring Cloud基礎。您若是打算系統學習該技術，本人仍是推薦上述說起書籍。

　　固然歡迎大牛指導錯誤及不足！

 

---

 

　　介紹：Spring Cloud是基於Spring Boot實現的微服務架構工具，提供了配置管理，服務治理，斷路器，智能路由，微代理，控制總線，全局鎖，決策競爭，分佈式會話，集權狀態管理等操做。

 

    第一章 服務治理

 

　　服務治理是微服務架構的核心與基礎，主要實現各個服務實例的自動化註冊與發現。Spring Cloud Eureka基於 Netflix Eureka 作了二次封裝，主要負責完成微服務架構中的服務治理功能。主要用來實現服務註冊發現，同時包含服務端，客戶端組件。

 

一.服務註冊 服務續約 服務發現

1.服務註冊 服務續約

　　服務註冊：服務治理中，構建註冊中心來統一管理每一個服務，客戶端向註冊中心發送自身服務的服務名，端口，IP，通訊協議等等元數據信息。註冊中心會將其並儲存至本地服務清單（雙層Map結構存儲）。

　　高可用註冊中心：分佈式環境中，咱們須要充分考慮發生故障的狀況，因此在生產環境中必須對各個組件進行高可用部署，對於服務註冊中心也同樣。須要構建高可用的服務註冊中心以加強系統的可用性。Eureka Server的設計一開始就考慮了高可用問題，在Eureka的服務治理設計中，全部節點便是服務提供方，也是服務消費方，服務註冊中心也不例外。
　　Eureka Server的高可用實際上就是將本身做爲服務向其餘服務註冊中心註冊本身，這樣就能夠造成一組互相註冊的服務註冊中心， 以實現服務清單的互相同步， 達到高可用的效果。以集羣的方式部署註冊中心，容許分片故障期間，其餘分片繼續提供服務發現註冊，故障分片恢復時其餘分片會把狀態同步回來。不一樣的註冊中心分片經過異步方式互相複製狀態，提供高的實例可用性。

　　如圖4個客戶端之間能夠相互調用。

　　

 　　服務續約：客戶端向註冊中心註冊自身的服務信息後，而且週期性的（默認30秒）發送心跳（eurekaTransport.registrationClient.sendHeartBeat方法）來更新服務租約。註冊中心若是一段時間（默認90秒）內沒收到客戶端的心跳續約，則會剔除該客戶端。

 

註冊流程詳解：

　　客戶端操做：服務啓動時發送REST請求到註冊中心的方式進行的，以discoveryClent.register(instanceinfo)方法進行服務註冊，能夠看到以com.netflix.appinfo.Instanceinfo對象爲參數，該對象就是註冊時客戶端給服務端的服務的元數據信息（主機名、IP地址、端口號、狀態頁和健康檢查等等）。

　　註冊中心端操做：註冊中心接收到註冊請求後，先調用publishEvent函數，將該新服務註冊的事件已請求轉發的方式傳播出去，通知其餘節點的註冊中心，達到服務同步，然後調用com.netflix.eureka.registry.AbstractlnstanceRegistry父類中的register註冊實現，將InstanceInfo中的元數據信息存儲在一個ConcurrentHashMap對象中。ConcurrentHashMap<String, Map<String,Lease<InstanceInfo>>>對象，它是一個兩層Map結構，第一層的key存儲服務名：InstanceInfo中的appName屬性，第二層的key存儲實例名：InstanceInfo中的instanceId屬性。

 

2.服務發現

　　服務啓動會調用com.netflix.discovery.DiscoveryClient的initScheduledTasks函數，發如今其中還有兩個定時任務，分別是 服務獲取 和 服務續約。

　　當咱們啓動服務消費者的時候，它會發送一個REST請求給服務註冊中心，來獲取註冊中心存儲的服務清單。爲了性能考慮，Eureka Server會維護一份只讀的服務清單來返回給客戶端，同時每一個客戶端都會週期的（默認30秒）向註冊中心諮詢，獲取到全部的服務實例清單，存入本地(serverList),能夠對其餘具體服務實例進行訪問。(若但願修改緩存清單的 更新時間，能夠經過 eureka.clent.registry-fetch-interval-seconds=30參數進行修改)。

二.服務消費

　　服務消費者在獲取服務清單後，經過服務名能夠得到具體提供服務的實例名和該實例的元數據信息。由於有這些服務實例的詳細信息，因此客戶端能夠根據本身的須要決定具體調用哪一個實例（使用RestTemplate）。

　　RestTemplate：主要有GET,POST,PUT,DELETE的請求方式。

　　GET有getForEntity和getForObject的重載。POST有postForEntity和postForObject的重載。

 　　通常咱們都會使用負載均衡結合Ribbon完成。當Ribbon與Eureka聯合使用時，Ribbon的服務實例清單RibbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka註冊中心中獲取服務端列表。Ribbon是一個基於HTTP和TCP的客戶端負載均衡器，它能夠在經過客戶端中配置的ribbonServerList服務端列表去輪詢訪問(默認)以達到均衡負載的做用。

　　(具體的Ribbon及RestTemplate下章負載均衡會詳解)

 

三.服務下線 失效剔除

 

　　3.1服務下線

　　在系統運行過程當中必然會面臨關閉或重啓服務的某個實例的狀況，在服務關閉期間，咱們天然不但願客戶端會繼續調用關閉了的實例。 因此在客戶端程序中，當服務實例進行正常的關閉操做時，它會觸發一個服務下線的REST請求給註冊中心,告訴服務註冊中心：我要下線了。註冊中心在接收到請求以後，將該服務狀態置爲下線(DOWN), 並把該下線事件傳播出去。

　　

　　3.2失效剔除

　　有些時候，咱們的服務實例並不必定會正常下線，可能因爲內存溢出，網絡故障等緣由使得服務不能正常工做，而服務註冊中心並未收到服務下線的請求。爲了從服務列表中將這些沒法提供服務的實例剔除，註冊中心在啓動的時候會建立一個定時任務，默認每隔一段時間（默認爲60秒）將當前清單中超時（默認爲90秒）沒有續約的服務剔除出去。

 

　　3.3自我保護

　　自我保護機制：服務註冊到Eureka Server以後，會維護一個心跳鏈接，告訴Eureka Server本身還活着。EurekaServer在運行期間，會統計心跳失敗的比例在15分鐘以內是否低於85%, 若是出現低於的狀況，EurekaServer會將當前的實例註冊信息保護起來，讓這些實例不會過時，儘量保護這些註冊信息。可是在這段保護期間內實例若出現問題，那麼客戶端很容易拿到實際已經不存在的服務實例，會出現調用失敗的清況，因此客戶端必需要有容錯機制，好比可使用請求重試、斷路器等機制。

　　若是Eureka以集羣模式部署，當集羣中有分片出現故障時，那麼Eureka就轉入自我保護模式。它容許在分片故障期間繼續提供服務的發現和註冊，當故障分片恢復運行時，集羣中的其餘分片會把它們的狀態再次同步回來。

　　固然也可使用eureka.server.enableself-preservation=false參數來關閉保護機制，以確保註冊中心能夠將不可用的實例正確剔除。

四.健康檢測

　　Actuator監控管理：爲了系統獲取各個微服務相關指標好比環境變量，垃圾收集信息，內存信息，線程池信息，HTTP請求統計。Spring Cloud提供了Actuator模塊來自動構建一系列用於監控的端點，而且支持擴展。模塊中自帶一些經常使用資源的健康指標檢接口，好比磁盤空間，DataSource連接，Mongo數據庫可用，Rabbit服務，Redis，Solr檢測等，也能夠本身實現自定義檢測器。
　　默認狀況下，Eureka中各個服務實例的健康檢測並非經過spring-boot-actuator模塊的/health 端點來實現的， 而是依靠客戶端心跳的方式來保持服務實例的存活。在Eureka 的服務續約與剔除機制下，客戶端的健康狀態從註冊到註冊中心開始都會處於 UP狀態， 除非心跳終止一段時間以後，服務註冊中心將其剔除。 默認的心跳實現方式能夠有效檢查客戶端進程是否正常運做， 但卻沒法保證客戶端應用可以正常提供服務。因爲大多數微服務應用都會有一些其餘的外部資源依賴，好比數據庫、 緩存、 消息代理等，若是咱們的應用與這些外部資源沒法聯通的時候， 實際上已經不能提供正常的對外服務了，可是由於客戶端心跳依然在運行， 因此它仍是會被服務消費者調用，而這樣的調用實際上並不能得到預期的結果。
　　在Spring Cloud Eureka中，咱們能夠經過簡單的配置，把Eureka客戶端的健康檢測交給spring-boot-actuator模塊的/health端點， 以實現更加全面的健康狀態維護。

 

---

 

本文連接：《Spring Cloud》學習（一） 服務治理！
轉載聲明：本博客由靜影殘月創做。可自由轉載、引用，但需署名做者且註明文章出處。