SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)

前言

本文是《SpringCloud 应用在 Kubernetes 上的最佳实践》的第11期,从前面两期开始我们进入到了高可用专题,分别介绍了流量防护和故障演练相关内容。本文将从另一个视角介绍如何保障业务高可用性:即业务准备阶段,提前进行线上的瓶颈定位和容量评估,以便更低成本、更高效/真实的发现系统瓶颈点,做到最精确的容量评估。

高可用体系介绍

首先来介绍下高可用体系,应用生命周期的高可用都有哪些策略、分别可以实现什么能力呢?

SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)
SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)


从上图示意中可以看出,应用生命周期的整个过程中,都有响应的高可用策略,如前面2期介绍的 流量防护即为线上运行时的线上管控相关策略,混沌工程即为系统演练的相关策略。而全链路压测即为规划阶段的重要策略,其包括线上压测(即环境选择)、容量规划(即压测实施)、弹性伸缩(即生态内联动)。
以下将重点介绍容量评估的重要性,以及如何实施压测来实现容量评估。

为何要进行容量评估

关于容量评估的重要性及必要性已经是个老生常谈的问题了,分别从技术角度和业务战略角度总结如下:

SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)


容量评估的目的自然是解决容量问题,如新业务上线前的准备,大型营销活动的准备等等。大型活动中洪峰流量引起的系统表现不确定性,是最经典的适用场景。一个理想的营销活动周期应该是有如下闭环流程:

SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)

性能测试是容量评估的核心手段,性能测试之后通过客户端-应用系统-基础负载一系列的监控分析,最终可得出瓶颈点位于何处、应如何有针对性的优化。上图可以看出,性能测试通过真实、高效的压测方式进行容量评估/瓶颈定位&解决,最终来保障活动稳定进行。

如何进行性能测试

阿里巴巴全链路压测从2013年到现在也已经是第7个年头了,在这7年中间我们不断的积累、总结、优化进步,进行这样一种大规模的项目活动,离不开有效的流程把控及分工管理。关于全链路压测的前期准备,这边将不做赘述,有兴趣的同学可以参考文章《独家揭秘 | 阿里巴巴是如何做全链路压测的?》。以下将重点介绍压测执行阶段操作。
进行全链路压测之前,单应用会进行内部压测,以便能提升全链路压测的效率,即解决内部问题之后再解决联动问题。故以下将分别介绍Spring Cloud应用的压测以及全链路压测分别如何执行。

单应用压测Spring Cloud应用

单应用的压测不少开发者会选择开源JMeter进行压测,甚至还会进行自建平台以便实现高并发能力。这两者都不推荐,他们都有较为明显的劣势。阿里云性能测试服务(PTS Performance Testing Service)提供了云端压测服务,其完美兼容了JMeter,只需把脚本上传上来即可发起压测。

SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)


同时,目前PTS上已经支持直接进行微服务压测,不需要自己设置进行插件管理和升级,只需直接在PTS中选择对应的集群等信息,即可快速发起压测。

SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)

全链路压测

如前面介绍性能压测流程中所属,整个全链路压测包括的前期事宜较多,如环境选择与改造、数据准备、安全策略等,这部分内容在此不做赘述,有兴趣的可以查阅《Performance Test Together》主题相关介绍。本处主要介绍全链路压测的实施:即配置与线上业务模型一样的业务场景,从公网发起真实流量进行多维度和场景的压测,验证容量能力和瓶颈问题的定位。
一般正式压测会按照压测计划,执行多种压测策略。淘宝的双11大促压测,一般包含这样几步:

  • 峰值脉冲
    即完全模拟0点大促目标峰值流量,进行大促态压测,观察系统表现。
  • 系统摸高
    取消限流降级保护功能,抬高当前压测值(前提是当前的目标压测值已经达到,则可以进行摸高测试),观察系统的极限值是多少。可进行多轮提升压力值压测,直到系统出现异常为止。简化摸高测试的提升信息
  • 限流降级验证
    顾名思义,即验证限流降级保护功能是否正常。修改限流降级的作用与验证方法,更简化。 (AHAS引入)商业化产品AHAS(应用高可用服务,Application High Availability Service)提供了全面的限流降级能力,可进行全链路的降级保护。
  • 破坏性测试
    这个主要是为了验证预案的有效性,类似于容灾演练时的预案执行演练。即为持续保持大促态压测,并验证预案的有效性,观察执行预案之后对系统的影响。修改破坏性测试的内容。

在PTS上压测

上述压测场景的实施,均可以在PTS上操作实现,且配置不同的压测量级数据,来进行多轮压测,并观察其系统表现。压测不应该是一次性的操作,而应该是反复的、多轮验证的操作。以下以峰值脉冲为例,介绍如何在PTS上实施压测。
首先是场景的构建。PTS提供了丰富的创建场景方式,包括JSON、JMX、YAML脚本的导入,纯交互0编码UI创建、云端录制器录制结果导入、完美兼容JMeter脚本等。下图作为示例:

SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)


业务场景构建完成之后,以PTS自研原生引擎(即纯交互UI编排模型)为例,提供了丰富的压力来源定制化能力,可实现多地域/运营商的来源定制,更真实地模拟真实流量情况。

SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)


同时,可通过SLA + 定时任务能力,实现“无人值守”压测,对核心业务链路进行周期性的性能摸顶。

SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)


压测结束后,PTS提供了可下载的压测报告,有详细统计数据及趋势图数据,采样日志以及添加了的监控数据,可快速进行问题方向的定位于分析。

在EDAS上压测Spring Cloud应用

EDAS 的微服务治理能力,同时打通了与 PTS 服务的相应的压测能力,进入到服务查询页面之后点击压测按钮即可开始在 PTS 的性能测试,如下图:

SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)

结尾

本文简单介绍了下业务高可用体系的相关策略,容量评估的重要性以及核心手段-性能测试的实施方式,同时在Spring Cloud下的快速应用。此外,PTS 还提供了更多功能:

  • 全链路压测的流量隔离改造
  • JMeter的环境管理及本地化插件
  • 压测过程中,云上业务的架构监控
  • JMeter的高级流量定制
  • ......

以性能压测为主线,进行应用系统规划期的容量验证,并以压测数据结果为参考,通过应用高可用服务AHAS中流量防护进行从网关到应用多维度的系统防护,以此来实现业务系统上线后的高可用性。后续PTS和AHAS会提供更多的智能化功能,来更好地帮助实现线上业务在各种极端场景下的连续性。

上一篇:《跨境电商——速卖通搜索排名规则解析与SEO技术》一一1.1 初识速卖通的搜索引擎


下一篇:【购买老域名】老域名对于网站SEO的价值