概述

我们公司运维着 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(平均修复时间)上升了。

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