一、Eureka 簡介
Eureka 是 Netflix 開發的服務發現框架，其本身是個基於 REST 的服務，主要用於定位運行在 AWS 域中的中間層服務，以達到負載均衡和中間層服務故障轉移的目的。Spring Cloud將它集成在其子項目 spring-cloud-netflix 中，以實現 Spring Cloud 的服務發現功能。
Eureka Client 是一個 Java 客戶端，用於簡化與 Eureka Server 的交互，客戶端同時也就是一個內置的、使用輪詢 (round-robin) 負載算法的負載均衡器。
在應用啓動後，將會向 Eureka Server 發送心跳，默認週期爲 30 秒，如果 Eureka Server 在多個心跳週期內沒有接收到某個節點的心跳，Eureka Server 將會從服務中心註冊表中把這個服務節點移除 (默認90秒)。
Eureka Server 之間通過複製的方式完成數據的同步，Eureka 還提供了客戶端緩存機制，即使所有的 Eureka Server 都掛掉，客戶端依然可以利用緩存中的信息消費其他服務的API。
綜上，Eureka 通過心跳檢查、客戶端緩存等機制，確保了系統的高可用性、靈活性和可伸縮性。
二、服務發現原理
三、服務發現組件的功能
(1) 服務註冊表：一個記錄當前可用服務實例的網絡信息的數據庫，是服務發現機制的核心。服務註冊表提供查詢 API 和管理 API，使用查詢 API 獲得可用的服務實例，使用管理 API 實現註冊和註銷；
(2) 服務註冊：在服務啓動時，將服務實例的網絡地址信息添加到服務註冊表中，稱之爲服務註冊；
(3) 健康檢查：服務發現組件會通過一些機制定時檢測已註冊的服務，如果發現某些服務無法訪問了(可能是某幾個心跳週期後)，就會將該服務從服務註冊表中移除/註銷掉；
四、服務發現方式
服務實例的網絡位置都是動態分配的。由於擴展、失敗、升級，服務實例會經常動態改變，因此，客戶端代碼需要使用更加複雜的服務發現機制。服務發現有以下兩種模式：
(1) 客戶端發現：例如，Eureka、zookeeper；
使用客戶端發現模式時，客戶端決定相應服務實例的網絡位置，並且對請求實現負載均衡。客戶端查詢服務註冊表，後者是一個可用服務實例的數據庫；然後使用負載均衡算法從中選擇一個實例，併發出請求。
客戶端從服務註冊表服務中查詢，其中是所有可用服務實例的庫。客戶端使用負載均衡算法從多個服務實例中選擇出一個，然後發出請求；
服務實例的網絡位置在啓動時被記錄到服務註冊表，實例終止時被刪除。服務實例的註冊信息通常使用心跳機制定期刷新。
Netflix OSS 是客戶端發現模式的絕佳範例，Netflix Eureka 是一個服務註冊表，爲服務實例註冊管理和查詢可用實例提供了 REST API 接口。Netflix Ribbon 是IPC 客戶端，與 Eureka 一起實現對請求的負載均衡。
客戶端發現模式優缺點兼有。這一模式相對直接，除了服務註冊外，其他部分無需變動。此外，由於客戶端知曉可用的服務實例，能針對特定應用實現智能負載均衡，比如使用哈希一致性。這種模式的一大缺點就是客戶端與服務註冊綁定，要針對服務端用到的每個編程語言和框架，實現客戶端的服務發現邏輯。
(2) 服務器端發現：Consul + nginx
客戶端通過負載均衡器向某個服務提出請求，負載均衡器查詢服務註冊表，並將請求轉發到可用的服務實例。如同客戶端發現，服務實例在服務註冊表中註冊或註銷。
AWS Elastic Load Balancer(ELB) 是服務端發現路由的例子，ELB 通常均衡來自互聯網的外部流量，也可用來負載均衡 VPC(Virtual private cloud) 的內部流量。客戶端使用 DNS 通過 ELB 發出請求 (HTTP 或 TCP)，ELB 在已註冊的 EC2 實例或 ECS 容器之間負載均衡。這裏並沒有單獨的服務註冊表，相反，EC2 實例和 ECS 容器註冊在 ELB。
HTTP服務器與類似 NGINX PLUS 和 NGINX 這樣的負載均衡器也能用作服務端的發現均衡器。Graham Jenson 的 Scalable Architecture DR CoN: Docker, Registrator, Consul, Consul Template and Nginx 一文就描述如何使用 Consul Template 來動態配置 NGINX 反向代理。Consul Template 定期從 Consul Template 註冊表中的配置數據中生成配置文件；文件發生變更即允許任意命令。
Kubernetes 和 Marathon 這樣的部署環境會在每個集羣上運行一個代理，將代理用作服務端發現的負載均衡器。客戶端使用主機 IP 地址和分配的端口通過代理將請求路由出去，向服務發送請求。代理將請求透明地轉發到集羣中可用的服務實例。
服務端發現模式兼具優缺點。它最大的優點是，客戶端無需關注發現的細節，只需要簡單地向負載均衡器發送請求，這減少了編程語言框架需要完成的發現邏輯。並且如上所述，某些部署環境免費提供這一功能。這種模式也有缺點。除非負載均衡器由部署環境提供，否則會成爲一個需要配置和管理的高可用系統組件。
五、服務註冊與遠程服務調用的流程：
在 RPC 架構項目中，一個服務從註冊到被調用的整個流程步驟如下：
1. 啓動註冊中心 (Ereka、Zookeeper、Redis、...)，等待服務提供者或者消費者連接；
2. 啓動服務提供者；服務提供者啓動時，會把當前服務的基本信息以別名的方式註冊到註冊中心上去；
備註：① 服務的基本信息，是一般是指服務的地址、端口號；
② 別名，是指在註冊中心存儲服務信息時，會爲每個服務生成一個serviceId；在註冊中心存儲的所有服務的 serviceId 是唯一的，而存儲的服務信息不一定唯一；即有可能多個 serviceId 對應相同的服務地址及端口號；
③ 註冊中心存儲服務的方式是以類似於Java中的Map的形式存儲的；即類似於鍵值對的形式，其鍵就是生成的 serviceId，值就是所註冊服務的地址和端口號，例如:127.0.0.1:8080；
3. 啓動服務消費者；服務消費者啓動時，會使用服務別名 (也就是 serviceId) 去註冊中心獲取實際的 RPC 遠程調用地址；
4. 在消費者獲取到實際的 RPC 遠程調用地址後，再使用本地的 HttpClient 技術 (http + json) 實現調用；
備註：① 消費者在獲取到 RPC 遠程調用的服務地址後，會首先將其混村在本地的 jvm 內存中；
② 默認情況下，Eureka 會每隔 30 秒更新一次服務調用地址；