Software Architect · 模块 13
Performance 不是一种感觉，不是觉得代码跑得快。它是可测量的目标、profiling，以及为优化付出的明确代价。
Latency · throughput · profiling · caching · budget
要优化的是 bottleneck，而不是看起来不顺眼的地方。
Latency 与 throughput 是两件事
出租车能把一个人快速送到。地铁则能运送上千人。用同一个"快"字去比较它们毫无意义。
Latency 是一次操作的响应时间。Throughput 是系统在一段时间内处理的操作数量。你可以降低单个请求的 latency，却让系统整体的 throughput 变差——比如不加资源控制地激进 parallelism。
架构师必须把 performance requirement 说得具体：p95 response time、p99 tail latency、requests per second、batch duration、cold start、memory budget。"应该快一点"不是一条需求。
缓存意味着对 staleness 负责
橱窗里贴出的菜单只要和收银台的价格一致就有用。一旦不一致，它就变成争吵的来源。
Caching 能加速读取，但同时引入 invalidation、TTL、consistency model 与 stale data 的风险。在加缓存之前要先问：到底什么操作昂贵，它多久变化一次，是否可以展示过期值，source of truth 变化时如何使缓存失效。
不理解数据模型就加缓存很危险：你可能只是更快地返回了错误答案。
好的优化以测量开始，以验证结果结束。
例子：通过 profiling 解决慢 endpoint
医生先下诊断，而不是因为病人说"哪里痛"就直接做手术。
/dashboard endpoint 的 p95 是 2.8 秒。Tracing 显示 80% 的时间消耗在 N+1 数据库查询，以及缺失 workspace_id, created_at 索引上。团队加上 eager loading、索引和一个 performance test。
结果：p95 降到 380 ms。修复是精准的、可测量的，且没有引入额外的架构复杂度。
反例：没有 profile 就改写成 Go
如果路被封了车堵在路上，换发动机毫无意义。
团队决定把服务改写成另一种语言，理由是"Python 慢"。后来发现 90% 的时间花在外部 API 和设计糟糕的 SQL 查询上。
语言可以是 bottleneck，但需要证明。否则优化就变成一次昂贵的 refactor，对业务没有任何影响。
- 这里真正重要的 performance 指标是哪一个？- 根据 profiler/tracing，bottleneck 在哪里？- 可以接受的 budget 是多少？- 加上缓存后什么会坏掉？