2.2 進階場景

嘗試過Eureka的基本使用場景后，雖然功能能夠實現，但是落實到具體的企業級應用場景時，必然會有許多需要自定義的配置以及一些生產環境可能需要用到的參數。下面列出一些場景供讀者參考。

（1）Eureka的健康檢查

默認情況下，Eureka通過客戶端心跳包來檢測客戶端狀態，并不是通過spring-boot-actuator模塊的/health端點來實現的。默認的心跳實現方式可以有效地檢查Eureka客戶端進程是否正常運作，但是無法保證客戶端應用能夠正常提供服務。由于大多數微服務應用都會有一些外部資源依賴，比如數據庫、Redis緩存等，如果應用與這些外部資源無法連通時，實際上已經不能提供正常的對外服務了，但因為客戶端心跳依然在運行，所以它還是會被服務消費者調用，而這樣的調用實際上并不能獲得預期的效果。當然，我們可以開啟Eureka的健康檢查，這樣應用狀態就可以同步給Eureka了。在application.yml中添加如下配置即可：

    eureka:
        client:
            healthcheck:
                enabled:true

Eureka中的實例一共有如下幾種狀態：UP、DOWN、STARTING、OUT_OF_SERVICE、UNKNOWN。如果需要更多的健康檢查控制，可以實現com.netflix.appinfo.Health-CheckHandler接口，根據自己的場景進行操作。

（2）自我保護模式

Eureka在設計時，認為分布式環境的網絡是不可靠的，可能會因網絡問題導致Eureka Server沒有收到實例的心跳，但是這并不能說明實例宕了，所以Eureka Server默認會打開保護模式，它主要是網絡分區場景下的一種保護。

一旦進入保護模式，Eureka Server將會嘗試保護其服務注冊表中的信息，不再刪除里面的數據（即不會注銷任何微服務）。在這種機制下，它仍然鼓勵客戶端再去嘗試調用這個所謂down狀態的實例，當網絡故障恢復后，該Eureka Server節點會自動退出自我保護模式。若確實調用失敗，熔斷器就派上用場了。

關于熔斷器，第6章會詳細介紹并演示。

通過修改注冊中心的配置文件application.yml，即可打開或關閉注冊中心的自我保護模式：

    eureka:
        server:
            enable-self-presaervation: false           #關閉自我保護模式（默認為打開）

綜上，自我保護模式是一種應對網絡異常的安全保護措施。它的理念是寧可同時保留所有實例（健康實例和不健康實例都會保留），也不盲目注銷任何健康的實例。使用自我保護模式，可以讓Eureka集群更加健壯、穩定。

（3）踢出宕機節點

自我保護模式打開時，已關停節點是一直顯示在Eureka首頁的。

關閉自我保護模式后，由于其默認的心跳周期比較長等原因，要過一會兒才會發現已關停節點被自動踢出了。若想盡快踢出，就只能修改默認的心跳周期參數了。

注冊中心的配置文件application.yml需要修改的地方如下所示：

    eureka:
        server:
            enable-self-preservation: false       # 關閉自我保護模式（默認為打開）
            eviction-interval-timer-in-ms: 1000   # 續期時間，即掃描失效服務的間隔時間
                                                      （默認為60＊1000ms）

客戶端的配置文件application.yml需要修改的地方為：

    eureka:
        instance:
            lease-renewal-interval-in-seconds: 5   # 心跳時間，即服務續約間隔時間（默認為30s）
            lease-expiration-duration-in-seconds: 15  # 發呆時間，即服務續約到期時間（默認為90s）
        client:
            healthcheck:
                enabled: true          #開啟健康檢查（依賴spring-boot-starter-actuator）

（4）注冊服務慢的問題

客戶端去注冊中心默認持續30s，直到實例自身、服務端、客戶端各自元數據本地緩存同步完成后服務才可用（至少需要3次心跳周期）。可以通過eureka.instance. leaseRenewalIntervalInSeconds修改這個周期，改善客戶端鏈接到服務的速度。不過，考慮短期的網絡波動以及服務續期等情況，在生產環境最好用默認設定。

（5）服務狀態顯示UNKNOWN

如果在Eureka監控頁面發現服務狀態顯示UNKNOWN，則很大可能是把微服務的eureka.client.healthcheck.enabled屬性配置在bootstrap.yml里面的問題。比如，實際測試發現，Eureka首頁顯示的服務狀態，本應是UP(1)，卻變成大紅色的粗體UNKNOWN(1)。

（6）自定義InstanceId

兩個相同的服務（端口不同），如果注冊時設置的都是${spring.application.name}，那么Eureka首頁只會看到一個服務名字，而無法區分有幾個實例注冊上來了。于是，可以自定義生成InstanceId的規則。

Eureka服務名默認如下：

    ${sp ring.cloud.client.hostname}:${spring.application.name}:${spring.application.
        instance_id:${server.port}}

可以在配置文件中通過eureka.intance.intance_id來自定義：

    eureka:
        instance:
            #修改顯示的微服務名為：IP：端口
            instance-id: ${spring.cloud.client.ipAddress}:${server.port}

（7）自定義Eureka控制臺服務的鏈接

既然微服務顯示的名稱允許修改，那么其對應的點擊鏈接也是可以修改的。

同樣，還是修改微服務的配置文件，如下所示：

    eureka:
        instance:
            # ip-address: 192.168.6.66  #只有prefer-ip-address=true時才會生效
            prefer-ip-address: true     #設置微服務調用地址為IP優先（默認為false）

Eureka首頁顯示的微服務調用地址，默認是http://hostName:port/info。

而在設置prefer-ip-address=true之后，調用地址會變成http://ip:port/info。

這時若再設置ip-address=192.168.6.66，則調用地址會變成http://192.168.6.66:2100/info。

（8）健康度指示器

一個Eurake實例的狀態頁和健康指示器默認為/info和/health，這兩個是由Spring Boot Actuator應用提供的訪問端點。可以通過以下方式進行修改：

    application.yml
    eureka:
        instance:
            statusPageUrlPath: ${management.context-path}/info
            healthCheckUrlPath: ${management.context-path}/health

這些地址會被用于Eureka對客戶端元數據的獲取，以及健康檢測。

（9）就近原則

用戶量比較大或者用戶地理位置分布范圍很廣的項目，一般都會有多個機房。這個時候如果上線服務的話，我們希望一個機房內的服務優先調用同一個機房內的服務，當同一個機房的服務不可用時，再去調用其他機房的服務，以達到減少延時的作用。Eureka有Region和Zone的概念，可以理解為現實中的大區（Region）和機房（Zone）。Eureka Client在啟動時需要指定Zone，它會優先請求自己Zone的Eureka Server獲取注冊列表。同樣，Eureka Server在啟動時也需要指定Zone。如果沒有指定，其會默認使用defaultZone。

（10）高可用配置

Eureka Server也支持運行多實例，并以互相注冊的方式（即伙伴機制）來實現高可用的部署，即每一臺Eureka都在配置中指定另一個Eureka地址作為伙伴，它在啟動時會向伙伴節點獲取注冊列表。如此一來，Eureka集群新加機器時，就不用擔心注冊列表的完整性。所以，只需要在Eureka Server里面配置其他可用的serviceUrl，就實現了注冊中心的高可用。

我們新建兩個Eureka服務端項。第1個服務端項為EurekaServer1項目中的配置文件/src/main/resources/application.yml。

    server:
        port: 8989
    eureka
        serviceUrl:
            defaultZone:

第2個服務端項為EurekaServer2項目中的配置文件/src/main/resources/application.yml。

    server:
        port: 9898
    eureka
        serviceUrl:
            defaultZone:

啟動Server1、Server2后，分別訪問http://127.0.0.1:8989/eureka/、http://127.0.0.1:9898/eureka/，發現DS Replicas、General Info模塊出現了對方的信息。讀者可以自行測試，分別單獨向Server1或者Server2進行服務注冊時，都會自動同步給另外一個注冊中心。

在生產環境中大于兩臺注冊中心的條件下，可以同理將其配置成如圖2-4所示的雙向環形。