微服务注册中心如何承载大型系统的千万级访问?

标签: tuicool | 发表时间:2018-12-25 00:00 | 作者:
出处:http://itindex.net/relian

点击上方 " 石杉的架构笔记",右上角选择“设为星标”

周一到周五早8点,精品技术文章准时送上!

目录:

一、问题起源

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

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

四、总结

一、问题起源

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,那么就说明这个服务实例已经挂了。

光看上面的文字,大家可能没什么印象。老规矩!咱们还是来一张图,一起来直观的感受一下这个过程。

二、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源码里一探究竟:

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

  • 从代码中可以看到,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,里面则会维护每个服务 最近一次发送心跳的时间

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

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

  • 根据之前的测试,单台4核8G的机器,处理纯内存操作,哪怕加上一些网络的开销,每秒处理几百请求也是轻松加愉快的。

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

  • 在拉取注册表的时候:

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

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

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

  • 在注册表发生变更的时候:

    • 会在内存中更新变更的注册表数据,同时 过期掉ReadWriteCacheMap

    • 此过程不会影响ReadOnlyCacheMap提供人家查询注册表。

    • 一段时间内(默认30秒),各服务拉取注册表会直接读ReadOnlyCacheMap

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

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

多级缓存机制的优点是什么?

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

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

为方便大家更好的理解,同样来一张图,大家跟着图再来回顾一下这整个过程:

四、总结

  • 通过上面的分析可以看到,Eureka通过设置适当的请求频率 (拉取注册表30秒间隔,发送心跳30秒间隔),可以保证一个大规模的系统每秒请求Eureka Server的次数在几百次。

  • 同时通过纯内存的注册表,保证了所有的请求都可以在内存处理,确保了极高的性能

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

上述就是Spring Cloud架构中,Eureka作为微服务注册中心可以承载大规模系统每天千万级访问量的原理。

如有收获,请帮忙转发,您的鼓励是作者最大的动力,谢谢!

一大波 微服务、分布式、高并发、高可用原创系列文章正在路上, 欢迎扫描下方二维码,持续关注:

《双1 1 背后 每秒上万并发下的Spring   Cloud参数优化实战》,敬请期待

《微服务架构如何保障双11狂欢下的99.99%高可用》,敬请期待

石杉的架构笔记(id:shishan100)

十余年BAT架构经验倾囊相授

相关 [微服务 心如 系统] 推荐:

微服务注册中心如何承载大型系统的千万级访问?

- - IT瘾-tuicool
点击上方 " 石杉的架构笔记",右上角选择“设为星标”. 周一到周五早8点,精品技术文章准时送上. 面试请不要再问我Spring Cloud底层原理》. 二、Eureka Server设计精妙的注册表存储结构. 三、Eureka Server端优秀的多级缓存机制. Spring Cloud架构体系中,Eureka是一个至关重要的组件,它扮演着微服务注册中心的角色,所有的服务注册与服务发现,都是依赖Eureka的.

微服务系统中的认证策略

- - 企业架构 - ITeye博客
软件安全本身就是个很复杂的问题,由于微服务系统中的每个服务都要处理安全问题,所以在微服务场景下会更复杂. David Borsos在最近的伦敦微服务大会上作了相关内容的演讲,并评估了四种面向微服务系统的身份验证方案. 在传统的单体架构中,单个服务保存所有的用户数据,可以校验用户,并在认证成功后创建HTTP会话.

微服务架构:如何用十步解耦你的系统?

- - 掘金后端
耦合性,是对模块间关联程度的度量. 耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少. 模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系. 模块间联系越多,其耦合性越强,同时表明其独立性越差. 软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准.

消息系统在微服务间通讯的数据一致性

- - 互联网 - ITeye博客
微服务是当下的热门话题,今天来聊下微服务中的一个敏感话题:如何保证微服务的数据一致性. 谈到分布式事务,就避免不了CAP理论. CAP理论是指对于一个分布式计算系统来说,不可能同时满足以下三点: . 一致性(Consistence) (等同于所有节点访问同一份最新的数据副本). 可用性(Availability)(对数据更新具备高可用性).

解析微服务架构(一)单块架构系统以及其面临的挑战

- - 博客园_知识库
  多年来,我们一直在技术的浪潮中乘风破浪,扬帆奋进,寻找更优秀的方法来构建IT系统,也一直在积极的学习并观察先进的公司如何以不同的架构方式构建或者优化其IT系统,来积极应对市场的变化,迅速做出响应,从而为客户提供更多的价值.   微服务架构模式(Microservice Architect Pattern)是近两年在软件架构模式领域里出现的一个新名词.

基于支付系统场景的微服务架构的分布式事务解决方案

- - 研发管理 - ITeye博客
分布式系统架构中,分布式事务问题是一个绕不过去的挑战. 而微服务架构的流行,让分布式事问题日益突出. 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析. 如上图所示,假设三大参与平台(电商平台、支付平台、银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析:.

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.