创业公司架构优化：解决到可接受程度而非极致

在各种场合听到的”架构优化”，一般都是指优化某一个具体业务模块、把性能做到极致；但雪球团队做的架构优化更多是”从问题出发，把实际问题解决到可以接受的程度即可”——这种做法从旁观者角度看会显得凌乱，每件事单拎出来也不像什么大事，但这恰恰是快速增长的创业公司应对复杂业务局面时更现实的策略。这条原则背后有一层关键区分：面对一个”大服务”（比如遗留的大一统系统Snowball）做架构优化时，一般是往深处的本质去挖掘、做比较彻底的重构；但当面对的是一堆架构各异的小服务时，”架构优化”的含义就不一样了——大部分时候既不需要、也没有办法深入到每个小服务的最底层去优化，只要去掉或优化掉原来明显不合理的地方就够了。这个区分揭示了一条容易被忽视的判断标准：优化投入的深度应该和”这个组件在系统里的地位”匹配，而不是所有组件都用同一套”往死里优化”的标准去对待——对核心大服务值得深挖本质，对众多外围小服务只需要消灭明显的不合理之处，试图用统一标准苛求所有组件都做到极致，本身就是一种资源错配。这条原则的现实依据是：在快速迭代的创业公司里，不会（也没必要）针对某一个服务做非常完善的架构设计和代码实现，出现问题时也不追求极致优化，而是”以解决瓶颈问题为先”——极致优化需要的时间和确定性，往往是快速变化的创业环境负担不起的奢侈品。