做技术驱动型企业，易宝支付技术分享之——网络容量如何规划

    面对互联网的快速发展，第三方支付平台也在产品更新、客户服务上不断进行完善。做为第三方支付领导者的易宝支付，在近几年不断推出易码付、掌柜通、EPOS支付等产品。产品类型的增加、功能项的优化等等技术问题，如何在原有系统基础上进行扩展?如何在扩展的同时不影响原有系统的正常运营?这些问题与易宝支付相关人员进行了交流。今天我们还将讨论如何计算系统的可扩展性，也就是如何进行系统容量或者系统能力的规划。系统稳定性就像阳光、空气、水一样，只有失去了才知道珍贵。

　　网络随着企业业务的发展而发展。无论是计划新局域网(LAN)还是维护现有LAN，都需要根据业务需求对数据容量要求进行建模。因此，网络容量规划的起点是记录你现有的资源，网络当前的性能，并评估潜在的需求变化。

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

　　对互联网公司而言，清楚地掌握并合理地规划平台的容量是业务成败的关键之一。首先产品部门需要根据业务的规划来预测用户的访问量，以确定产品所需要的服务能力，据此进一步确定系统所需要的容量。系统运维部门的工程师根据产品需求预测出容量需求，以确定下一年度系统资源的预算，人力资源部门根据产品需求确定需要招聘多少不同技能的人员，比如软件开发工程师、系统运维工程师、数据库管理员等。预算部门根据各部门的需求，准备足够的资金确保增加或者减少服务器和网络设备，雇佣更多称职的工程师来扩展系统容量，以达到预期的产品需求。

　　基本步骤

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

　　实例操作

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

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

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

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

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

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

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

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

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

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

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

　　从这个案例可以看到，对每个迭代进行例行的压力测试以掌握单个节点的处理能力变化非常重要;另外持续不断地对用户请求和系统资源的使用情况进行监测也是进行系统容量规划的基础。理解起来容易做起来难，一切尽在细节中，在于严瑾和坚持，在于事故中磨练出来的团队。

本文为企业推广，本网站不做任何建议，仅提供参考，作为信息展示！