大家好,这是全链路压测系列的第十三篇文章,也是倒数第二篇文章。
前面用了很多篇幅介绍了包括全链路压测的调研验证、落地实践前的准备工作细节、以及线上压测的一些注意事项。到了这里基本上技术实践的东西就讲完了,这篇文章,我想和大家聊聊,关于性能优化和高可用,我的一些理解。
开始聊之前,我想回到写这个系列文章的开头,先聊聊全链路压测出现的原因和本质。
基于实际的生产业务场景和系统环境,模拟海量的用户请求和数据,对整个业务链路进行各种场景的测试验证,持续发现并进行瓶颈调优,保障系统稳定性的一个技术工程。
业务场景复杂化、海量数据冲击下,发现并解决业务系统的可用性、扩展性以及容错性问题。
聊完了上面关于全链路压测的本质和目的、价值以及一些常见的理解误区之后,接下来我们谈谈关于服务高可用和性能优化的一些内容。
系统高可用和性能优化一直是技术领域热门的一个话题,无论是三高(高性能、高可用、高稳定),还是CAP(数据一致性、服务可用性、分区容错性),都强调了服务的性能和可用。
可用是一个名词,简单来讲就是系统既有的功能能否正常为用户提供服务;可用性是一个形容词,即系统的可用在某种评估标准下能得多少分。那么如何衡量可用性?目前业内大多从下面几点指标来评估:
服务可用时常即我们常说的SLA(即服务等级协议,全称:service level agreement)。SLA对互联网公司来说就是网站服务可用性的一个保证。9越多代表全年服务可用时间越长服务更可靠,停机时间越短,反之亦然。服务可用性指标可以通过下面的例子来理解:
全年以365天做计算,看看几个9要停机多久时间才能达到! 1年 = 365天 = 8760小时; 99.9% = 8760 * 0.1% = 8760 * 0.001 = 8.76小时; 99.99%= 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟; 99.999% = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟;
当然,服务可用时长还要区分核心业务和非核心业务,不同的业务造成的不可用影响程度也是不同的。
这一点目前业内有个口号是:1-5-15。什么意思呢,就是:一分钟发现问题,5分钟定位问题,15分钟解决问题,线上业务恢复正常运营。要做到上述的指标需要很强的技术能力以及不断的演练才能达到,主要是如下几点:
这一点很好理解,即线上故障对业务造成的损失。这一点业内在故障定级评估复盘时,大多采用最近一天/一周同时段的业务营收来做对比,当然,其中还可能包括用户的客诉以及赔偿的成本支出等维度。
PS:注意!无论是限流还是降级以及熔断和隔离,本质上对业务都是有损的。即在尽可能保障服务可用的情况下提供业务可用,保障业务目标的达成。这是一个需要不断验证和评估投入产出比的过程。
聊完了高可用,接下来聊聊性能优化。
在保持和降低系统99%RT的前提下,不断提高系统吞吐量,提高流量高峰时期的服务可用性。
PS:三者关系在某些场景下互相矛盾冲突,不可兼得!
首先要声明一点:性能优化没有边际,随着优化的范围越大细节越深,要投入的成本和精力就越大。而且在实际工作中,很多时候是没有太多时间让我们去做细致的分析优化的。特别是在版本迭代业务交付deadline、倒排期情况下,按时交付往往是第一优先级。
我并不是提倡大家不注重系统性能的表现和优化,而是想说明一点:性能优化的成本和及时交付带来的业务价值之间需要做评估和平衡。
而且现在各种技术框架工具以及编码规范和测试验证的最佳实践不断涌现,在更重要的价值面前,要做到性能优化实际上是很简单的事情,就是下面的性能优化三板斧: