阿里双11狂欢如何承载大型系统的千万级访问？

1、问题起源

Spring Cloud微服务架构体系中，Eureka是一个相当重要的组件，它扮演着微服务注册中心的角色，全部的服务注册与服务发现，都是依赖Eureka的。

很多初学Spring Cloud的朋友在落地公司生产环境部署时，常常会问：

• Eureka Server到底要部署几台机器？
• 咱们的系统那么多服务，到底会对Eureka Server产生多大的访问压力？
• Eureka Server能不能抗住一个大型系统的访问压力？

若是你也有这些疑问，别着急！我们这就一块儿去看看，Eureka做为微服务注册中心的核心原理

下面这些问题，你们先看看，有个大概印象。带着这些问题，来看后面的内容，效果更佳！

1. Eureka注册中心使用什么样的方式来储存各个服务注册时发送过来的机器地址和端口号？
2. 各个服务找Eureka Server拉取注册表的时候，是什么样的频率？
3. 各个服务是如何拉取注册表的？
4. 一个有几百个服务，部署了上千台机器的大型分布式系统，会对Eureka Server形成多大的访问压力？
5. Eureka Server从技术层面是如何抗住日千万级访问量的？

先给你们说一个基本的知识点，各个服务内的Eureka Client组件，默认状况下，每隔30秒会发送一个请求到Eureka Server，来拉取最近有变化的服务信息

举个例子：

• 库存服务本来部署在1台机器上，如今扩容了，部署到了3台机器，而且均注册到了Eureka Server上。
• 而后订单服务的Eureka Client会每隔30秒去找Eureka Server拉取最近注册表的变化，看看其余服务的地址有没有变化。

除此以外，Eureka还有一个心跳机制，各个Eureka Client每隔30秒会发送一次心跳到Eureka Server，通知人家说，哥们，我这个服务实例还活着！

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

光看上面的文字，你们可能没什么印象。老规矩！我们仍是来一张图，一块儿来直观的感觉一下这个过程。

 

 

 

2、Eureka Server设计精妙的注册表存储结构

如今我们假设手头有一套大型的分布式系统，一共100个服务，每一个服务部署在20台机器上，机器是4核8G的标准配置。

也就是说，至关于你一共部署了100 * 20 = 2000个服务实例，有2000台机器。

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

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

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

• 按标准的算法，每一个服务实例每分钟请求2次拉取注册表，每分钟请求2次发送心跳
• 这样一个服务实例每分钟会请求4次，2000个服务实例每分钟请求8000次
• 换算到每秒，则是8000 / 60 = 133次左右，咱们就大概估算为Eureka Server每秒会被请求150次
• 那一天的话，就是8000 * 60 * 24 = 1152万，也就是天天千万级访问量

好！通过这么一个测算，你们是否发现这里的奥秘了？

• 首先，对于微服务注册中心这种组件，在一开始设计它的拉取频率以及心跳发送频率时，就已经考虑到了一个大型系统的各个服务请求时的压力，每秒会承载多大的请求量。
• 因此各服务实例每隔30秒发起请求拉取变化的注册表，以及每隔30秒发送心跳给Eureka Server，其实这个时间安排是有其用意的。

按照咱们的测算，一个上百个服务，几千台机器的系统，按照这样的频率请求Eureka Server，日请求量在千万级，每秒的访问量在150次左右。

即便算上其余一些额外操做，咱们姑且就算每秒钟请求Eureka Server在200次~300次吧。

因此经过设置一个适当的拉取注册表以及发送心跳的频率，能够保证大规模系统里对Eureka Server的请求压力不会太大。

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

要搞清楚这个，首先得清楚Eureka Server究竟是用什么来存储注册表的？三个字，看源码！

接下来我们就一块儿进入Eureka源码里一探究竟：

 

 

 

• 如上图所示，图中这个名字叫作registry的CocurrentHashMap，就是注册表的核心结构。看完以后忍不住先赞叹一下，精妙的设计！
• 从代码中能够看到，Eureka Server的注册表直接基于纯内存，即在内存里维护了一个数据结构。
• 各个服务的注册、服务下线、服务故障，所有会在内存里维护和更新这个注册表。
• 各个服务每隔30秒拉取注册表的时候，Eureka Server就是直接提供内存里存储的有变化的注册表数据给他们就能够了。

一样，每隔30秒发起心跳时，也是在这个纯内存的Map数据结构里更新心跳时间。

一句话归纳：维护注册表、拉取注册表、更新心跳时间，所有发生在内存里！这是Eureka Server很是核心的一个点。

搞清楚了这个，我们再来分析一下registry这个东西的数据结构，你们千万别被它复杂的外表唬住了，沉下心来，一层层的分析！

• 首先，这个ConcurrentHashMap的key就是服务名称，好比“inventory-service”，就是一个服务名称。
• value则表明了一个服务的多个服务实例。
• 举例：好比“inventory-service”是能够有3个服务实例的，每一个服务实例部署在一台机器上。

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

• 这个Map的key就是服务实例的id
• value是一个叫作Lease的类，它的泛型是一个叫作InstanceInfo的东东，你可能会问，这俩又是什么鬼？
• 首先说下InstanceInfo，其实啊，咱们见名知义，这个InstanceInfo就表明了服务实例的具体信息，好比机器的ip地址、hostname以及端口号。
• 而这个Lease，里面则会维护每一个服务最近一次发送心跳的时间

3、Eureka Server端优秀的多级缓存机制

假设Eureka Server部署在4核8G的普通机器上，那么基于内存来承载各个服务的请求，每秒钟最多能够处理多少请求呢？

• 根据以前的测试，单台4核8G的机器，处理纯内存操做，哪怕加上一些网络的开销，每秒处理几百请求也是轻松加愉快的。
• 并且Eureka Server为了不同时读写内存数据结构形成的并发冲突问题，还采用了多级缓存机制来进一步提高服务请求的响应速度。
• 在拉取注册表的时候：
• 首先从ReadOnlyCacheMap里查缓存的注册表。
• 若没有，就找ReadWriteCacheMap里缓存的注册表。
• 若是尚未，就从内存中获取实际的注册表数据。
• 在注册表发生变动的时候：
• 会在内存中更新变动的注册表数据，同时过时掉ReadWriteCacheMap。
• 此过程不会影响ReadOnlyCacheMap提供人家查询注册表。
• 一段时间内（默认30秒），各服务拉取注册表会直接读ReadOnlyCacheMap
• 30秒事后，Eureka Server的后台线程发现ReadWriteCacheMap已经清空了，也会清空ReadOnlyCacheMap中的缓存
• 下次有服务拉取注册表，又会从内存中获取最新的数据了，同时填充各个缓存。

多级缓存机制的优势是什么？

• 尽量保证了内存注册表数据不会出现频繁的读写冲突问题。
• 而且进一步保证对Eureka Server的大量请求，都是快速从纯内存走，性能极高。

为方便你们更好的理解，一样来一张图，你们跟着图再来回顾一下这整个过程：

 

 

 

4、总结

• 经过上面的分析能够看到，Eureka经过设置适当的请求频率（拉取注册表30秒间隔，发送心跳30秒间隔），能够保证一个大规模的系统每秒请求Eureka Server的次数在几百次。
• 同时经过纯内存的注册表，保证了全部的请求均可以在内存处理，确保了极高的性能
• 另外,多级缓存机制，确保了不会针对内存数据结构发生频繁的读写并发冲突操做，进一步提高性能。

上述就是Spring Cloud架构中，Eureka做为微服务注册中心能够承载大规模系统天天千万级访问量的原理。

推荐一个学习圈子：697-57-9-751 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多