當調用API或者發(fā)起網絡通信的時候，無論如何我們都要知道被調用方的IP和服務端口，大部分情況是通過域名和服務端口，事實上基于DNS的服務發(fā)現，因為DNS緩存、無法自治和其他不利因素的存在，有很多局限。傳統(tǒng)的DNS方式，都是通過nginx或者其他代理軟件來實現，物理機器的ip和port都是固定的，那么nginx中配置的服務ip和port也是固定的，服務列表的更新只能通過手動來做，但如果后端服務很多時，手動更新容易出錯，效率也很低，這在后端服務發(fā)生故障時，不可用時間就可能會加長。在微服務中，尤其是使用了Docker等虛擬化技術的微服務，其IP和port都是動態(tài)分配的，服務實例數也是動態(tài)變化的，那么就需要精細而準確的服務發(fā)現機制。當微服務app啟動后，告訴其他服務自己的ip和端口，這里的其他服務就是Eureka Server和Eureka Client，這樣其他服務就知道這個服務有多少實例在線，都在哪些地方，方便去負載均衡和調用。
Eureka屬于客戶端發(fā)現模式，客戶端負責決定相應服務實例的網絡位置，并且對請求實現負載均衡?？蛻舳藦囊粋€服務注冊服務中查詢所有可用服務實例的庫，并緩存到本地。服務調用時，客戶端使用負載均衡算法從多個后端服務實例中選擇出一個，然后發(fā)出請求。Eureka分為Eureka Server和Eureka client， Eureka Server是一個服務注冊中心，為服務實例注冊管理和查詢可用實例提供了REST API，并可以用其定位、負載均衡、故障恢復后端服務的中間層服務。在服務啟動后，Eureka Client向服務注冊中心注冊服務同時會拉去注冊中心注冊表副本；在服務停止的時候，Eureka Client向服務注冊中心注銷服務；服務注冊后，Eureka Client會定時的發(fā)送心跳來刷新服務的最新狀態(tài)。
客戶端發(fā)現模式的優(yōu)點是服務調用、負載均衡不需要和Eureka Server通信，直接使用本地注冊表副本，因此Eureka Server不可用時是不會影響正常的服務調用，性能也不會因為網絡延遲和服務端延遲受到影響。但其缺點也很明顯，但某個服務不可用時，各個Eureka Client不能及時的知道，需要1~3個心跳周期才能感知，但是，由于基于Netflix的服務調用端都會使用Hystrix來容錯和降級，當服務調用不可用時Hystrix也能及時感知到，通過熔斷機制來降級服務調用，因此彌補了基于客戶端服務發(fā)現的時效性的缺點。
Eureka Server采用的是對等通信(P2P),無中心化的架構，無master/slave區(qū)分，每一個server都是對等的，既是Server又是Client,所以其集群方式可以自由發(fā)揮，可以各點互連，也可以接力互連。Eureka Server通過運行多個實例以及彼此之間互相注冊來提高可用性，每個節(jié)點需要添加一個或多個有效的serviceUrl指向另一個節(jié)點。利用Eureka Server這種架構特性， 我在Eureka Server Cluster的部署時采用了三角形通信模型，三角形是一個很好的均衡模型，既是各點互連，又是接力互連，三角形本身就是一個穩(wěn)定性幾何形狀，有著穩(wěn)固、堅定搜索、耐壓的特點，家具、建筑、交通等各種行業(yè)都有應用。如下圖所示，Eureka Cluster的每個實例都和另外2個實例通信交互。