netflix eureka 版本功能比对升级-翻译

Netflix Eureka是微服务的服务注册发现框架。

 

eureka 1.X发布了稳定版本，但是正在研发2.X

 

1. 1.X版本架构

1. 为什么采用2.X

Eureka 1.X是一个稳定的系统，并且在数以万计节点的大规模云部署环境下，通过了瓶颈测试。但是其有以下几个重要的限制：

• 只能够支持相同性质client视图。Eureka Server只认为所有的client都需要整个注册信息，不支持client监听指定的几个应用，或者vip地址。这强迫所有的client都花费大量的内存存放整个注册信息，即使此client只用到很少的注册信息。
• 只支持定期更新。Eureka client只能定期从server拉取更新模型。这强迫client在注册信息没有更新的情况下，也需要定期访问server。同时，在更新周期内，更新的注册信息会延期到达。
• 复制算法限制可扩展性。Eureka遵从广播复制，所有的server冗余存储注册信息，并且和所有的节点维护心跳信息。这个算法很简单，并且在已有节点之间具有很高效率。但是一旦有新的节点加入，就需要将server接收到节点的链接，复制给所有人。所有的节点都需要顶住Eureka整体的写负载，从而限制可扩展性。

Eureka 的提升：

• 以 Interest为基础的注册信息订阅模型：Eureka client可以选择订阅自己关心的整体注册信息的一部分，Server只会发送此部分的注册信息。Eureka提供了不同的订阅准则，并且以一种动态的方式更新这些订阅信息。
• Server采用Push方式，将感兴趣的信息推送给client.Server采用push的方式，替代了client定期pull的方式。
• 复制规则优化：Eureka 2.X依旧支持广播复制模式。每个节点将数据复制给所有的节点。但是复制规则更加优化，消除了将心跳发给每个节点的弊端。这大幅降低了复制通信流量，从而更加容易扩展。
• Eureka Server自动扩展：Eureka 2.X将server分为read和write。write的规模是实现预估好的。read的规模是不可预估的，且可以动态扩展。
• 统计日志
• Dashboard

 

1. 2.X版本架构

 

client在write cluster上注册和发现read cluster。

read cluster注册到write cluster。

一旦注册信息有变化，write cluster通知read cluster，read cluster 通知client。

client 注册。client 的注册，心跳维护，信息更新，取消注册，都是在write cluster上操作。

 

注册信息发现。注册信息的更新，都是通过read cluster获取。client的订阅，取消订阅都是基于read cluster。

 

订阅数据模型。Eureka 2定位于同 各种各样的云服务提供者和数据中心交互工作，所以他的数据是可扩展的。数据模型通过key-value对进行信息扩展。

 

Interest订阅模型

可以支持的订阅维度：

• application interest - all service instances belonging to a given application
• vip interest - all service instances belonging to a particular eureka virtual address (vip)
• instance id - a specific instance with a given id
• full registry - a special interest type denoting all entries in the registry (should be rarely used as may generate huge traffic for large registries)

application/vip/instance id interests 支持关联的操作符:

• Equals - match exactly the provided value
• Like - treat interest value as a regular expression

不同的条件之间可以通过OR来进行组合。

转载于:https://my.oschina.net/u/347227/blog/1142887