没有万能可伸缩架构架构必须围绕负载假设构建

[[Twitter主页时间线的扇出问题揭示写时多做与读时多做的权衡]]说明可伸缩性从来不是一个 可以脱离具体场景讨论的一维属性——不存在”某某架构天生可伸缩”这种说法，也没有一招鲜 吃遍天的通用方案（业界戏称为”万金油”）。同样的数据吞吐量，用来处理每秒10万个1KB 请求的系统，和用来处理每分钟3个2GB请求的系统，架构会完全不同，因为二者的负载参数 （请求频率、单次数据量、读写比例、访问模式）截然不同。一个良好适配的可伸缩架构， 本质是围绕着一组关于”哪些操作常见、哪些操作罕见”的假设搭建起来的——这组假设就是所谓 的负载参数。这里隐含着一个重要的风险：如果这组假设最终被证明是错的，那么为了迎合 这组假设所做的工程投入不仅白费，甚至可能起反作用（比如为一种几乎不会发生的负载模式 过度优化，反而拖累了真正常见操作的性能）。因此在早期创业公司或非正式产品阶段，比起 “为未来假想中的负载做可伸缩性投入”，更重要的往往是保持产品快速迭代的能力——因为这 个阶段对负载参数的假设本身还很不稳定，过早做重架构投入的风险更高。