1. Eureka设计原理1.1. 前言

目前我越来越关注技术原理层面的东西，开始考虑中间件设计背后，要考虑哪些因素，为什么要这样设计，有什么优化的地方，这次来讨论Eureka

1.2. 设计问题

设计一个注册中心，需要考虑什么东西？一步步来

• 首先注册中心的作用是用来存储各个服务器的地址端口等信息，所以需要考虑如何存储
• 存储就需要考虑是主动去拉还是各系统自己推送地址信息过来？拉取或推送的时间频率如何考虑？如何进行拉取推送，使用socket通信？
• 如何保证注册服务的准确性，实时性，可靠性？
• 当有几百上千个服务的时候，会对Eureka造成压力吗？如何克服这种压力？
  

1.3. 注册步骤

• Eureka Client A启动后主动注册到Eureka Server，Eureka Client B再一段时间后主动向服务端拉取注册表，发现客户端A注册上来了
• 当Eureka Client C启动再注册上Eureka Server，一定时间后客户端AB再去拉取注册表，就可以发现C注册上来了
• 客户端每隔一段时间（默认30秒）会去服务端拉取注册表信息，保证注册表是最新的
• 且客户端每隔一段时间（默认30秒）会发送一次心跳，来表示客户端存活
  

1.4. 如何抗住上千台机器压力

• 假设100个服务每个部署20台机器，那就是2000台
• 按每个客户端每隔30秒发送一个心跳+一次注册表拉取，每分钟就是4次，也就是总共每分钟4*2000=8000次
• 也就是每秒8000/60=133次，换算成一天 80006024=1152 0000 也就是每天上千万的请求量了
• 经过这么一算你会发现这样的请求频率好像还能接受，只需要Eureka Server能抗住每秒200的qps就行了
• 那么它是如何抗住200qps的？Eureka采用的是ConcurrentHashMap来存储注册表信息，没错就是这玩意，我一开始看到也很吃惊，不是吃惊它什么巧妙的设计，我觉得让一个刚入行的菜鸟来做存储，可以也做成这样，只不过可能用的HashMap。但后来想想，我们系统的QPS之所以上不去，实际上耗时都在IO操作上，不管是文件操作还是数据库操作都是比较耗时的，用ConcurrentHashMap这种纯内存操作的确可以做到非常快速的响应
• 经过上面的分析，我们知道了30秒的间隔差不多就能抗住上千万的日请求了，那么就算你机器再增多上去，再加个两三千台，真撑不住的时候，你还可以改请求间隔，时间改长一点就行了
  

1.5. 服务端缓存机制

Eureka为了防止同时读写内存数据造成的并发冲突问题，采用多级缓存来提高响应速度

1.6. 注册延迟原理

• 同样的上面的机制，导致了服务注册到可使用完毕需要更多的延迟，这些延迟在什么地方呢？
• 首先是注册，查看源码会发现，客户端启动时默认需要40秒才能主动去注册
  

    @Override    public int getInitialInstanceInfoReplicationIntervalSeconds() {        return configInstance.getIntProperty(                namespace + INITIAL_REGISTRATION_REPLICATION_DELAY_KEY, 40).get();    }

• 注册之后服务端的ReadWriteCacheMap会清掉缓存，打算之后重新读内存
• 服务端后台线程默认30秒会去发现ReadWriteCacheMap清空了，就会去清空ReadOnlyCacheMap中的缓存，而这个缓存是客户端来读的时候经历的一级缓存
• 客户端来请求的周期同样是默认30秒，这又导致了一次延迟
• 而如果用Ribbon请求，它首先请求的是Eureka Client缓存的注册表，这个缓存更新同样要30秒，这样就导致了最大可能造成2分钟左右的延迟
  

这里我要着重强调，Eureka为什么要这么设计？目的是为了分散请求压力，当客户端机器越来越多的时候，不至于qps都集中到同一时刻，所以在小规模的部署中，有些时间是可以减小的

1. Eureka设计原理1.1. 前言

目前我越来越关注技术原理层面的东西，开始考虑中间件设计背后，要考虑哪些因素，为什么要这样设计，有什么优化的地方，这次来讨论Eureka

1.2. 设计问题

设计一个注册中心，需要考虑什么东西？一步步来

• 首先注册中心的作用是用来存储各个服务器的地址端口等信息，所以需要考虑如何存储
• 存储就需要考虑是主动去拉还是各系统自己推送地址信息过来？拉取或推送的时间频率如何考虑？如何进行拉取推送，使用socket通信？
• 如何保证注册服务的准确性，实时性，可靠性？
• 当有几百上千个服务的时候，会对Eureka造成压力吗？如何克服这种压力？
  

1.3. 注册步骤

• Eureka Client A启动后主动注册到Eureka Server，Eureka Client B再一段时间后主动向服务端拉取注册表，发现客户端A注册上来了
• 当Eureka Client C启动再注册上Eureka Server，一定时间后客户端AB再去拉取注册表，就可以发现C注册上来了
• 客户端每隔一段时间（默认30秒）会去服务端拉取注册表信息，保证注册表是最新的
• 且客户端每隔一段时间（默认30秒）会发送一次心跳，来表示客户端存活
  

1.4. 如何抗住上千台机器压力

• 假设100个服务每个部署20台机器，那就是2000台
• 按每个客户端每隔30秒发送一个心跳+一次注册表拉取，每分钟就是4次，也就是总共每分钟4*2000=8000次
• 也就是每秒8000/60=133次，换算成一天 80006024=1152 0000 也就是每天上千万的请求量了
• 经过这么一算你会发现这样的请求频率好像还能接受，只需要Eureka Server能抗住每秒200的qps就行了
• 那么它是如何抗住200qps的？Eureka采用的是ConcurrentHashMap来存储注册表信息，没错就是这玩意，我一开始看到也很吃惊，不是吃惊它什么巧妙的设计，我觉得让一个刚入行的菜鸟来做存储，可以也做成这样，只不过可能用的HashMap。但后来想想，我们系统的QPS之所以上不去，实际上耗时都在IO操作上，不管是文件操作还是数据库操作都是比较耗时的，用ConcurrentHashMap这种纯内存操作的确可以做到非常快速的响应
• 经过上面的分析，我们知道了30秒的间隔差不多就能抗住上千万的日请求了，那么就算你机器再增多上去，再加个两三千台，真撑不住的时候，你还可以改请求间隔，时间改长一点就行了
  

1.5. 服务端缓存机制

Eureka为了防止同时读写内存数据造成的并发冲突问题，采用多级缓存来提高响应速度

1.6. 注册延迟原理

• 同样的上面的机制，导致了服务注册到可使用完毕需要更多的延迟，这些延迟在什么地方呢？
• 首先是注册，查看源码会发现，客户端启动时默认需要40秒才能主动去注册
  

    @Override    public int getInitialInstanceInfoReplicationIntervalSeconds() {        return configInstance.getIntProperty(                namespace + INITIAL_REGISTRATION_REPLICATION_DELAY_KEY, 40).get();    }

• 注册之后服务端的ReadWriteCacheMap会清掉缓存，打算之后重新读内存
• 服务端后台线程默认30秒会去发现ReadWriteCacheMap清空了，就会去清空ReadOnlyCacheMap中的缓存，而这个缓存是客户端来读的时候经历的一级缓存
• 客户端来请求的周期同样是默认30秒，这又导致了一次延迟
• 而如果用Ribbon请求，它首先请求的是Eureka Client缓存的注册表，这个缓存更新同样要30秒，这样就导致了最大可能造成2分钟左右的延迟
  

这里我要着重强调，Eureka为什么要这么设计？目的是为了分散请求压力，当客户端机器越来越多的时候，不至于qps都集中到同一时刻，所以在小规模的部署中，有些时间是可以减小的