January 28th, 2026

更多算力并不能替代系统架构

作者：Uwe Jesgarz，Kithara Software 总经理
 

当技术系统接近其性能极限时，人们通常会做出同样的反应： 更换为更快的硬件。更多内核、更高主频、更强大的加速器。这一决定看似理性、可量化，而且相对容易实施。 

然而，在许多情况下，这种做法依然是错误的。 

这并不是因为算力不重要，而是因为它常常被当作某种无法事后补救之物的替代品：一种清晰且经过系统化设计的结构。

性能是一种资源——架构是一项决策

算力是一种资源，类似于内存容量或存储空间。相比之下，系统架构是一项从根本上决定系统如何运行的关键决策。资源可以扩展；架构则无法随意扩展——至少事后无法做到，而且必然伴随代价。一个普遍存在的误区正源于此：认为增加性能可以弥补结构性缺陷。短期内或许有效，但从长期来看往往会加剧问题。算力并不能消除结构上的混乱——它只会将其掩盖。

失控的并发仍然是失控的

现代系统几乎都是并发的。多个任务同时运行，共享状态，并对时间顺序并非确定的事件作出响应。这种并发并非由硬件本身产生，而是源于设计决策。如果这些决策并非有意识地做出，而是偶然形成，那么系统就失去了控制。

如果缺乏对所有流程的明确时间结构，系统行为就会变得隐含、模糊且未定义。依赖关系不清晰，状态未被明确界定，状态转换缺乏控制。结论很明确：失控的并发仍然是失控的——无论硬件运行得多快。

更高的性能，只会让系统更快地经历这种混乱。

为何这种误区在当下尤为常见

现代平台强化了这种误解。性能不断提升的多核处理器、云基础设施以及可扩展的运行环境，使人产生性能几乎无限可用的印象。当系统达到极限时，人们选择扩展——无论是纵向还是横向扩展。这种方式很方便——却推迟了对根本问题的正视。

算力越容易获得，人们就越少去思考系统为何需要如此之多的算力。结构性问题被搁置，因为表面症状暂时消失。然而，问题并未真正解决，只是变得不那么明显。

当错误变得更少，却代价更高

一个结构混乱的系统并不会立即暴露其弱点。尤其在实验环境或中等负载下，它可能在相当长时间内看起来稳定。问题往往在之后才显现：

• 在特定负载条件下
• 在罕见的状态组合中
• 在现场环境，而非测试环境中

此时，这些问题往往：

• 难以复现
• 难以解释
• 分析成本高昂

系统看似可靠…直到它不再可靠。

速度提升的是吞吐量，而非控制力

一个常见的误解，是将速度等同于控制力。算力和速度可以提高吞吐量，却无法提升可预测性。

系统不会因为性能更强而变得更具确定性。它只是以更高的速度变得不确定。时间相关的错误并不会消失，而是从统计上变得更少，却因此更加危险。一旦问题真正发生，排查和定位可能会耗费数周甚至数月的人力。一个缺乏时间秩序却运行迅速的系统，并非高性能系统，而是一个高风险系统。

那个很少被提出的问题

在许多项目中，人们会反复讨论需要多少算力。却很少有人追问：系统必须满足哪些时间保证？然而，这正是决定性的关键问题：

• 什么事情可以发生？何时发生？
• 哪些状态是有效的——以及持续多久？
• 哪些事件具有优先级？
• 整个项目由哪些子系统构成？
• 它们之间如何相互作用？

这些问题无法通过更快的硬件或编译器优化来回答。项目的架构，始于做出明确决策的那一刻。

衡量进步的另一种标准

技术进步常被理解为提升：更快、更大、更并行。但对于复杂系统而言，这样的衡量标准并不充分。真正先进的系统应当：

• 保持可解释性
• 具备可重复的响应行为
• 在负载下仍然可预测

试图用算力压制问题，意味着放弃对系统的理解。而没有理解，就没有控制。