4

2.6.6 负载规划

负载规划是指对未来一段时间内用户的使用量进行粗略估计并制订应对计划，这对工程团队来说非常重要。他们会根据你预估的使用量来确定哪些地方需要添加缓存，哪种类型的服务器和存储需要准备，哪些授权问题可能产生，等等。
首先你会建一个表格来制订年度或季度负载能力规划。然后你需要预估存储量（帖子数量、图片数量、图片大小等）和流量（访客数量、访客停止时间、人均页面流量数）。在谷歌你还需要预估出口流量（从数据中心获取的数据量）和进口流量（你的服务器请求量）。包括亚马逊网站在内的大部分应用的出口流量都远远大于进口流量。但如果你构建了一个用户可以上传图片、视频或者其他内容的应用，你的进口流量就会非常大，所以请根据实际情况制订负载规划。

你需要维持适当的余量并预测一个余量值，这个值可能并不准确。例如，你可以这样说：“我设想需要100%的余量来应对超出预期的增长。”

你需要预估日均峰值，通常预估为均值的3到4倍是安全的，因为这个值代表了美国不同时区用户的重叠峰值。如果你的产品与众不同，比如是一个设计成开机启动的软件升级系统，你的峰值则会远远大于均值，所以请根据实际情况调整预估数值。

如果业务面向全球，还需要考虑如何缓解延迟问题，是部署多个数据中心，还是使用阿卡迈（Akamai）等公司提供的内容分发网络（CDN， Content Delivery Network，也称为边缘缓存）。

你需要制订预案以应对突发的高峰，比如在产品发布时期剧增的访问量。这时期的用户行为极为不同，你需要采用不同的应对计划。比如当《60分钟》报道了你的产品时，你该如何应对突增的用户量呢？我在一家创业公司时曾经历了这样的事情，不过好在尽管延迟增加、网页做了分页处理，但产品始终是可以访问的。虽然并不完美，但至少我们扛住了。

你需要制订备用策略以应对最坏的情况。一次分布式拒绝服务（DDOS，Distributed Denial-Of-Service）攻击、一篇《华尔街日报》的报道或者一次数据中心故障都可能置你的产品于最坏的境地。不过灾难并不可怕，可怕的是你没有任何准备。你应该适当部署一些有效的危机管理系统，如流量限制系统、“系统目前繁忙，请稍后再试”的出错页面或者保存在CDN上的应用静态版本。

你可以在撰写负载规划这节时与工程团队就系统设计进行充分的讨论。你需要了解当系统过载时是部分彻底不可用还是整体被拖慢？系统是支持纵向扩展（指你每增加一台服务器，你就能获得这台服务器的负载能力）还是非线性扩展？

总之，关于负载规划你要做的就是进行合理的预估，你的工程主管则负责根据预估值来构建一个能稳定运行的系统。不要花太长时间在预估上面只需花几个小时写个初稿，再找几个团队成员讨论下并将讨论出来的数值翻倍就大功告成了。