eureka 学习笔记1

eureka 是什么

Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers. We call this service, the Eureka Server. Eureka also comes with a Java-based client component,the Eureka Client, which makes interactions with the service much easier. The client also has a built-in load balancer that does basic round-robin load balancing. At Netflix, a much more sophisticated load balancer wraps Eureka to provide weighted load balancing based on several factors like traffic, resource usage, error conditions etc to provide superior resiliency.

eureka 适合的什么场景（能干啥？）

中小公司的微服务治理： 服务注册发现

eureka 以及常见的 注册中心对比

eureka 的缺点

Eureka in its current form is a very stable system, battle tested in large cloud deployments with tens of thousand nodes. However, it has the following major limitations:

Only support homogenous client views: Eureka servers only expects the client to always get the entire registry and does not allow to get specific applications/VIP addresses. This imposes a memory limitation on all clients registering with Eureka, even if they need a very small subset of the Eureka’s registry.

Only supports scheduled updates: Eureka client follows a poll model to fetch updates from the server routinely. This imposes an overhead on the client of doing a scheduled call to the server, even if there are no changes and also delays the updates by the poll interval.

Replication algorithm limits scalability: Eureka follows a broadcast replication model i.e. all the servers replicate data and heartbeats to all the peers. This is simple and effective for the data set that eureka contains however replication is implemented by relaying all the HTTP calls that a server receives as is to all the peers. This limits scalability as every node has to withstand the entire write load on eureka.
Although Eureka 2.0 provides a more richer feature set, the above limitations are the major driving factors for the changes proposed in this version.
当前形式的Eureka是一个非常稳定的系统，在拥有数万个节点的大型云部署中进行了战斗测试。但是，它有以下主要限制：

只支持同质客户端视图：Eureka服务器只希望客户端始终获得整个注册表，不允许获取特定的应用程序/VIP地址。这对所有在Eureka注册的客户机都施加了内存限制，即使他们需要Eureka注册表的一小部分。

只支持定时更新：Eureka客户机遵循轮询模型定期从服务器获取更新。这给客户机带来了对服务器进行定时调用的开销，即使没有更改，也会延迟轮询间隔的更新。

复制算法限制了可扩展性：Eureka遵循广播复制模型，即所有服务器将数据和心跳复制到所有对等方。对于eureka包含的数据集，这是简单而有效的，但是复制是通过将服务器接收的所有HTTP调用按原样转发给所有对等方来实现的。这限制了可伸缩性，因为每个节点都必须承受eureka上的整个写负载。

尽管Eureka 2.0提供了更丰富的功能集，但上述限制是本版本中提出的更改的主要驱动因素。

主要是这三点

当 Eureka 客户端服务实例数量达到一定时，Eureka Server 时常会出现服务不可用的情况，主要的问题集中在更新（Update）机制、复制（Replication）机制以及内存型存储，部分答案在 Eureka Wiki Eureka 2.0 Motivations 中也有描述.

由于大部分版本公司使用eureka 版本 都是1.X ，所以 不建议在生产 数以千计万计的服务实例中使用

可以考虑nacos ,或者使用某商云服务edas实现服务治理

参考文档地址

https://segmentfault.com/a/1190000015467967

https://github.com/Netflix/eureka/wiki