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

点击关注 👉 Java架构师技术 2022-07-01

收录于合集 #Java架构师技术 217个

以下文章来源Java架构师技术，回复”Spring“获惊喜礼包

上一篇推文：编写 if 时尽量不要带 else

大家好，我是Java架构师

作者｜ Itamar Lechowicer

来源｜ InfoQ 译者｜许学文

策划｜ Tina 审校｜王强

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

概述

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

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

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

认知改变时刻

在某次事件中，用户增加了对我们应用的使用率，导致我们应用的数据流量大幅增加。在此事件过程中，用户抱怨我们的应用性能实在太差，以至于无法在应用上完成全套的业务流程。为此，我们开始利用监控工具分析应用的性能瓶颈。通过应用监控工具，我们发现服务在获取 DB 连接上消耗了 90% 的响应时间。

但是 DB 看上去一切正常，所以，我们开始分析应用的 DB 连接池。分析发现，所有的 pod 将连接池中全部可用的连接都使用了。因此我们猜测服务在关闭连接上可能有问题。于是，我们花了几个小时时间检查代码，尝试找到连接没有被释放的地方。最终，我们的一个 TeamLeader 发现，pod 的存活探针在做一次简单的 DB 心跳请求之后没有释放 DB 连接。随后，我们立即在 pod 存活探针的请求中增加了一行用于释放 DB 连接的代码。影响是可怕的。眨眼间，应用的性能就开始稳定下来并且用户也恢复了正常使用。

就在此次事件的前一天，我们才执行过一次负载测试，以确保应用程序能够承受预期的使用量增长，测试结果表明应用的性能是在正常范围内的。然而事实证明这个测试结论是错误的，错误的测试结论误导我们以为应用程序没有需要修复的问题。我们深刻认识到了错误，我们需要做得更好。以下是我们在此次事件中学习到的一些经验和总结。

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

当用户抱怨应用响应慢的时候，我们发现平均等待时长指标并没有明显的变化。当我们回顾了这些指标数据的时候，注意到了一些有趣的事情：之前我们是将平均请求时间作为服务等待的主要指标。

因此，这次我们将 90% 请求等待时长的数据做了一个图表，看看这个图表能不能反馈些信息。果不其然，在用户抱怨应用慢的时候，我们观察到图表中等待时长急剧增加。

平均等待时长指标之所以没有明显变化，是因为太多的快速请求将平均值拉下来了。所以我的建议是，不使用平均等待时长，而使用 50%，90%，95%，99% 的平均等待时长作为服务响应的指标。核查那些远远超过正常值范围的“尾部”值是非常重要的。

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

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

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

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

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

作为人类，我们都有创造新事物的冲动和欲望，并且对创造出来的产品有一种所有权感。在软件的世界里，在我们需要处理的矛盾中，有时候也会包含这样的矛盾。一方面，有一个老系统需要我们维护；而另一方面，有一个炫酷的新系统我们想要去开发。

那么这个时候，我们就需要决定将时间投入到那块。当我们面对这样的矛盾时，我们必须记住，如果我们不继续在老系统上进行开发和添加新功能，那么对老系统的了解会随着时间的推移而消失。

因此，当我们面对系统故障或客户新需求时，由于缺少对老系统的了解或者能力问题，将无法达成目标。换句话说，当我们失去对于老系统的了解之后，系统的 MTTR(平均修复时间) 上升了。

因此，我的建议是，要时常克制想要创造一个新的、炫酷事物的冲动，将时间投入到对老维护系统的熟悉和提升解决问题的能力上。另外，保持对老系统熟悉度的最佳方式就是尝试在老系统中添加代码。

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

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

我的建议是：

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

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

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