SpringCloud之深入Eureka（五）

Git源碼: https://github.com/chenhang666/SpringCloud

1、Eureka自我保護機制

• 默認情況下，如果EurekaServer在一定時間內沒有接收到某個微服務實例的心跳。EurekaServer將會註銷該實例（默認90秒）。但是當網絡分區故障發生時，微服務與EurekaServer之間無法正常通信，以上行爲可能變得非常危險，因爲微服務本身其實是健康的，此時本不應該註銷這個服務。Eureka通過“自我保護模式”來解決這個問題。一旦進入該模式，EurekaServer就會保護服務註冊表中的信息，不在刪除服務註冊表中的數據（也就是不會註銷任何微服務）。當網絡故障恢復後，該EurekaServer節點會自動退出自我保護模式。
• 在自我保護模式中，EurekaServer會保護服務註冊表中的信息，不再註銷任何服務實例。當它收到的心跳數重新恢復到閾值以上時，該EurekaServer節點就會自動退出自我保護模式。它的設計哲學就是寧可保留錯誤的服務註冊信息，也不盲目註銷任何可能健康的服務實例。
• SpringCloud中可以使用eureka.server.enable-self-preservation = false 禁用自我保護模式。

2、Eureka服務發現

• 對於註冊Eureka裏面的微服務，可以通過服務發現來獲得該服務的信息。

	@Autowired
    private DiscoveryClient discoveryClient;

	@RequestMapping(value = "/dept/discovery",method = RequestMethod.GET)
    public Object discovery(){
        //獲取Eureka裏面的所有微服務
        List<String> list = discoveryClient.getServices();
        System.out.println("**************" +list);
		//獲取Eureka註冊中名稱爲MICROSERVICECLOUD-DEPT的信息
        List<ServiceInstance> siList = discoveryClient.getInstances("MICROSERVICECLOUD-DEPT");
        for (ServiceInstance element : siList) {
            System.out.println(element.getServiceId()+ "\t" + element.getHost()+ "\t"+element.getPort()
                    +"\t"+ element.getUri());
        }
        return this.discoveryClient;
    }

在服務的啓動類配置@EnableDiscoveryClient註解

3、Eureka集羣配置

• 新建一個EurekaServer項目內容與其大致一致修改以下位置即可搭建集羣成功
• 爲了方便區分，在host文件中做ip映射，host文件地址一般在C:\Windows\System32\drivers\etc文件夾下

127.0.0.1  eureka7001
127.0.0.1  eureka7002
127.0.0.1  eureka7003

• 修改EurekaServer的application.yml配置，另外兩個類似，注意端口
  

• EurekaServer服務的啓動類註解
  

• 修改微服務的application.yml配置文件

eureka:
  client:    #客戶端註冊進eureka服務列表內
    service-url:
      defaultZone: http://eureka7001:7001/eureka/,http://eureka7002:7002/eureka/,
      http://eureka7003:7003/eureka/

啓動EurekaServer服務與要註冊的微服務

4、Eureka與Zookeeper比較

著名的CAP理論支出，一個分佈式系統不可能同時滿足C（一致性）、A（可用性）和P（分區容錯性）。由於分區容錯性在分佈式系統中必須要保證的，因此我們只能在A和C之間權衡。

Zookeeper保證CP

當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是ZK會出現這樣的情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新進行leader選舉。問題在於，選舉learder的時間太長，30~120s，且選舉期間整個zk集羣都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因爲網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。

Eureka保證AP

Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊時如果發現連接失敗，則會自動切換至其他節點，只要有一臺Eureka還在，就能保證註冊服務可用，只不過查到的信息可能不是最新的。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現網絡故障，此時會出現以下幾種情況：

1、Eureka不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務；
2、Eureka仍然能夠接收新服務的註冊和查詢請求，但是不會被同步到其他節點上（即保證當前節點依然可用）
3、當網絡穩定時，當前實例新的註冊信息會被同步到其他節點中

因此，Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像Zookeeper那樣使整個註冊服務癱瘓。