forward from:
http://blog.csdn.net/forezp/article/details/73017664
This article is from Fang Zhipeng's blog
Some concepts of Eureka
-
Register: Service registration
When an Eureka client registers with Eureka Server, it provides its own metadata, such as IP address, port, health indicator URL, home page, etc. -
Renew: Service renewal
Eureka clients will send a heartbeat every 30 seconds to renew the contract. Renew the contract to inform Eureka Server that the Eureka client still exists and there is no problem. Normally, if Eureka Server does not receive a renewal from an Eureka client within 90 seconds, it will delete the instance from its registry. Changing the renewal interval is not recommended. -
Fetch Registries: Get registration list information
The Eureka client gets the registry information from the server and caches it locally. Clients use this information to find other services to make remote calls. This registration list information is updated periodically (every 30 seconds). The registration list information returned each time may be different from the cached information of the Eureka client, and the Eureka client handles it automatically. If the registration list information cannot be matched in time for some reason, the Eureka client will re-obtain the entire registry information. The Eureka server caches the registry information, the entire registry and each application's information is compressed, and the compressed content is exactly the same as the uncompressed content. Eureka client and Eureka server can communicate using JSON/XML format. By default the Eureka client uses compressed JSON format to get the registration list information. -
Cancel:
The Eureka client sends a cancellation request to the Eureka server when the service is offline. After the request is sent, the client instance information is removed from the server's instance registry. The shutdown request will not be done automatically, it needs to call the following:
DiscoveryManager.getInstance().shutdownComponent(); -
Eviction service removal
By default, when the Eureka client does not send a service renewal, that is, a heartbeat, to the Eureka server for 90 consecutive seconds, the Eureka server will delete the service instance from the service registration list, that is, service removal.
Eureka's high-availability architecture
The picture shows the high- level architecture diagram of Eureka, which is from the Eureka open source code document at https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance .
It can be seen from the figure that there are two roles in this system, namely Eureka Server and Eureka Client. The Eureka Client is divided into Applicaton Service and Application Client, that is, service providers and service consumers. There is one Eureka cluster per region, and at least one eureka server per region can handle region failure in case the server goes down.
Eureka Client registers with Eureka Serve and sends some of its client information to Eureka Serve. Then, Eureka Client renews the service by sending heartbeats (every 30 seconds) to Eureka Server. If the client continues to fail to renew, then it will be removed from the server registry in about 90 seconds. Registration information and renewals are replicated to all Eureka Serve nodes in the cluster. Registry information can be looked up by Eureka Clients from any region (occurs every 30 seconds). Based on these registry information, Application Client can remotely call Applicaton Service to consume services.
Register service registration
Service registration, that is, Eureka Client submits its own service information to Eureka Server, including IP address, port, service ID and other information. If Eureka Client does not write service ID, it defaults to ${ spring .application.name}.
Service registration is actually very simple. When Eureka Client starts, it sends its own service information to Eureka Server. Now let's briefly read the source code. Under Maven's dependency package, find the eureka-client-1.6.2.jar package. There is a DiscoveryClient class under the com.netflix.discovery package, which contains the related methods from Eureka Client to Eureka Server. Among them, DiscoveryClient implements the EurekaClient interface, and it is a singleton mode, and EurekaClient inherits the LookupService interface. The relationship between them is shown in the figure.
There is a service registration method register() in the DiscoveryClient class, which is registered with Eureka Client through Http request. Its code is as follows:
boolean register() throws Throwable {
logger.info(PREFIX + appPathIdentifier + ": registering service...");
EurekaHttpResponse<Void> httpResponse;
try {
httpResponse = eurekaTransport.registrationClient.register(instanceInfo);
} catch (Exception e) {
logger.warn("{} - registration failed {}", PREFIX + appPathIdentifier, e.getMessage(), e);
throw e;
}
if (logger.isInfoEnabled()) {
logger.info("{} - registration status: {}", PREFIX + appPathIdentifier, httpResponse.getStatusCode());
}
return httpResponse.getStatusCode() == 204;
}
在DiscoveryClient类继续追踪register()方法，它被InstanceInfoReplicator 类的run()方法调用，其中InstanceInfoReplicator实现了Runnable接口，run()方法代码如下：
public void run() {
try {
discoveryClient.refreshInstanceInfo();
Long dirtyTimestamp = instanceInfo.isDirtyWithTime();
if (dirtyTimestamp != null) {
discoveryClient.register();
instanceInfo.unsetIsDirty(dirtyTimestamp);
}
} catch (Throwable t) {
logger.warn("There was a problem with the instance info replicator", t);
} finally {
Future next = scheduler.schedule(this, replicationIntervalSeconds, TimeUnit.SECONDS);
scheduledPeriodicRef.set(next);
}
}
而InstanceInfoReplicator类是在DiscoveryClient初始化过程中使用的，其中有一个initScheduledTasks()方法。该方法主要开启了获取服务注册列表的信息，如果需要向Eureka Server注册，则开启注册，同时开启了定时向Eureka Server服务续约的定时任务，具体代码如下：
private void initScheduledTasks() {
...//省略了任务调度获取注册列表的代码
if (clientConfig.shouldRegisterWithEureka()) {
...
// Heartbeat timer
scheduler.schedule(
new TimedSupervisorTask(
"heartbeat",
scheduler,
heartbeatExecutor,
renewalIntervalInSecs,
TimeUnit.SECONDS,
expBackOffBound,
new HeartbeatThread()
),
renewalIntervalInSecs, TimeUnit.SECONDS);
// InstanceInfo replicator
instanceInfoReplicator = new InstanceInfoReplicator(
this,
instanceInfo,
clientConfig.getInstanceInfoReplicationIntervalSeconds(),
2); // burstSize
statusChangeListener = new ApplicationInfoManager.StatusChangeListener() {
@Override
public String getId() {
return "statusChangeListener";
}
@Override
public void notify(StatusChangeEvent statusChangeEvent) {
instanceInfoReplicator.onDemandUpdate();
}
};
...
}
然后在来看Eureka server端的代码，在Maven的eureka-core:1.6.2的jar包下。打开com.netflix.eureka包，很轻松的就发现了又一个EurekaBootStrap的类，BootStrapContext具有最先初始化的权限，所以先看这个类。
protected void initEurekaServerContext() throws Exception {
...//省略代码
PeerAwareInstanceRegistry registry;
if (isAws(applicationInfoManager.getInfo())) {
...//省略代码，如果是AWS的代码
} else {
registry = new PeerAwareInstanceRegistryImpl(
eurekaServerConfig,
eurekaClient.getEurekaClientConfig(),
serverCodecs,
eurekaClient
);
}
PeerEurekaNodes peerEurekaNodes = getPeerEurekaNodes(
registry,
eurekaServerConfig,
eurekaClient.getEurekaClientConfig(),
serverCodecs,
applicationInfoManager
);
}
其中PeerAwareInstanceRegistryImpl和PeerEurekaNodes两个类看其命名，应该和服务注册以及Eureka Server高可用有关。先追踪PeerAwareInstanceRegistryImpl类，在该类有个register()方法，该方法提供了注册，并且将注册后信息同步到其他的Eureka Server服务。代码如下：
public void register(final InstanceInfo info, final boolean isReplication) {
int leaseDuration = Lease.DEFAULT_DURATION_IN_SECS;
if (info.getLeaseInfo() != null && info.getLeaseInfo().getDurationInSecs() > 0) {
leaseDuration = info.getLeaseInfo().getDurationInSecs();
}
super.register(info, leaseDuration, isReplication);
replicateToPeers(Action.Register, info.getAppName(), info.getId(), info, null, isReplication);
}
其中 super.register(info, leaseDuration, isReplication)方法，点击进去到子类AbstractInstanceRegistry可以发现更多细节，其中注册列表的信息被保存在一个Map中。replicateToPeers()方法，即同步到其他Eureka Server的其他Peers节点，追踪代码，发现它会遍历循环向所有的Peers节点注册，最终执行类PeerEurekaNodes的register()方法，该方法通过执行一个任务向其他节点同步该注册信息，代码如下：
public void register(final InstanceInfo info) throws Exception {
long expiryTime = System.currentTimeMillis() + getLeaseRenewalOf(info);
batchingDispatcher.process(
taskId("register", info),
new InstanceReplicationTask(targetHost, Action.Register, info, null, true) {
public EurekaHttpResponse<Void> execute() {
return replicationClient.register(info);
}
},
expiryTime
);
}
经过一系列的源码追踪，可以发现PeerAwareInstanceRegistryImpl的register()方法实现了服务的注册，并且向其他Eureka Server的Peer节点同步了该注册信息，那么register()方法被谁调用了呢？之前在Eureka Client的分析可以知道，Eureka Client是通过 http来向Eureka Server注册的，那么Eureka Server肯定会提供一个注册的接口给Eureka Client调用，那么PeerAwareInstanceRegistryImpl的register()方法肯定最终会被暴露的Http接口所调用。在Idea开发工具，按住alt+鼠标左键，可以很快定位到ApplicationResource类的addInstance ()方法，即服务注册的接口，其代码如下：
@POST
@Consumes({"application/json", "application/xml"})
public Response addInstance(InstanceInfo info,
@HeaderParam(PeerEurekaNode.HEADER_REPLICATION) String isReplication) {
...//省略代码
registry.register(info, "true".equals(isReplication));
return Response.status(204).build(); // 204 to be backwards compatible
}
Renew服务续约
服务续约和服务注册非常类似，通过之前的分析可以知道，服务注册在Eureka Client程序启动之后开启，并同时开启服务续约的定时任务。在eureka-client-1.6.2.jar的DiscoveryClient的类下有renew()方法，其代码如下：
/**
* Renew with the eureka service by making the appropriate REST call
*/
boolean renew() {
EurekaHttpResponse<InstanceInfo> httpResponse;
try {
httpResponse = eurekaTransport.registrationClient.sendHeartBeat(instanceInfo.getAppName(), instanceInfo.getId(), instanceInfo, null);
logger.debug("{} - Heartbeat status: {}", PREFIX + appPathIdentifier, httpResponse.getStatusCode());
if (httpResponse.getStatusCode() == 404) {
REREGISTER_COUNTER.increment();
logger.info("{} - Re-registering apps/{}", PREFIX + appPathIdentifier, instanceInfo.getAppName());
return register();
}
return httpResponse.getStatusCode() == 200;
} catch (Throwable e) {
logger.error("{} - was unable to send heartbeat!", PREFIX + appPathIdentifier, e);
return false;
}
}
另外服务端的续约接口在eureka-core:1.6.2.jar的 com.netflix.eureka包下的InstanceResource类下，接口方法为renewLease()，它是REST接口。为了减少类篇幅，省略了大部分代码的展示。其中有个registry.renew()方法，即服务续约，代码如下:
@PUT
public Response renewLease(...参数省略）{
... 代码省略
boolean isSuccess=registry.renew(app.getName(),id, isFromReplicaNode);
... 代码省略
}
读者可以跟踪registry.renew的代码一直深入研究。在这里就不再多讲述。另外服务续约有2个参数是可以配置，即Eureka Client发送续约心跳的时间参数和Eureka Server在多长时间内没有收到心跳将实例剔除的时间参数，在默认的情况下这两个参数分别为30秒和90秒，官方给的建议是不要修改，如果有特殊要求还是可以调整的，只需要分别在Eureka Client和Eureka Server修改以下参数：
eureka.instance.leaseRenewalIntervalInSeconds eureka.instance.leaseExpirationDurationInSeconds
最后，服务注册列表的获取、服务下线和服务剔除就不在这里进行源码跟踪解读，因为和服务注册和续约类似，有兴趣的朋友可以自己看下源码，深入理解。总的来说，通过读源码，可以发现，整体架构与前面小节的eureka 的高可用架构图完全一致。
Eureka Client注册一个实例为什么这么慢
- Eureka Client一启动（不是启动完成），不是立即向Eureka Server注册，它有一个延迟向服务端注册的时间，通过跟踪源码，可以发现默认的延迟时间为40秒，源码在eureka-client-1.6.2.jar的DefaultEurekaClientConfig类下，代码如下：
public int getInitialInstanceInfoReplicationIntervalSeconds() {
return configInstance.getIntProperty(
namespace + INITIAL_REGISTRATION_REPLICATION_DELAY_KEY, 40).get();
}
-
Eureka Server的响应缓存
Eureka Server维护每30秒更新的响应缓存,可通过更改配置eureka.server.responseCacheUpdateIntervalMs来修改。 所以即使实例刚刚注册，它也不会出现在调用/ eureka / apps REST端点的结果中。 -
Eureka Server刷新缓存
Eureka客户端保留注册表信息的缓存。 该缓存每30秒更新一次（如前所述）。 因 此，客户端决定刷新其本地缓存并发现其他新注册的实例可能需要30秒。 -
LoadBalancer Refresh
Ribbon的负载平衡器从本地的Eureka Client获取服务注册列表信息。Ribbon本身还维护本地缓存，以避免为每个请求调用本地客户端。 此缓存每30秒刷新一次（可由ribbon.ServerListRefreshInterval配置）。 所以，可能需要30多秒才能使用新注册的实例。
综上几个因素，一个新注册的实例，特别是启动较快的实例（默认延迟40秒注册），不能马上被Eureka Server发现。另外，刚注册的Eureka Client也不能立即被其他服务调用，因为调用方因为各种缓存没有及时的获取到新的注册列表。
Eureka 的自我保护模式
当一个新的Eureka Server出现时，它尝试从相邻节点获取所有实例注册表信息。如果从Peer节点获取信息时出现问题，Eureka Serve会尝试其他的Peer节点。如果服务器能够成功获取所有实例，则根据该信息设置应该接收的更新阈值。如果有任何时间，Eureka Serve接收到的续约低于为该值配置的百分比（默认为15分钟内低于85％），则服务器开启自我保护模式，即不再剔除注册列表的信息。
The advantage of this is that if the Eureka Server's own network problem causes the Eureka Client to fail to renew the contract, the Eureka Client's registration list information will no longer be deleted, that is, the Eureka Client can also be consumed by other services.
References
http://cloud.spring.io/spring-cloud-static/Dalston.RELEASE/#netflix-eureka-client-starter
https://github.com/Netflix/eureka/wiki
https://github.com/Netflix/eureka/wiki/Understanding-Eureka-Peer-to-Peer-Communication
http://xujin.org/sc/sc-eureka-register/