一、背景介紹

Eureka是Netflix開源的一款提供服務註冊和發現的產品。

其官方文件中對自己的定義是：

Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers. We call this service, the Eureka Server. Eureka also comes with a Java-based client component,the Eureka Client, which makes interactions with the service much easier. The client also has a built-in load balancer that does basic round-robin load balancing.

我們在研發Apollo配置中心時(https://github.com/ctripcorp/apollo)，考慮到配置中心是基礎服務，有非常高的可用性要求，為了更好地支援服務動態擴容、縮容、失效剔除等特性，所以就選擇了使用Eureka來提供服務註冊和發現功能。

本著“當你選擇一款開源產品後，你就應當對它負責，既要信任它又要挑戰它”的原則，我花了一些時間比較深入地研究了Eureka的實現細節（好在Eureka的實現短小精悍，通讀原始碼也沒花太多時間），今天就來詳細介紹一下。

二、Why Eureka?

那麼為什麼我們在專案中使用了Eureka呢？我大致總結了一下，有以下幾方面的原因：

1. 它提供了完整的Service Registry和Service Discovery實現

首先是提供了完整的實現，並且也經受住了Netflix自己的生產環境考驗，相對使用起來會比較省心。

2. 和Spring Cloud無縫整合

我們的專案本身就使用了Spring Cloud和Spring Boot，同時Spring Cloud還有一套非常完善的開原始碼來整合Eureka，所以使用起來非常方便。

另外，Eureka還支援在我們應用自身的容器中啟動，也就是說我們的應用啟動完之後，既充當了Eureka的角色，同時也是服務的提供者。這樣就極大地提高了服務的可用性。

這一點是我們選擇Eureka而不是zk、etcd等的主要原因，為了提高配置中心的可用性和降低部署複雜度，我們需要儘可能地減少外部依賴。

3. Open Source

最後一點是開源，由於程式碼是開源的，所以非常便於我們瞭解它的實現原理和排查問題。

三、Dive into Eureka

相信大家看到這裡，已經對Eureka有了一個初步的認識，接下來我們就來深入瞭解下它吧：

3.1 Overview

3.1.1 Basic Architecture

上圖簡要描述了Eureka的基本架構，由3個角色組成：

• Eureka Server：提供服務註冊和發現
• Service Provider：服務提供方，將自身服務註冊到Eureka，從而使服務消費方能夠找到
• Service Consumer：服務消費方，從Eureka獲取註冊服務列表，從而能夠消費服務。

需要注意的是，上圖中的3個角色都是邏輯角色。在實際執行中，這幾個角色甚至可以是同一個例項，比如在我們專案中，Eureka Server和Service Provider就是同一個JVM程序。

3.1.2 More in depth

上圖更進一步的展示了3個角色之間的互動。

1. Service Provider會向Eureka Server做Register（服務註冊）、Renew（服務續約）、Cancel（服務下線）等操作；
2. Eureka Server之間會做註冊服務的同步，從而保證狀態一致；
3. Service Consumer會向Eureka Server獲取註冊服務列表，並消費服務。

3.2 Demo

為了給大家一個更直觀的印象，我們可以通過一個簡單的demo來實際執行一下，從而對Eureka有更好的瞭解。

3.2.1 Git Repository

這個專案使用了Spring Cloud相關類庫，包括：

3.2.2 準備工作

Demo專案使用了Spring Cloud Config做配置，所以第一步先在本地啟動Config Server。

由於專案基於Spring Boot開發，所以直接執行com.nobodyiam.spring.cloud.in.action.config.ConfigServerApplication即可。

3.2.3 Eureka Server Demo

Eureka Server的Demo模組名是：eureka-server。

3.2.3.1 Maven依賴

eureka-server是一個基於Spring Boot的Web應用，我們首先需要做的就是在pom中引入Spring Cloud Eureka Server的依賴。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
    <version>1.2.0.RELEASE</version>
</dependency>

3.2.3.2 啟用Eureka Server

啟用Eureka Server非常簡單，只需要加上@EnableEurekaServer即可。

@EnableEurekaServer
@SpringBootApplication
public class EurekaServiceApplication {
  public static void main(String[] args) {
    SpringApplication.run(EurekaServiceApplication.class, args);
  }
}

做完以上配置後，啟動應用，Eureka Server就開始工作了！

3.2.4 Service Provider and Service Consumer Demo

Service Provider的Demo模組名是：reservation-service。
Service Consumer的Demo模組名是：reservation-client。

3.2.4.1 Maven依賴

reservation-service和reservation-client都是基於Spring Boot的Web應用，我們首先需要做的就是在pom中引入Spring Cloud Eureka的依賴。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <version>1.2.0.RELEASE</version>
</dependency>

3.2.4.2 啟動Service Provider

啟用Service Provider非常簡單，只需要加上@EnableDiscoveryClient即可。

@EnableDiscoveryClient
@SpringBootApplication
public class ReservationServiceApplication {
  public static void main(String[] args) {
    new SpringApplicationBuilder(ReservationServiceApplication.class)
            .run(args);
  }
}

做完以上配置後，啟動應用，Server Provider就開始工作了！
啟動完，開啟http://localhost:8761，就能看到服務已經註冊到Eureka Server了。

3.2.4.3 啟動Service Consumer

啟動Service Consumer其實和Service Provider一樣，因為本質上Eureka提供的客戶端是不區分Provider和Consumer的，一般情況下，Provider同時也會是Consumer。

@EnableDiscoveryClient
@SpringBootApplication
public class ReservationClientApplication {
  @Bean
  CommandLineRunner runner(DiscoveryClient dc) {
    return args -> {
      dc.getInstances("reservation-service")
              .forEach(si -> System.out.println(String.format(
                      "Found %s %s:%s", si.getServiceId(), si.getHost(), si.getPort())));
    };
  }
  public static void main(String[] args) {
    SpringApplication.run(ReservationClientApplication.class, args);
  }
}

上述程式碼中通過dc.getInstances("reservation-service")就能獲取到當前所有註冊的reservation-service服務。

3.3 Eureka Server實現細節

看了前面的demo，我們已經初步領略到了Spring Cloud和Eureka的強大之處，通過短短几行配置就實現了服務註冊和發現！

相信大家一定想了解Eureka是如何實現的吧，所以接下來我們繼續Dive！首先來看下Eureka Server的幾個對外介面實現。

3.3.1 Register

首先來看Register（服務註冊），這個介面會在Service Provider啟動時被呼叫來實現服務註冊。同時，當Service Provider的服務狀態發生變化時（如自身檢測認為Down的時候），也會呼叫來更新服務狀態。

介面實現比較簡單，如下圖所示。

1. ApplicationResource類接收Http服務請求，呼叫PeerAwareInstanceRegistryImpl的register方法
2. PeerAwareInstanceRegistryImpl完成服務註冊後，呼叫replicateToPeers向其它Eureka Server節點（Peer）做狀態同步（非同步操作）

註冊的服務列表儲存在一個巢狀的hash map中：

• 第一層hash map的key是app name，也就是應用名字
• 第二層hash map的key是instance name，也就是例項名字

以3.2.4.2中的截圖為例，RESERVATION-SERVICE就是app name，jason-mbp.lan:reservation-service:8000就是instance name。

Hash map定義如下：

private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry =
new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

3.3.2 Renew

Renew（服務續約）操作由Service Provider定期呼叫，類似於heartbeat。主要是用來告訴Eureka Server Service Provider還活著，避免服務被剔除掉。介面實現如下圖所示。

可以看到，介面實現方式和register基本一致：首先更新自身狀態，再同步到其它Peer。

3.3.3 Cancel

Cancel（服務下線）一般在Service Provider shut down的時候呼叫，用來把自身的服務從Eureka Server中刪除，以防客戶端呼叫不存在的服務。介面實現如下圖所示。

3.3.4 Fetch Registries

Fetch Registries由Service Consumer呼叫，用來獲取Eureka Server上註冊的服務。

為了提高效能，服務列表在Eureka Server會快取一份，同時每30秒更新一次。

3.3.5 Eviction

Eviction（失效服務剔除）用來定期（預設為每60秒）在Eureka Server檢測失效的服務，檢測標準就是超過一定時間沒有Renew的服務。

預設失效時間為90秒，也就是如果有服務超過90秒沒有向Eureka Server發起Renew請求的話，就會被當做失效服務剔除掉。

失效時間可以通過eureka.instance.leaseExpirationDurationInSeconds進行配置，定期掃描時間可以通過eureka.server.evictionIntervalTimerInMs進行配置。

介面實現邏輯見下圖：

3.3.6 How Peer Replicates

在前面的Register、Renew、Cancel介面實現中，我們看到了都會有replicateToPeers操作，這個就是用來做Peer之間的狀態同步。

通過這種方式，Service Provider只需要通知到任意一個Eureka Server後就能保證狀態會在所有的Eureka Server中得到更新。

具體實現方式其實很簡單，就是接收到Service Provider請求的Eureka Server，把請求再次轉發到其它的Eureka Server，呼叫同樣的介面，傳入同樣的引數，除了會在header中標記isReplication=true，從而避免重複的replicate。

Peer之間的狀態是採用非同步方式同步的，所以不保證節點間的狀態一定是一致的，不過基本能保證最終狀態是一致的。

結合服務發現的場景，實際上也並不需要節點間的狀態強一致。在一段時間內（比如30秒），節點A比節點B多一個服務例項或少一個服務例項，在業務上也是完全可以接受的（Service Consumer側一般也會實現錯誤重試和負載均衡機制）。

所以按照CAP理論，Eureka的選擇就是放棄C，選擇AP。

3.3.7 How Peer Nodes are Discovered

那大家可能會有疑問，Eureka Server是怎麼知道有多少Peer的呢？

Eureka Server在啟動後會呼叫EurekaClientConfig.getEurekaServerServiceUrls來獲取所有的Peer節點，並且會定期更新。定期更新頻率可以通過eureka.server.peerEurekaNodesUpdateIntervalMs配置。

這個方法的預設實現是從配置檔案讀取，所以如果Eureka Server節點相對固定的話，可以通過在配置檔案中配置來實現。

如果希望能更靈活的控制Eureka Server節點，比如動態擴容/縮容，那麼可以override getEurekaServerServiceUrls方法，提供自己的實現，比如我們的專案中會通過資料庫讀取Eureka Server列表。

具體實現如下圖所示：

3.3.8 How New Peer Initializes

最後再來看一下一個新的Eureka Server節點加進來，或者Eureka Server重啟後，如何來做初始化，從而能夠正常提供服務。

具體實現如下圖所示，簡而言之就是啟動時把自己當做是Service Consumer從其它Peer Eureka獲取所有服務的註冊資訊。然後對每個服務，在自己這裡執行Register，isReplication=true，從而完成初始化。

3.4 Service Provider實現細節

現在來看下Service Provider的實現細節，主要就是Register、Renew、Cancel這3個操作。

3.4.1 Register

Service Provider要對外提供服務，一個很重要的步驟就是把自己註冊到Eureka Server上。

這部分的實現比較簡單，只需要在啟動時和例項狀態變化時呼叫Eureka Server的介面註冊即可。需要注意的是，需要確保配置eureka.client.registerWithEureka=true。

3.4.2 Renew

Renew操作會在Service Provider端定期發起，用來通知Eureka Server自己還活著。這裡有兩個比較重要的配置需要注意一下：

1. eureka.instance.leaseRenewalIntervalInSeconds
   Renew頻率。預設是30秒，也就是每30秒會向Eureka Server發起Renew操作；
2. eureka.instance.leaseExpirationDurationInSeconds
   服務失效時間。預設是90秒，也就是如果Eureka Server在90秒內沒有接收到來自Service Provider的Renew操作，就會把Service Provider剔除。

具體實現如下：

3.4.3 Cancel

在Service Provider服務shut down的時候，需要及時通知Eureka Server把自己剔除，從而避免客戶端呼叫已經下線的服務。

邏輯本身比較簡單，通過對方法標記@PreDestroy，從而在服務shut down的時候會被觸發。

3.4.4 How Eureka Servers are Discovered

這裡大家疑問又來了，Service Provider是怎麼知道Eureka Server的地址呢？

其實這部分的主體邏輯和3.3.7 How Peer Nodes are Discovered幾乎是一樣的。

也是預設從配置檔案讀取，如果需要更靈活的控制，可以通過override getEurekaServerServiceUrls方法來提供自己的實現。定期更新頻率可以通過eureka.client.eurekaServiceUrlPollIntervalSeconds配置。

3.5 Service Consumer實現細節

Service Consumer這塊的實現相對就簡單一些，因為它只涉及到從Eureka Server獲取服務列表和更新服務列表。

3.5.1 Fetch Service Registries

Service Consumer在啟動時會從Eureka Server獲取所有服務列表，並在本地快取。需要注意的是，需要確保配置eureka.client.shouldFetchRegistry=true。

3.5.2 Update Service Registries

由於在本地有一份快取，所以需要定期更新，定期更新頻率可以通過eureka.client.registryFetchIntervalSeconds配置。

3.5.3 How Eureka Servers are Discovered

Service Consumer和Service Provider一樣，也有一個如何知道Eureka Server地址的問題。

其實由於Service Consumer和Service Provider本質上是同一個Eureka客戶端，所以這部分邏輯是一樣的，這裡就不再贅述了。詳細資訊見3.4.4節。

四、Summary

本文主要介紹了Eureka的實現思路，通過深入瞭解Eureka Server、Service Provider、Service Consumer的實現，我們清晰地看到了服務註冊、發現的一系列過程和實現方式。

相信對正在使用Eureka的同學會有一些幫助，同時希望對暫不使用Eureka的同學也能有一定的啟發，畢竟服務註冊、發現還是比較基礎和通用的，瞭解了實現方式後，在使用上應該能更得心應手一些吧~

宣告：本文為CSDN原創投稿文章，未經許可，禁止任何形式的轉載。
作者：宋順，攜程框架研發部技術專家。2016年初加入攜程，主要負責中介軟體產品的相關研發工作。畢業於復旦大學軟體工程系，曾就職於大眾點評，擔任後臺系統技術負責人。
責編：錢曙光，關注架構和演算法領域，尋求報道或者投稿請發郵件[email protected]，另有「CSDN 高階架構師群」，內有諸多知名網際網路公司的大牛架構師，歡迎架構師加微信qianshuguangarch申請入群，備註姓名+公司+職位。