一次全面的性能优化，从5秒优化到1秒

前言

性能优化，有时候看起来是一个比较虚的技术需求。除非代码慢的已经让人无法忍受，否则，很少有公司会有觉悟投入资源去做这些工作。

即使你有了性能指标数据，也很难说服领导做一个由耗时 300ms 降低到 150ms 的改进，因为它没有业务价值。

这很让人伤心，但这是悲催的现实。

性能优化，通常由有技术追求的人发起，根据观测指标进行的正向优化。他们通常具有工匠精神，对每一毫秒的耗时都吹毛求疵，力求完美。当然，前提是你得有时间。

正文

优化背景和目标

我们本次的性能优化，就是由于达到了无法忍受的程度，才进行的优化工作，属于事后补救，问题驱动的方式。这通常没什么问题，毕竟业务第一嘛，迭代在填坑中进行。

先说背景。本次要优化的服务，请求响应时间十分的不稳定。随着数据量的增加，大部分请求，要耗时 5-6 秒左右！超出了常人能忍受的范围。

当然需要优化。

为了说明要优化的目标，我大体画了一下它的拓扑结构。如图所示，这是一套微服务架构的服务。

其中，我们优化的目标，就处于一个比较靠上游的服务。它需要通过 Feign 接口，调用下游非常多的服务提供者，获取数据后进行聚合拼接，最终通过 zuul 网关和 nginx，来发送到浏览器客户端。

为了观测服务之间的调用关系和监控数据，我们接入了 Skywalking 调用链平台和 Prometheus 监控平台，收集重要的数据以便能够进行优化决策。

要进行优化之前，我们需要首先看一下优化需要参考的两个技术指标：
吞吐量：单位时间内发生的次数。比如 QPS、TPS、HPS 等。
平均响应时间：每个请求的平均耗时。

平均响应时间自然是越小越好，它越小，吞吐量越高。吞吐量的增加还可以合理利用多核，通过并行度增加单位时间内的发生次数。

我们本次优化的目标，就是减少某些接口的平均响应时间，降低到 1 秒以内；增加吞吐量，也就是提高 QPS，让单实例系统能够承接更多的并发请求。

通过压缩让耗时急剧减少

我想要先介绍让系统飞起来最重要的一个优化手段：压缩。

通过在 chrome 的 inspect 中查看请求的数据，我们发现一个关键的请求接口，每次要传输大约 10MB 的数据。这得塞了多少东西。

这么大的数据，光下载就需要耗费大量时间。如下图所示，是我请求 juejin 主页的某一个请求，其中的 content download，就代表了数据在网络上的传输时间。如果用户的带宽非常慢，那么这个请求的耗时，将会是非常长的。

为了减少数据在网络上的传输时间，可以启用 gzip 压缩。gzip 压缩是属于时间换空间的做法。

对于大多数服务来说，最后一环是 nginx，大多数人都会在 nginx 这一层去做压缩。

它的主要配置如下：

gzip on;
gzip_vary on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
gzip_disable "MSIE [1-6]\.";

压缩率有多惊人呢？我们可以看一下这张截图。可以看到，数据压缩后，由 8.95MB 缩减到了 368KB！瞬间就能够被浏览器下载下来。