架构随业务一起成长

在中国一些最大的互联网公司工作时，我经常在会议上听到一些宏大的说法：“这项技术的最佳实践”“最优架构”，以及“下一代基础设施平台”。

那时，云服务正在逐渐普及，但我任职的公司仍然自行构建大量基础设施。它们有专门的基础设施部门，由规模庞大的团队开发和维护内部系统。

想象一下，每家大型互联网公司里都有一个小型 AWS。

其中一些系统解决了真正的问题。另一些则留下了负担，存在的时间远远超过了那些构建它们的人在公司的任期。

员工来了又走。内部政治、绩效考核和晋升要求都影响着技术决策。打造一个框架可以带来认可和影响力，而多年后维护它，却很少受到同等关注。

在一家公司，我所在部门的一位领导曾把我叫到一旁，说我的架构太注重服务业务了。他解释说，在自己的技术平台中，他刻意把不同团队的业务功能与底层基础设施耦合在一起。这样一来，这些部分就更难拆开，各个团队也会更加依赖他。

他描述的是一种有意为之的设计选择。这些依赖关系巩固了他的地位，却把它们带来的复杂性留给公司承担。

那次谈话一直留在我的记忆里。我怀疑这即便在那个部门里也不是孤例，更不用说整个行业了。

为了维护某个人地位而构建的架构，可能会让业务更难改变方向。当公司需要拆分一项服务、替换一个组件，或者停止使用某个平台时，那些刻意构建的依赖就会成为障碍。

这也是我对热衷打造内部框架的做法抱有疑问的原因之一。

一个部门可能会开发自己的框架，即便成熟的开源替代方案已经存在，并且被广泛使用。我们凭什么期待自己的版本更好？更重要的是，我们凭什么期待它能长期保持更好？

即便内部版本在推出时有优势，维持这种优势也需要持续投入。一个被广泛采用的开源项目，会在许多公司和真实场景中得到检验。活跃的社区能够发现漏洞、贡献修复、完善文档，并让软件适应新的需求。

与此同时，最初的内部开发者可能会离开。接手的人需要学习这个系统，理解那些从未被妥善记录的决策。其他团队又会在它之上建立依赖。最终，升级或替换它可能意味着大量工作和风险。

最初的技术成就，可能变成技术债务。

我见过太多没有必要的框架被构建、采用，随后却得不到充分维护。“开源方案不符合我们的需求”，是一个耳熟能详的解释。有时确实如此。有时，通过配置、一个小扩展，或者向上游贡献代码，就能解决问题。

在决定投入自研替代方案之前，我们应该能回答三个问题：究竟是哪项限制阻碍了业务？我们自己的方案能提供什么实质性的优势？在原团队离开之后，公司是否还能持续承担这份责任？

也有一些时候，自研技术是必要的。

一种新的商业模式、一个真正全新的技术产品，或者独特的运行环境，可能需要现有工具无法提供的能力。在这种情况下，强迫业务去适应现成工具，可能会阻碍公司的发展。开发缺失的能力，可能是公司成长的必要条件。

拒绝做这项工作，可能与开发不必要的东西同样有害。

辨清两者，需要判断力，也需要对自己诚实。我们需要区分业务真正需要的能力，与我们自己想要拥有的平台。而且，随着业务和可用工具发生变化，我们还需要重新审视这个判断。

这让我想到一个更广泛的问题：什么才是好的架构？

我不认为存在一种所有公司都应该遵循的标准架构。我们今天研究的那些架构，是人们应对特定业务、约束和工具时逐渐形成的。在采用他们的答案之前，我们应该先理解那些条件。

早期的 YouTube 是一个我经常想到的例子。它的基础设施并不完善，一支小型工程团队随着服务增长，不断解决瓶颈。在架构仍然演进的时候，业务就已经变得有价值了。它不需要先为未来的每个问题准备好完整答案，才能取得成功。

在自己的职业生涯中，我逐渐形成了一个简单的信念：好的架构能够随业务演进。

这并不是说我们应该停止阅读论文，或者停止向其他工程师学习。他们的经验能帮助我们做出更好的决策。但研究别人的架构，并不能免除我们理解自身业务的责任。

只要一个六十分的方案能够支撑今天的业务，并为明天的改进留出空间，我就乐于接受它。相比一个构建周期过长，或者变更成本过高的所谓完美架构，我会选择前者。

剩下的四十分，可能以后会变得必要。其中一部分也许永远都不重要。随着业务发展，我们可能发现，从一开始，我们就是在用错误的需求衡量完美。

一个实际运行的系统，能给我们提供真实的学习依据。我们能看到用户在哪里遇到困难，成本在哪里增长，以及哪些限制真正阻碍了业务。这些经验能帮助我们决定下一笔投入应该花在哪里。

演进能力不仅包括增加功能，也包括升级依赖、移除不必要的组件、替换内部系统，或者把某项职责交给外部服务。

有时候，一个临时系统就够了。如果它能支撑今天的业务，而未来替换它的成本也可以承受，那么它可能已经完成了自己的任务。并不是每个系统都需要永远存在。

如今，云平台和成熟的开源项目，提供了许多公司过去必须自行构建的能力。这改变了架构的经济账。

对于一家销售基础设施的公司，开发更好的基础设施可能就是业务本身。对于另一家公司，同样的投入则需要通过它所带来的业务成果，证明自身的价值。

这笔账从开发开始之前就要算起，并贯穿系统的整个生命周期。它包括构建和测试、培训使用它的团队、集成、维护、调试、升级，以及最终的迁移或退役。服务器上的节省只是其中一部分。我们还需要考虑，这些人如果投入其他工作，本可以取得什么成果。

在优化一个流程之前，我们应该先问：业务是否还需要这个流程本身？

每家大型公司现在都还需要一个庞大的基础设施部门吗？我不这么认为。部门规模应该取决于业务的需求、外部可获得的能力，以及公司能够持续承担的责任。

架构是在演进的，无法事先完整规划出来。我们可以制定未来三年、五年，甚至十年的计划，但架构应该为适应业务变化留出空间。

当有人声称自己的架构能够满足未来十年的所有需求时，他本质上是在声称自己能够预测未来。而如果你真的能预测未来十年，那你一定有比设计软件架构更值得运用这份天赋的事情。