增加了一行代码，让我们提高了 3000% 的性能-技术圈

作者｜ Itamar Lechowicer

来源｜ InfoQ 译者｜许学文

策划｜ Tina 审校｜王强

本文最初发布于 Itamar Lechowicer 博客，经原作者授权由 InfoQ 中文站翻译并分享

概述

我们公司运维着 15 个 Web 应用，主要的工作就是按需交付基于数据驱动的 Web 应用程序，用于支撑实时决策的制定。

这些应用的预期是在高负载下依然保持高可用。其中的主 Web 应用是一个历史遗留的大型多服务系统。系统中的大部分服务都有超过 15 年的历史并且经过了好几代人的重构。试想一下，负责编写系统代码的人现在可能已经离职或已经调整到其他岗位了。

过去几年我们团队的主要目标是就是针对这些服务进行性能优化。本次我将和你分享在性能优化的过程中，我们的一些主要经验总结和当时决定这么做的原因。

认知改变时刻

总结一：不要使用平均等待时长作为衡量服务负载的指标——核查应用的“尾部”值

总结二：在性能优化上投入时间、工具和人力

要保持应用的高性能，我们必须具备以下条件：

负载测试和负载场景——具备可用的负载测试和负载场景非常重要。
应用监控工具（APM）——诸如 Dyanatrace，AppDynamics 和 Epsagon 等工具。APM 在监控服务上可以帮我们节约大量的时间。因此在生产环境安装至少一个 APM 是非常有必要的。
有效的日志——有效的日志是生产服务中断调查和性能问题调查的基本条件。因此你必须确保应用的日志是清晰且有用的。
日志分析工具——你不能从很多文件中读取和搜索日志，尤其当你的服务是集群的时候，通过文件读取日志将变得更加困难。因此，花时间投产一个诸如 ELK，Grafana 或 Splunk 的日志收集器和分析工具是非常有必要的。
专业的人力支撑——对于上面提到的知识或者工具，如果你的团队没有相关的专业人才，那么你将什么也干不了。

因此，针对复杂的系统，我建议投入专门的人和时间来处理。（例如，SRE 团队就能很好的胜任此项工作）

总结三：老系统将会消亡（除非我们激活它们）

结论四：每一行代码都很重要

有时，当我们在编写代码的时候，我们可能会忘记这些代码最终运行将在生产环境中，并为一个真实用户的真实工作服务。上面提到的我们亲身经历的案例中，仅仅只是因为程序员忘记了释放 DB 连接（一行代码而已），就可以干扰一个用户的正常工作（那些工作受影响的用户估计很不愿意给我们付钱）。

我的建议是：

想象一下（虽然很难），在世界的另一端，某个用户的工作完全依赖你编写的代码，同时试想一下，你写的每一行代码都将影响其使用应用的体验。

在 CI 或者 CD 环节执行负载测试。如果你想确保代码高可用，那么就针对每个即将投产的 PR 或版本都进行负载测试。

当你发现性能问题的时候，请怀疑每一行代码——据我们的经验，代码中的每个字符都有可能是导致性能的瓶颈。