100个服务，​Eureka作为微服务注册中心，一天要被请求多少次？

微服务架构体系中，注册中心是一个至关重要的组件，所有的服务注册与服务发现，都是依赖注册中心。

Eureka作为微服务注册中心的核心原理

今天我们这就一起看看，SpringCloud微服务在落地公司生产环境部署时，我们估计心里会有这样的疑惑：

1、各个服务找Eureka Server拉取注册表的时候，是什么样的频率？

2、一个有几百个服务，部署了上千台机器的大型分布式系统，会对Eureka Server造成多大的访问压力？

3、Eureka Server从技术层面是如何抗住日千万级访问量的？

SpringCloud微服务中各个服务内的Eureka Client组件，默认情况下，每隔30秒会发送一个请求到Eureka Server，来拉取最近有变化的服务信息。

此外，Eureka还有一个心跳机制，各个Eureka Client每隔30秒会发送一次心跳到Eureka Server，告诉大哥，嗨，我这个还活着！

如果某个Eureka Client很长时间没有发送心跳给Eureka Server，那么就说明这个服务实例已经挂了。

光看上面的文字，可能很枯燥。还是来一张图，一起来直观的感受一下这个过程吧。

看了上图我们心中的疑惑可能还没有解开，拿来的的千万级访问呢？下面我将举个例子，我们来一起扳手指算一下。

假设有一套大型的分布式系统，一共100个服务。

1、每个服务部署在20台机器上。也就是说，相当于一共部署了100 * 20 = 2000个服务实例，

2、有2000台机器，每台机器上的服务实例内部都有一个Eureka Client组件，它会每隔30秒请求一次Eureka Server，拉取变化的注册表。

3、此外，每个服务实例上的Eureka Client都会每隔30秒发送一次心跳请求给Eureka Server。

Eureka Server 一天要被请求多少次

那么我们来算算，Eureka Server作为一个微服务注册中心，每秒钟要被请求多少次？一天要被请求多少次？

1、按标准的算法，每个服务实例每分钟请求2次拉取注册表，每分钟请求2次发送心跳，这样一个服务实例每分钟会请求4次，2000个服务实例每分钟请求8000次。

2、换算到每秒，则是8000 / 60 = 133次左右，我们就大概估算为Eureka Server每秒会被请求150次。

3、那一天的话，就是8000 * 60 * 24 = 1152万，也就是每天千万级访问量了！

根据上面的的测算，一个上百个服务，几千台机器的系统，按照这样的频率请求，日请求量在千万级，每秒的访问量在150次左右。即使算上其他一些额外操作，每秒钟请求大概在200次~300次左右。

现在关键的问题来了，Eureka Server是如何保证轻松抗住这每秒数百次请求，每天千万级请求的呢？

不要猜测，我们一起来看一下源码

如上图所示，图中这个名字叫做registry的CocurrentHashMap，就是注册表的核心结构。看完之后忍不住先赞叹一下，精妙的设计！

从代码中可以看到，Eureka Server的注册表直接基于纯内存，即在内存里维护了一个数据结构。

各个服务的注册、服务下线、服务故障，全部会在内存里维护和更新这个注册表。

各个服务每隔30秒拉取注册表的时候，Eureka Server就是直接提供内存里存储的有变化的注册表数据给他们就可以了。

同样，每隔30秒发起心跳时，也是在这个纯内存的Map数据结构里更新心跳时间。概括起来就是，维护注册表、拉取注册表、更新心跳时间，全部发生在内存里！这是Eureka Server非常核心的一个点。

这个ConcurrentHashMap的key就是服务名称，value则代表了一个服务的多个服务实例。

再来看看作为value的这个 Map：Map<String,Lease>

1、key就是服务实例的id

2、value是一个叫做Lease的类，里面的InstanceInfo，这个代表了服务实例的具体信息，比如机器的ip地址、hostname以及端口号。

3、而Lease，维护着每个服务最近一次发送心跳的时间

Eureka 不仅仅基于内存来承载各个服务的请求，而且还有优秀的多级缓存机制。

为了避免同时读写内存数据结构造成的并发冲突问题，Eureka 采用了多级缓存机制来进一步提升服务请求的响应速度。

1、拉取注册表的步骤：

首先从ReadOnlyCacheMap里查缓存的注册表。

若没有，就找ReadWriteCacheMap里缓存的注册表。

如果还没有，就从内存中获取实际的注册表数据

2、在注册表发生变更的时候：

在内存中更新变更的注册表数据，同时过期掉ReadWriteCacheMap。
此过程不会影响ReadOnlyCacheMap提供查询注册表。

一段时间内（默认30秒），各服务拉取注册表会直接读ReadOnlyCacheMap。

30秒过后，Eureka Server的后台线程发现ReadWriteCacheMap已经清空了，也会清空ReadOnlyCacheMap中的缓存。

下次有服务拉取注册表，又会从内存中获取最新的数据了，同时填充各个缓存。

Eureka 为什么采用多级缓存机制，其优点在哪里？

尽可能保证了内存注册表数据不会出现频繁的读写冲突问题。

进一步保证对Eureka Server的大量请求，都是快速从纯内存走，性能极高。

说了这么多还是来一张图更直观的描述一下过程：

总结

Eureka作为微服务注册中心可以承载每天千万级访问量的原理

1、通过设置适当的请求频率（拉取注册表30秒间隔，发送心跳30秒间隔），保证一个大规模的系统每秒请求注册中心的次数在几百次。

2、通过纯内存的注册表，保证了所有的请求都可以在内存处理，确保了极高的性能

3、多级缓存机制，确保了不会针对内存数据结构发生频繁的读写并发冲突操作，进一步提升性能。

来源：https://url.cn/5jeXlXV