Spring Cloud 學習筆記(六) 之服務治理模塊之「基礎架構」，「服務治理機制」講解

1、前言

上一篇文章主要講了對於spring cloud的高可用註冊中心的調用，本章節主要對前幾章的一些概念的總結以及補充一些新的概念。

2、概念總結

    1.基礎架構

        a.服務註冊中心

            Eureka提供的服務端，提供服務註冊和發現的功能，也就是以前實現的 eureka-server

        b.服務提供者

            提供服務，他將本身的服務註冊到Eureka-server，以供其餘應用調用，也就是以前實現的hello-ervice服務

        c.服務消費者  

             消費者從服務註冊中心獲取服務列表，從而使得消費者能夠知道去何處調用想要的服務，在以前的章節中咱們使用Ribbon來實現服務消費。

    2.服務治理機制

        

        a.服務註冊中心

            失效剔除

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

            自我保護

                當咱們在本地調試Eureka的時候，常常會出現一行警告

                

                這是因爲服務註冊中心檢測到服務提供者掛掉的狀態觸發了註冊中心的保護機制，若是是這種狀態，咱們服務調用者若是調用其中一個失敗的服務是會返回調用失敗的，因此客戶端必需要有容錯機制，好比可使用請求重試，斷路器等機制。咱們在本地開發的時候，能夠經過 eureka.server.enable-self-preservation=false.先關閉保護機制，這樣，咱們客戶端調用的時候，只會調用到正常的服務上來。

        b.服務提供者

            服務註冊

                「服務提供者」在啓動的時候會經過發送REST請求的方式將本身註冊到Eureka Server上，同時帶上了一些自身服務的一些元數據信息。Eureka Server 接收到這個REST請求後，將元數據信息存儲在一個雙層結構MAP中，其中第一層key是服務名，第二層的key是具體服務的示例名。

                注意：在服務註冊時，須要確保 eureka.client.register-with-eureka=true 。若爲false，將不會啓動服務註冊。

            服務同步

                如上面架構圖所示，這裏兩個服務分別註冊到了兩個註冊中心，也就是，他們的信息被兩個註冊中心維護。此時，因爲註冊中心之間互相註冊爲服務，當服務提供者發送註冊請求到一個註冊中心時，他會將請求自動轉發到另外一個註冊中心上，從而實現註冊中心間的服務同步，經過服務同步，兩個服務提供者的服務信息就能夠經過這兩臺註冊中心的任何一臺獲取到。

            服務續約

                在註冊完服務後，服務提供者會和註冊中心之間維護一個心跳機制，告訴註冊中心，我還活着，以防被剔除。這種神操做叫作服務續約。

                服務續約有個重要屬性，能夠進行調整註冊服務的心跳

                eureka.instance.leaseRenewalIntervalInSeconds = xxx

Why Is It so Slow to Register a Service?
Being an instance also involves a periodic heartbeat to the registry (through the client’s serviceUrl) with a default duration of 30 seconds. A service is not available for discovery by clients until the instance, the server, and the client all have the same metadata in their local cache (so it could take 3 heartbeats). You can change the period by setting eureka.instance.leaseRenewalIntervalInSeconds. Setting it to a value of less than 30 speeds up the process of getting clients connected to other services. In production, it is probably better to stick with the default, because of internal computations in the server that make assumptions about the lease renewal period.

做爲一個實例還須要按期檢查註冊表（經過客戶端的serviceUrl），默認持續時間爲30秒。 服務不可用於客戶端發現，直到實例，服務器和客戶端在其本地緩存中都具備相同的元數據（所以可能須要3次檢測信號）。 您能夠經過設置eureka.instance.leaseRenewalIntervalInSeconds來更改期間。 將其設置爲小於30的值可加快客戶端與其餘服務的鏈接。 在生產中，因爲服務器中的內部計算對租約續訂期做出了假設，因此最好堅持使用默認值。

        c.服務消費者

            獲取服務

                當咱們啓動服務消費者的時候，他會發送一個REST請求到服務註冊中心，來獲取上面註冊的服務清單。爲了性能考慮，Eureka Server會維護一份只讀的服務清單來返回到客戶端

            服務調用

                咱們能夠看到架構圖是兩個服務提供者，當服務消費者拿到清單後，能夠本身選擇調用哪一個註冊中心的哪一個服務，在Ribbon會默認採起輪訓的方式調用，從而實現客戶端的負載均衡。

            服務下線

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