用小鸟吊起大鲸鱼，拢共分几步？

-引言-

我们先来回答两个好玩的问题：

问题一：

问：把大象放进冰箱，需要几步？

答：

1、打开冰箱；

2、把大象放进去；

3、关上冰箱。

问题二：

问：用小鸟吊起大鲸鱼，拢共分几步？

想知道答案？请继续往下看。

---

-正文-

前几日我们讨论了如何计算平台的可用性，今天我们将讨论如何计算系统的可扩展性，也就是如何进行系统容量或者系统能力的规划。

在推特早期，系统经常因为出现重大问题而导致宕机。当这种情况发生时，推特网站就会出现失败鲸鱼的页面，几只推特小鸟试图把一条大鲸鱼从海里吊起来，这也暗示着推特的市场需求繁多，用户请求导致系统负载过大，小鸟们正在努力解决问题。类似的事情时有发生，以至于印着鲸鱼和小鸟图案的衣服开始在旧金山的街头售卖。

《孙子兵法》中提到：“故知战之地，知战之日，则可千里而会战。”意思是说优秀的将帅可以通过分析敌我双方的情况，预知交战的时间、地点，从而决定应该在何时、何地交战才能掌握主动，取得胜利。因此，胜利是可以争取的，只要具备一定的客观条件，发挥主观能动性，因势利导，就能夺取胜利。

事实上，如果做好网站的容量规划，系统过载这类问题完全可以通过正确的管理流程和适当的资源投入来避免。

一、基本介绍

对互联网公司而言，清楚地掌握并合理地规划平台的容量是业务成败的关键之一。首先产品部门需要根据业务的规划来预测用户的访问量，以确定产品所需要的服务能力，据此进一步确定系统所需要的容量。

系统运维部门的工程师根据产品需求预测出容量需求，以确定下一年度系统资源的预算，比如网络带宽、服务器数量、数据库的许可证以及存储空间的大小等。

人力资源部门根据产品需求确定需要招聘多少不同技能的人员，比如软件开发工程师、系统运维工程师、数据库管理员等。如果知道应用服务器和数据库有充足的预留空间，但防火墙和负载均衡设备会出现吞吐量瓶颈，那么可能需要增加具有负载均衡和防火墙技能的网络工程师，而不是管理服务器的系统管理员。

预算部门根据各部门的需求，准备足够的资金确保增加或者减少服务器和网络设备，雇佣更多称职的工程师来扩展系统容量，以达到预期的产品需求。

大型的互联网公司应该设立独立的系统容量规划部门。在CTO的领导下，由专业的系统容量规划师来负责统筹分析、计算、协调平台的合理预留能力和发展空间，这涉及到产品部门、研发部门、运维部门、人力部门和财务部门，是一项综合性很强的工作。实际的规划工作覆盖了数据中心空间、电力、机架、网络带宽、存储设备、服务器、信息安全设备、负载均衡设备、灾难和恢复（DR）和业务持续计划（BCP）。

二、基本步骤

了解了以上这些基本信息后，我们应该如何计算并确定平台的合理预留空间呢？以下是需要遵循的几个基本步骤：

三、实例操作

下面我们通过一个典型的基于 SaaS 的 B2B 产品实例来解释如何规划系统的容量。这个产品非常受市场欢迎，而且客户数量呈爆发式的增长。当新客户注册该产品的服务时，平台的负载会随着每个客户公司所带来的用户数量的变化而变化。到目前为止，该平台共有 25 个客户，约 1500 位用户。

为确保平台可以满足业务发展的需要，该 SaaS 提供商的 CTO 正在做明年的预算，这需要我们准确地预测成本，因此要求进行一次系统容量的规划。

第一步是理解平台的技术架构。该 SaaS 应用的技术架构非常简单，包含网络层、应用层和数据层。在该容量规划中，我们将聚焦网络、应用和数据库服务器，暂时忽略路由器、交换机、防火墙和负载均衡等网络设备，当然，在实践中我们必须定期对这些网络设备进行分析，以确保有足够的预留空间。

第二步是确定需要关注的组件。在本案例中，这些要关注的组件就是网络服务器、应用服务器和数据库服务器。

第三步是确定每个组件的实际和最大的使用率。假设这些组件都有良好的运维记录，我们了解所有这些组件的实际峰值和平均使用率，在每次代码发布前都进行压力测试，并且掌握每个组件的 TPS（每秒处理的用户请求数或者每秒处理的交易数）。

系统可以监控每个发送到网络服务器和应用服务器的请求。从上表中可以看到，网络服务器在高峰期每秒接受 125 个请求（TPS），应用服务器在高峰期每秒接受 80 个请求（TPS）。出现这种差别的原因是在网络服务器上有大量不需要任何业务逻辑计算的静态页面，这些页面包括企业官网、引导页、图片等。上表给出了每个组件高峰期请求的总数、服务器群组的节点数、单节点请求的峰值和单节点所允许的最大请求数。在压力测试中，当服务器对用户需求的响应时间高于内部服务水平协议（SLA）标准时，所观察到的请求数量就是每个节点所允许的最大请求数。

第四步是确定该业务流量的增长率。下图显示了该 SaaS 产品最近两周每天的流量监控数据，据此可以看出每周的流量增长情况。通过计算，我们得出每周的流量增长率为2%，年化相当于280%的增长率，或者每年3倍的增长率。这种快速的增长既来自于现有的客户使用越来越多的服务，也得益于销售团队签约新的客户。

第五步是确定该 SaaS 产品受季节性影响的程度。由于该产品是为企业服务的，而企业的项目往往是在年初做预算，所以会有一定的周期性。下图显示了该 SaaS 案例中存量客户的季节性变化趋势。根据这个趋势，我们可以观察到存量客户会受到影响的季节。由于这个容量规划是在八月份进行的，而八月通常是该产品使用率较低的月份；因此我们预计在明年的一月底前受季节效应影响，流量会增加 50% 。

第六步是计算实施既定的系统扩容项目后可以获得的新容量。假如这个项目计划在今年秋季实施，创建一个写数据库和两个读数据库，把数据库节点增加到三个，从而把现有请求分散到三个节点之间。

第七步是估计服务器的理想使用率。理想使用率是指一个特定组件可以安全地使用多大百分比的容量。有两个理由使我们无法 100% 地使用组件。首先，尽管我们尽力收集数据，但在容量规划中，必定会包含一定程度的误差。为此，我们需要一个缓冲空间以容纳这些不确切性。

其次，任何组件，当其使用率达到容量的100%时，系统行为可能会变得不稳定和不可预测。我们希望系统能够在行为可预测的容量范围内运行。每个组件都有各自的理想使用率，其值取决于估算的准确性和缓冲空间的大小。在本案例中，数据库的理想使用率将采用 90% 、网络和应用服务器的理想使用率将采用 75% 。

第八步就是进行计算。可采用以下公式进行计算：

容量=理想使用率*最大容量-目前用量-增量+计划扩容

以网络服务器为例，首先，计算在理想情况下，该 SaaS 产品可以处理的总容量，即：

75% × 75TPS／服务器 × 5个服务器 = 281.25TPS

其次，计算该系统目前的预留处理，用总容量减去当前已经使用的系统容量，即：

281.25TPS - 125TPS = 156.25TPS

再次，我们需要考虑未来的需求，对网络服务器而言，每年流量增加 300% ，季节性增长率为 50% ，加起来每年的总流量增加 350% ，即 3.5 倍，这等于共有 437.5 个 TPS 的潜在未来请求。由此得出的计算结果是：

156.25TPS - 3.5 X 125 = -281.25TPS

最后，综合全部的计算步骤如下：

75% X 75TPS／服务器 X 5个服务器 - 125TPS - 3.5倍 X 125TPS = -281.25TPS

这个结果是个负数，这意味着当前的网络服务器群组没有足够的容量，无法满足明年的业务扩展需要，我们必须采取多种措施来扩大容量。可以优化代码提高单个服务器的处理能力，也可以在不动代码的前提下，通过购买更多服务器来扩大容量。计算需要多少个服务器的方法是用需要扩大的总容量除以理想使用率和单台服务器的能力之积，也就是：

281.25TPS ／（75TPS X 75%）= 5个服务器

这意味着我们还需要增加五个额外的网络服务器来处理预期的流量增长。

下表把网络、应用和数据库服务器的容量计算细节列了出来供大家参考。

总结

从这个案例可以看到，对每个迭代进行例行的压力测试以掌握单个节点的处理能力变化非常重要；另外持续不断地对用户请求和系统资源的使用情况进行监测也是进行系统容量规划的基础。

除了从技术角度进行预测、计算和规划外，同时我们还需要从人力资源的角度出发，根据技术组件的变化情况，有针对性地调整技术人员，以适应产品的新需求。今天，系统容量的规划是被许多互联网公司忽略的一个工作，也是不少互联网平台无法满足用户和市场的快速变化而发生崩溃的一个重要因素，建议每个 CTO 都把这件事情重视起来，从组织、人员和过程管理角度把这项工作纳入常规工作。

现在你能回答开篇的问题了吗？

问：用小鸟吊起大鲸鱼，拢共分几步？

答：

1、先计算需要多少只小鸟；

2、给小鸟和鲸鱼套上绳子；

3、让小鸟飞！

作者介绍

陈斌：易宝集团首席技术官