技術/楊33
一、Eureka的介紹
在前後端分離架構中，服務層被拆分成了很多的微服務，那麼服務註冊中心就管理著服務與服務之間的一個依賴關係。
EureKa在Spring Cloud全家桶中擔任著服務的註冊與發現的落地實現。
Eureka包含兩個組件：Eureka Server和Eureka Client。
Eureka Server：註冊中心服務端。提供服務註冊，各個服務節點啟動後，在EureKa server中進行註冊
Eureka Client：註冊中心客戶端。Eureka Client 是一個 Java 客戶端，用於簡化與 Eureka Server 的交互。Eureka Client 會拉取、更新和緩存 Eureka Server 中的信息。
二、Eureka的通信原理
Eureka Server採用的是Peer to Peer對等通信，每一個Peer都是對等的。
節點通過彼此互相註冊來提高可用性，每個節點需要添加一個或多個有效的serviceUrl指向其他節點，每個節點都可被視為其他節點的副本。
如果某臺Eureka Server宕機，Eureka Client的請求會自動切換到新的Eureka Server節點。當宕機的服務器重新恢復後，Eureka會再次將其納入到服務器集群管理之中。
一個新的Eureka Server節點啟動後，會首先嚐試從鄰近節點獲取所有實例註冊表信息，完成初始化。
Eureka Server通過getEurekaServerUrls()方法獲取所有節點，並且通過心跳續約的方式是定期更新。默認配置下，如果Eureka Server在一定時間內沒有接收到某個服務實例的心跳，Eureka Server將會註銷該實例。這個時間默認是90秒，通過eureka.instance.lease-expiration-duration-in-seconds配置。
當Eureka Server節點在短時間內丟失過多的心跳時，這個節點就會進入自我保護模式。
三、Eureka的自我保護模式
默認配置下，如果Eureka Server每分鐘收到的心跳續約的數量低於一個閾值，並且持續15分鐘，就會觸發自我保護模式。
在自我保護模式下，Eureka Server會保護服務註冊表中的信息，不再註銷任何服務實例，當它收到的心跳數重新恢復到閾值以上時，該Eureka Server節點會自動退出自我保護模式。
自我保護模式的設計理念就是寧可保留錯誤的服務註冊信息，也不盲目註銷任何可能健康的服務實例。
禁用自我保護模式：eureka.server.enable-self-preservation = false
改變心跳時間間隔：eureka.instance.lease-renewal-interval-in-seconds = ？？？
修改自我保護係數：eureka.server.renewal-percent-threshold = ？？？，默認是0.85。
四、搭建註冊中心服務端Eureka Server
1、創建項目module
Eureka Server的項目module
2、pom.xml文件添加依賴
<code><
project
xmlns
="http://maven.apache.org/POM/4.0.0"
xmlns:xsi
="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation
="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
><
parent
><
artifactId
>cloudprojectartifactId
><
groupId
>com.project.cloudgroupId
><
version
>1.0-SNAPSHOTversion
>parent
><
modelVersion
>4.0.0modelVersion
><
artifactId
>cloud-eureka-server7001artifactId
><
dependencies
><
dependency
><
groupId
>org.springframework.cloudgroupId
><
artifactId
>spring-cloud-starter-netflix-eureka-serverartifactId
>dependency
><
dependency
><
artifactId
>cloud-common-utilartifactId
><
groupId
>com.project.cloudgroupId
><
version
>1.0-SNAPSHOTversion
>dependency
><
dependency
><
groupId
>org.springframework.bootgroupId
><
artifactId
>spring-boot-starter-webartifactId
>dependency
><
dependency
><
groupId
>org.springframework.bootgroupId
><
artifactId
>spring-boot-starter-actuatorartifactId
>dependency
><
dependency
><
groupId
>org.springframework.bootgroupId
><
artifactId
>spring-boot-devtoolsartifactId
><
scope
>runtimescope
><
optional
>trueoptional
>dependency
><
dependency
><
groupId
>org.projectlombokgroupId
><
artifactId
>lombokartifactId
>dependency
>dependencies
>project
>/<code>
3、添加application.yml配置文件
<code>server:
port:
7001
eureka:
instance:
hostname:
localhost
client:
register-with-eureka:
false
fetch-registry:
false
service-url:
defaultZone:
http://${eureka.instance.hostname}:${server.port}/eureka/
/<code>
4、編寫主啟動類
<code>package
com.cloud;import
org.springframework.boot.SpringApplication;import
org.springframework.boot.autoconfigure.SpringBootApplication;import
org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;public
class
EurekaMain7001
{public
static
void
main
(String[] args)
{ SpringApplication.run(EurekaMain7001.
class
,args
); } }/<code>
5、啟動主啟動類，瀏覽器訪問：http://localhost:7001/
打開Eureka Server的web管理頁面。
Eureka Server的web管理頁面
五、都是服務註冊中心的ZooKeeper和Eureka對比
在分佈式系統，有三個特性：
C-數據一致性、A-服務可用性、P-服務對網絡分區故障的容錯性。它們統稱為CAP定理。這三個特性在任何分佈式系統中，是不能同時滿足的，最多同時滿足兩個。
- ZooKeeper是基於CP設計的。可以保證數據一致性。
在任何時刻對Zookeeper的訪問請求都可以得到一致的數據，同時系統對網絡分割具備容錯性，但它不能保證每次服務請求的可用性。
什麼情況下會發生服務不可用呢？
如果Zookeeper正在選主，或者Zookeeper集群中半數以上的機器不可用，就會發生從服務器上獲取不到數據。
為什麼Zookeeper設計為保證數據一致性呢？
基於很多分佈式涉及到數據存儲的場景，保證數據的一致性是最為重要的。
- Eureka是基於AP設計的。可以保證服務可用性。
即使所有的機器都掛了，也能拿到本地緩存的數據，保證服務能返回數據結果。
理論上，Eureka更適合做服務註冊中心。而Zookeeper的使用，在實際環境下，也基本不會出現服務器宕機一半以上的情況，所以Zookeeper實際上也沒什麼大問題。
作者：楊33，北京互聯網公司在職Java開發，專注分享寫作乾貨。歡迎關注我，期待你的點贊評論。
