1 啟動配置 & Maven依賴
引入SpringBoot 和 SpringCloud
引入Eureka Server
<dependency>
? ? ? <groupId>org.springframework.cloud</groupId>
? ? ? <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
resource目錄下創(chuàng)建啟動配置文件application.yml
spring:
? application:
? ? name: eureka-server
server:
? port: 9999? ? #指定服務(wù)端口
eureka:
? instance:
? ? hostname: localhost
? client:
? ? registerWithEureka: false? #是否將eureka自身作為應(yīng)用注冊到eureka注冊中心
? ? fetchRegistry: false? ? ? #為true時，可以啟動，但報異常：Cannot execute request on any known server
? ? serviceUrl:
? ? ? defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
? server:
? ? enableSelfPreservation: false
? ? evictionIntervalTimerInMs: 4000
logging:
? config: classpath:logback.xml
創(chuàng)建啟動類 DiscoveryServer
其中@EnableEurekaServer 代表啟用EurekaServer
@EnableEurekaClient非必須配置，當需要將EurekaServer本身作為服務(wù)注冊到注冊中心時需要配置此注解，適用于注冊中心集群模式。
客戶端配置
<dependency>
? ? ? ? ? ? <groupId>org.springframework.cloud</groupId>
? ? ? ? ? ? <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
? </dependency>
2 Eureka的原理和優(yōu)點
eureka 原理
優(yōu)點
1、在Eureka平臺中，如果某臺服務(wù)器宕機，Eureka不會有類似于ZooKeeper的選舉leader的過程；客戶端請求會自動切換到新的Eureka節(jié)點；當宕機的服務(wù)器重新恢復(fù)后，Eureka會再次將其納入到服務(wù)器集群管理之中；而對于它來說，所有要做的無非是同步一些新的服務(wù)注冊信息而已。所以，再也不用擔(dān)心有“掉隊”的服務(wù)器恢復(fù)以后，會從Eureka服務(wù)器集群中剔除出去的風(fēng)險了。Eureka甚至被設(shè)計用來應(yīng)付范圍更廣的網(wǎng)絡(luò)分割故障，并實現(xiàn)“0”宕機維護需求。（多個zookeeper之間網(wǎng)絡(luò)出現(xiàn)問題,造成出現(xiàn)多個leader，發(fā)生腦裂）當網(wǎng)絡(luò)分割故障發(fā)生時，每個Eureka節(jié)點，會持續(xù)的對外提供服務(wù)（注：ZooKeeper不會）：接收新的服務(wù)注冊同時將它們提供給下游的服務(wù)發(fā)現(xiàn)請求。這樣一來，就可以實現(xiàn)在同一個子網(wǎng)中（same side of partition），新發(fā)布的服務(wù)仍然可以被發(fā)現(xiàn)與訪問。
2、正常配置下，Eureka內(nèi)置了心跳服務(wù)，用于淘汰一些“瀕死”的服務(wù)器；如果在Eureka中注冊的服務(wù)，它的“心跳”變得遲緩時，Eureka會將其整個剔除出管理范圍（這點有點像ZooKeeper的做法）。這是個很好的功能，但是當網(wǎng)絡(luò)分割故障發(fā)生時，這也是非常危險的；因為，那些因為網(wǎng)絡(luò)問題（注：心跳慢被剔除了）而被剔除出去的服務(wù)器本身是很”健康“的，只是因為網(wǎng)絡(luò)分割故障把Eureka集群分割成了獨立的子網(wǎng)而不能互訪而已。
幸運的是，Netflix考慮到了這個缺陷。如果Eureka服務(wù)節(jié)點在短時間里丟失了大量的心跳連接（注：可能發(fā)生了網(wǎng)絡(luò)故障），那么這個Eureka節(jié)點會進入”自我保護模式“，同時保留那些“心跳死亡“的服務(wù)注冊信息不過期。此時，這個Eureka節(jié)點對于新的服務(wù)還能提供注冊服務(wù)，對于”死亡“的仍然保留，以防還有客戶端向其發(fā)起請求。當網(wǎng)絡(luò)故障恢復(fù)后，這個Eureka節(jié)點會退出”自我保護模式“。所以Eureka的哲學(xué)是，同時保留”好數(shù)據(jù)“與”壞數(shù)據(jù)“總比丟掉任何”好數(shù)據(jù)“要更好，所以這種模式在實踐中非常有效。
3、Eureka還有客戶端緩存功能（注：Eureka分為客戶端程序與服務(wù)器端程序兩個部分，客戶端程序負責(zé)向外提供注冊與發(fā)現(xiàn)服務(wù)接口）。所以即便Eureka集群中所有節(jié)點都失效，或者發(fā)生網(wǎng)絡(luò)分割故障導(dǎo)致客戶端不能訪問任何一臺Eureka服務(wù)器；Eureka服務(wù)的消費者仍然可以通過Eureka客戶端緩存來獲取現(xiàn)有的服務(wù)注冊信息。甚至最極端的環(huán)境下，所有正常的Eureka節(jié)點都不對請求產(chǎn)生相應(yīng)，也沒有更好的服務(wù)器解決方案來解決這種問題
時；得益于Eureka的客戶端緩存技術(shù)，消費者服務(wù)仍然可以通過Eureka客戶端查詢與獲取注冊服務(wù)信息，這點很重要。
4、Eureka的構(gòu)架保證了它能夠成為Service發(fā)現(xiàn)服務(wù)。它相對與ZooKeeper來說剔除了Leader節(jié)點的選取或者事務(wù)日志機制，這樣做有利于減少使用者維護的難度也保證了Eureka的在運行時的健壯性。而且Eureka就是為發(fā)現(xiàn)服務(wù)所設(shè)計的，它有獨立的客戶端程序庫，同時提供心跳服務(wù)、服務(wù)健康監(jiān)測、自動發(fā)布服務(wù)與自動刷新緩存的功能。但是，如果使用ZooKeeper你必須自己來實現(xiàn)這些功能。Eureka的所有庫都是開源的，所有人都能看到與使用這些源代碼，這比那些只有一兩個人能看或者維護的客戶端庫要好。
5、維護Eureka服務(wù)器也非常的簡單，比如，切換一個節(jié)點只需要在現(xiàn)有EIP下移除一個現(xiàn)有的節(jié)點然后添加一個新的就行。Eureka提供了一個web-based的圖形化的運維界面，在這個界面中可以查看Eureka所管理的注冊服務(wù)的運行狀態(tài)信息：是否健康，運行日志等。Eureka甚至提供了Restful-API接口，方便第三方程序集成Eureka的功能。
3 其他注冊中心:Zookeeper,Consul,Etcd...
4 （@_@）拓展知識：CAP理論
C(一致性)、A(可用性)和P(分區(qū)容錯性),一個系統(tǒng)不可能同時滿足這三點,這就好比性能優(yōu)化時常常會考慮的時間與空間的關(guān)系。所以Zookeeper保證的是CP,而Eureka保證的是AP,在互聯(lián)網(wǎng)應(yīng)用中,大部分系統(tǒng)需要7*24小時不間斷提供服務(wù)（我們IT人只賣藝不賣身）,個人覺得AP要更加重要些。
