• 博客园logo
  • 会员
  • 众包
  • 新闻
  • 博问
  • 闪存
  • 赞助商
  • HarmonyOS
  • Chat2DB
    • 搜索
      所有博客
    • 搜索
      当前博客
  • 写随笔 我的博客 短消息 简洁模式
    用户头像
    我的博客 我的园子 账号设置 会员中心 简洁模式 ... 退出登录
    注册 登录
Spillage
博客园    首页    新随笔    联系   管理    订阅  订阅
Eureka server压测分析

    前提,公司最近在做网关重构,并决定所有服务使用同一个eureka server集群,为此需求对eureka server做一次负载测试,分析eureka server cluster能否承受所有服务的心跳,注册机获取服务列表的请求。

    查了一下springcloud.cn上的文章,发现宜信工程师已经做了类似的eureka server的压测,不过目的和我司不一样。为了确认eureka server集群可以管理我司所有微服务,有必要进行专门的负载测试进行验证。首先是准备工作:

    Eureka server和 Eureka client的通信机制是什么?HTTP 协议。

    Eureka 在逻辑上可以分为3个角色

    Eureka Server, Eureka Client Consumer, Eureka Client Provider

    此处参考我司许进大神的文章即可:http://springcloud.cn/view/31

    然而,为什么不能直接使用大神的测试结果?

    原因如下:

    大神的测试报告中,是针对单机进行测试,且Server端单机的配置-XX:MaxHeapSize=4g(默认) 是比较好的配置了,我们的实际测试过程中是5台2c4g的机器组成Eureka server cluster进行测试,我们的目的是多大的集群,心跳上报间隔是多少(默认为30s,实际在生产上不建议使用默认值,在使用发布系统发布的时候如果采用30s的默认值可能导致部分流量流入不该进入的节点)可以支撑起全公司的微服务治理。

    基于这样的逻辑,我设计了符合我们公司的服务治理的压测逻辑:

    

 

    初始化1000个线程,每个线程可视为一个instance 与 Eureka server通信,用于注册,心跳上报及获取服务列表。统计qps并不是我们的目标,因此不需要任何压测工具参与这件事情,实际上,判断Eureka Server cluster能否治理这么多实例,才是我们的目标。如何衡量?观察response的status_code, 以及eureka server机器的监控即可。

    事实证明,在5s及10s间隔下,4台2c4g的机器维持1000个instance的服务还是勉强了点,所有CPU达到98%。。。

 

posted on 2019-07-15 15:46  Spillage  阅读(551)  评论(2)    收藏  举报
刷新页面返回顶部
博客园  ©  2004-2025
浙公网安备 33010602011771号 浙ICP备2021040463号-3