保障服务性能，除了压测我们还能做些什么

前言

在保障服务性能的时候，发现除了传统的通过压测发现后台接口性能问题，确保足够的容量供服务使用以外，还需要做许多事情，才能来确保服务的性能达标万无一失。

压测是如何保证服务性能的

首先，服务性能怎么算达标？我在这里简单归结为，时延在可接受的范围且服务正常可用。时延是用户直接感知的，如果接口响应时间非常长，那么体验就会变得非常糟糕，这显然是不可接受的。服务正常可用，指的是即使在预料之外的大压力下，接口仍能承载得住，不出现崩溃情况。因为就算你的接口性能再好，服务不正常也是毫无意义的。

基于上面对性能达标的定义，你会发现对接口进行压测，无疑是达到上述目的的最佳方案。首先，可以通过对接口的预估，制定一个容量目标，然后对这个目标进行优化，反复测试以达到在相应的容量下，接口时延在可接受的范围且服务正常可用。

压测局限性在哪里

在保障工作中，发现压测对于确保服务性能有着一定的局限性，主要表现在下面几点：

1、后台接口响应时间 ≠ 用户感知到的反应时间

接口压测只针对接口进行压测，往往跟用户感知到的页面响应时间是不等同的。最突出的问题是，展示给用户的页面需要进行资源加载和渲染，而如果资源使用不当或者渲染策略不合理，往往会导致非常糟糕的用户体验，尽管你的接口响应时间是多么地快。

2、接口容量预估无法预料所有突发情况

除了无法确保用户的实际体验以外，如果只凭压测去确保接口能够达到某一个容量，而不管接口是否拥有扩容的能力，这样也无法去应对突发情况的来临。

更为完善的保障手段

结合上面的局限性，在实践当中，加入了下面几项保障手段，来确保服务的性能是可靠的。

1. 结合Lighthouse

Lighthouse是Chrome浏览器的一个用于检查页面是否存在性能问题的工具，工具非常简单易用，而且也是确实能够发现问题的。

我这里的建议是，可以把Performance这项优化到绿色作为页面性能优化的目标。而这里的Lighthouse的建议和修改Demo一应俱全，这里也就不赘述了。

这里结合生态大会的案例，汇总了当时遇到的一些问题。除了Lighthouse的建议，也可以考虑下下面几项，是否存在类似的可以优化的空间：

• 保证清晰度的前提下，尽可能压缩图片
• 如果能够容忍一定的播放失败，建议使用mpeg替代GIF；如果需要保证播放100%成功，使用GIF也需要在保障清晰的前提下，尽可能压缩资源
• 主框架的资源单独打包，独立且最优先加载。这样能够保证在弱网环境下，能够先加载出网页的框架，缓解用户焦虑。
• 使用gzip压缩map文件等

2. 扩容与监控

为了应对可能发生的突发流量，必须保证接口是拥有扩容的能力的。关于扩容有几个关键的要点需要注意：

1. 对接口有合理的预估 扩容的前提，是你应该对你的接口有一个大致的访问量的评估。如果大致的评估都做不到，也无法谈论扩容。毕竟如果连数量级都对不上的话，临时扩一个数据级的容量，估计连代码框架都无法支撑。对于接口预估，还是推荐看看之前的文章 如何去做接口容量预估 。
2. 具备监控接口的能力 扩容还有一点比较重要的是，需要具备监控能力，监控数据的走向，在出现较大的增长趋势之前，就需要马上动手去做了。这里建议的是使用Grafana去读取云服务和网关的数据，进行展示。

1. 确保接口均可扩容并且对其进行演练验证

接口并不是全都具备扩容能力的，比如一些依赖外部接口的接口，如果外部接口无法配套扩容，那么这些接口就无法真正做到扩容。对于这些接口，建议采取兜底策略，比如异步队列处理。

3. 故障演练

除了接口的异常以外，对于大型项目，往往不能忽略的是集群和机器本身的异常。对于这种故障的预防，其实公司内外都有比较好的工具可以利用。比如Chaos Mesh。利用这些工具，可以提前对系统进行故障的演练，发现问题进行兜底预防。