【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？

欢迎关注头条号：石杉的架构笔记

每周一至周五早八点半！精品技术文章准时送上！！

往期文章

1.拜托！面试请不要再问我Spring Cloud底层原理！

 

 

目录：

一、问题起源

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

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

四、总结

---

一、问题起源

 

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

之前不少初学Spring Cloud的朋友在落地公司的生产环境部署时，经常会有一个疑问：Eureka Server到底要部署几台机器？

我们的系统那么多服务，到底会对Eureka Server产生多大的访问压力？Eureka Server能不能抗住一个大型系统的访问压力？

你现在心里一定很多疑问，别着急，咱们这就去探索一下，Eureka作为微服务注册中心的核心原理。下面这些问题，大伙儿先看看，有个大概的印象。

 

带着这些问题，来看后面的内容，效果更佳。

● Eureka注册中心使用什么样的方式来储存各个服务注册时发送过来的机器地址和端口号？

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

● 各个服务是如何拉取注册表的？

● 对于一个有几百个服务，部署上千台机器的大型分布式系统来说，这套系统会对Eureka Server造成多大的访问压力？

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

 

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

 

举个例子：

● 库存服务原本部署在1台机器上，现在扩容了，部署到了3台机器，并且均注册到了Eureka Server上。

● 然后订单服务的Eureka Client会每隔30秒去找Eureka Server拉取