什么是性能工程：Gatling视角

Source: Dev.to

现代性能工程：为什么大多数团队没有性能问题——而是有架构问题

如果你花足够的时间与工程团队相处，你会开始注意到一种奇怪的脱节。系统在孤立的分支上构建，并在受控的预发布环境中测试，然后在祈祷和乐观的仪表盘下部署。

随后，它们被期望能够承受真实用户的混乱、不可预测的流量以及与预发布环境截然不同的生产环境。大多数团队并非缺乏专业知识或努力——而是缺乏一种真实了解系统在实际性能条件下表现的方式。

性能工程本应弥合这一鸿沟。但在许多组织中，性能只有在生产环境出现卡顿时才被提及。到那时，系统已经在挣扎，仪表盘响起警报，所有人都在诊断症状而不是了解根本原因。

这时通常会有人问：“我们不是已经做过负载测试了吗？”

于是我们的故事就此开始。

负载测试通过却仍然崩溃的夜晚

那是一个典型的发布之夜——一种没人会承认紧张的夜晚，直到出现问题。团队做了他们认为合适的性能测试：编写负载测试，在预发布环境执行，审查性能指标，未发现任何异常。图表保持平稳，延迟表现正常，环境看起来很平静。绿色仪表盘带来一种安慰的幻觉。

但预发布环境往往是礼貌的骗子。

部署后一小时内，生产环境表现出不同的情况。响应时间开始慢慢上升，随后急剧增长。错误率出现。API 客户端遭遇意外超时。团队围在监视器前，试图解释发生了什么。最初的怀疑显而易见：负载测试一定遗漏了什么。“但它昨天已经通过了，”有人说，好像通过性能测试就能保证系统在真实工作负载下的表现。

问题不在于测试本身，而在于其背后的假设。负载测试没有模拟真实的并发模式。它没有反映实际的数据量。它也没有考虑到一个下游依赖，在预发布环境表现良好，却在生产条件下崩溃。测试本身并没有错；只是它没有被设计成能够暴露系统固有的性能瓶颈。

这不是负载问题，而是一个架构问题，只是负载测试仅部分揭示了它。

什么是性能工程？（开发者视角）

性能工程 常以模糊或学术的方式定义，但其核心是设计、验证和改进系统的实践，使其在真实环境下