Profile of Eureka

What is 1. Eureka

Eureka is a REST-based services, mainly for AWS cloud location service, in order to achieve load balancing and failover server transfer of the intermediate layer

In Spring Cloud  micro-service architecture typically used as registration centers

Eureka consists of two components: Eureka Server and Eureka Client.

Eureka Server service registration services, after each node starts, it will be registered in Eureka Server, so EurekaServer in the service registry will store all information available information service node, service node can visually see in the interface .

Java Eureka Client is a client for interacting with the simplified Eureka Server, the client is also a built-in polling (round-robin) load load balancing algorithm.

Between Eureka Server synchronization is accomplished by way of copying data, Eureka also provides client-side caching mechanism, even if all of Eureka Server will hang up, the client still can use the information in the cache API consumption of other services. In summary, Eureka heartbeat checking, client caching mechanisms to ensure high system availability, flexibility and scalability.

We call this service for Eureka Server, as well as interact with a client called Eureka Client

2. Why use Eureka?

Because in a complete system architecture, any single point of service can not be guaranteed not to break, so we need to service discovery mechanism, after a node is interrupted, the other nodes can continue to provide services to ensure that the entire system is highly available of.
Service Discovery has two modes: one is a client discovery mode, one is the server discovery mode.

Erueka uses client discovery mode.

3. Eureka High Level Architecture

As shown above, wherein

Application Server represents a service provider

Application Client represents the service consumer

Make Remote Call representing remote call

Eureka service on the registration, and then sends a heartbeat every 30 seconds to update their lease. If the client can not repeatedly renew the lease, it will be removed from the registry server in about 90 seconds. Registration information and updates are replicated to all nodes in the cluster eureka. The client from any district can find registry information (occurs every 30 seconds) to locate their services (possible in any area) and long-distance calls.

(PS: Eureka Client needs Eureka Server every 30 seconds to send a heartbeat, while the latest update registration information on Server locally, repeatedly if Server does not receive a heartbeat from the client, it will be removed in 90 seconds on the Server)

Communication between the client and the server 4. Eureka

Service Discovery has two modes: one is a client discovery mode, one is the server discovery mode. Eureka uses client discovery mode.

4.1. Register (Register)

Eureka client information about registering to run instances of the server Eureka. Registration occurs at the first heartbeat.

4.2. Renew (update / renew)

Eureka client needs to update the latest registration information (renewal), by sending a heartbeat every 30 seconds. Update Notification is to tell the Eureka server instances are still alive. If the server within 90 seconds did not see the update, it will be deleted from the registry instance. It recommended not to change the update interval because the server uses this information to determine whether the problem is widespread communication between the client and server exist.

4.3. Fetch Registry (crawl registration information)

Eureka client obtains information from the registry server and cached locally. After that, the client uses this information to locate other services. By acquiring the incremental update between the acquisition period and a current acquisition period, the information is updated (every 30 seconds) on a regular basis. When it is retrieved might return the same instance. Eureka client automatically repeats the process information.

4.4. Cancel (Cancel)

Eureka Eureka client sends the server a cancel shutdown request. This will remove the instance registry server instances, the instances effectively removed from the traffic.

5. Eureka limp home mode

如果 Eureka 服务器检测到超过预期数量的注册客户端以一种不优雅的方式终止了连接，并且同时正在等待被驱逐，那么它们将进入自我保护模式。这样做是为了确保灾难性网络事件不会擦除eureka注册表数据，并将其向下传播到所有客户端。

任何客户端，如果连续3次心跳更新失败，那么它将被视为非正常终止，病句将被剔除。当超过当前注册实例15%的客户端都处于这种状态，那么自我保护将被开启。

当自我保护开启以后，eureka服务器将停止剔除所有实例，直到：

1. 它看到的心跳续借的数量回到了预期的阈值之上，或者
2. 自我保护被禁用

默认情况下，自我保护是启用的，并且，默认的阈值是要大于当前注册数量的15%

6.  Eureka  VS  Zookeeper

6.1.  Eureka保证AP

Eureka服务器节点之间是对等的，只要有一个节点在，就可以正常提供服务。

Eureka客户端的所有操作可能需要一段时间才能在Eureka服务器中反映出来，随后在其他Eureka客户端中反映出来。也就是说，客户端获取到的注册信息可能不是最新的，它并不保证强一致性

6.2.  Zookeeper保证CP

Zookeeper集群中有一个Leader，多个Follower。Leader负责写，Follower负责读，ZK客户端连接到任何一个节点都是一样的，写操作完成以后要同步给所有Follower以后才会返回。如果Leader挂了，那么重新选出新的Leader，在此期间服务不可用。

6.3.  为什么用Eureka

分布式系统大都可以归结为两个问题：数据一致性和防止单点故障。而作为注册中心的话，即使在一段时间内不一致，也不会有太大影响，所以在A和C之间选择A是比较适合该场景的。

关于AP和CP拓展

CAP理论提出就是针对分布式数据库环境的，所以，P这个属性是必须具备的。
P就是在分布式环境中，由于网络的问题可能导致某个节点和其它节点失去联系，这时候就形成了P(partition)，也就是由于网络问题，将系统的成员隔离成了2个区域，互相无法知道对方的状态，这在分布式环境下是非常常见的。
因为P是必须的，那么我们需要选择的就是A和C。
大家知道，在分布式环境下，为了保证系统可用性，通常都采取了复制的方式，避免一个节点损坏，导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况，而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的，所以，当P发生时，也就是无法向某个节点复制数据时，这时候你有两个选择：
选择可用性 A(Availability)，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。
选择一致性C(Consistency)，为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。