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

头图.png

作者 | 牛兔

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

高可用体系介绍

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

1.png

2.png

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

以下将重点介绍容量评估的重要性,以及如何实施压测来实现容量评估。

为何要进行容量评估?

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

3.png

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

4.png

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

如何进行性能测试?

阿里巴巴全链路压测从 2013 年到现在也已经是第 7 个年头了,在这 7 年间我们不断积累、总结、优化进步,进行这样一种大规模的项目活动,离不开有效的流程把控及分工管理。关于全链路压测的前期准备,这边将不做赘述,有兴趣的同学可以参考文章《独家揭秘 | 阿里怎么做 双11 全链路压测?》。以下将重点介绍压测执行阶段操作。

进行全链路压测之前,单应用会进行内部压测,以便能提升全链路压测的效率,即解决内部问题之后再解决联动问题。故以下将分别介绍 Spring Cloud 应用的压测以及全链路压测分别如何执行。

1. 单应用压测 Spring Cloud 应用

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

5.png

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

6.png

2. 全链路压测

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

一般正式压测会按照压测计划,执行多种压测策略。淘宝的 双11 大促压测,一般包含这样几步:

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

3. 在 PTS 上压测

上述压测场景的实施,均可以在 PTS 上操作实现,且配置不同的压测量级数据,来进行多轮压测,并观察其系统表现。压测不应该是一次性的操作,而应该是反复的、多轮验证的操作。以下以峰值脉冲为例,介绍如何在 PTS 上实施压测。

首先是场景的构建。PTS 提供了丰富的创建场景方式,包括 JSON、JMX、YAML 脚本的导入,纯交互 0 编码 UI 创建、云端录制器录制结果导入、完美兼容 JMeter 脚本等。下图作为示例:

7.png

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

8.png

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

9.png

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

4. 在 EDAS 上压测 Spring Cloud 应用

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

10.png

结尾

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

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

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

相关文章推荐:

 

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录