企业业务增长为什么容易带来计算资源不足的问题？

云主机刚买的时候明明够用，怎么过了半年就开始卡了？业务处于增长期的企业，经常会碰到这样的情形。项目上线之初，用户不多，原有的云主机可能绰绰有余，甚至还有一大半资源闲着。可是随着用户数量、交易频次、数据规模和业务功能不断增加，同一台云主机的使用情况会悄悄发生变化，等到发现的时候，往往已经影响到业务了。

资源不足的来源并不单一，大致有四种增长。

用户规模增长，应用访问请求持续增加

用户数量上去了，服务器的负载并不一定同比例增加。真正压在服务器上的，是同一时刻有多少请求在处理，以及每个请求要消耗多少资源。用户翻了一倍，如果大多数人集中在晚上同一个时段使用，并发可能增加得更多；一个请求要查好几张数据库表，再调用外部接口，消耗又更大。所以用户数只是起点，还要看请求量和单个请求的资源消耗。

业务功能增加，后台计算任务更加复杂

业务做着做着，功能就多了。加了报表分析，要定时汇总大量数据；加了批量处理，一次要跑几万条记录；加了消息推送，要在短时间内发给很多用户；又接入了第三方接口，每次调用都得等对方返回。这些后台任务和前台业务共用同一批CPU和内存，哪一边占多了，另一边就受影响。报表恰好在上午九点业务最忙的时候开始跑，就是个典型的例子。

业务数据不断累积，存储资源需求发生变化

数据库里的记录一直在增加，系统日志一天天在写，用户上传的文件越来越多，历史记录也不会自己消失。其中最容易被忽视的是日志，它们增长得很安静，不到磁盘写满的那天，没人会注意。存储还有一个特点：CPU偶尔忙一阵还能恢复，数据却只增不减，是一条持续向上的线。

业务活动产生阶段性峰值

电商促销、集中发布、线上报名、各种营销活动，都会让访问量在短时间内猛增，活动一过又回落。峰值持续的时间不长，却偏偏出现在业务最需要稳定的时刻，一旦撑不住，损失比平时大得多。这类需求最好提前规划，不太适合临时应对。

企业应该怎样判断云主机是否需要扩容？

凭感觉判断很容易出错，可以从下面四个角度来看。

观察长期资源利用率，而不只关注瞬时峰值

CPU偶尔冲到很高，不一定是问题，可能只是某个任务跑了几分钟。更有参考价值的是趋势：把CPU和内存的使用情况拉长到几周甚至几个月来看，平均水平是不是在慢慢抬高，高峰时段是不是越来越长，回落之后的底部是不是也在上移。趋势持续向上，才说明资源在被逐渐消耗。

识别业务响应时间是否持续恶化

用户最直接的感受是页面变慢。可以留意页面的响应时间、接口的处理时间，以及数据库查询的耗时有没有逐渐变长。需要注意，变慢不等于资源不够：可能是某条SQL写得有问题，可能是缓存失效了，也可能是第三方接口响应慢。先分清问题出在哪一层，再决定是升级配置还是优化程序，否则容易花了钱，问题却没解决。

检查存储空间增长速度

存储的判断最简单，也最容易算。用当前剩余的容量，除以最近每周的增长量，就能得到大约还能撑多少周。假设剩余空间每周都在稳定减少，照这个速度几周之后就会用完，那就要赶在这之前安排扩容。再结合业务计划，比如接下来要上线的功能会不会带来更多数据，对未来的数据规模做个估计。

结合业务增长预测安排资源调整

资源不要等耗尽之后才考虑升级。升级本身需要时间：评估方案，安排操作窗口，做测试，有的还需要重启实例。如果等系统已经卡住了才开始，只能在压力之下仓促操作，风险更大。比较稳妥的做法，是结合业务预测，在资源还有明显余量的时候，就着手安排调整。

企业云主机资源扩展，主要有哪些实现方式？

纵向扩展：提高现有实例的资源配置

纵向扩展，就是给现有的实例加资源：把CPU、内存升上去，或者扩大云盘容量。这种方式对应用的改动最小，原来的程序和部署基本不用动，所以通常是企业遇到资源不足时最先考虑的办法。

它也有限制。首先，应用本身要能用上新增的资源，有些程序的设计决定了它用不了更多的CPU核数。其次，调整是否需要重启实例、会不会影响业务，要看具体的产品和操作类型。另外，单台实例的规格总有上限，到了上限就没法再往上加了。

横向扩展：增加云主机实例分担业务负载

横向扩展是多开几台实例，让它们一起分担业务。典型的做法是增加应用节点，前面放负载均衡，把用户请求分发给不同的节点；更复杂的业务，则会采用分布式的处理方式。

这里要强调一点：横向扩展对应用本身有要求。程序必须支持多实例同时运行，用户的登录状态不能只存在某一台机器的内存里，上传的文件要能被所有节点访问到，定时任务也不能每台机器各跑一遍。如果应用还没有为此做过设计，单纯多买几台服务器，性能不会自动变好，反而可能引出新的问题。

业务拆分：让不同应用根据需求使用独立资源

很多企业最早是把所有东西放在一台服务器上：网站前端、后台程序、数据库、文件存储，全都挤在一起。业务增长之后，可以把它们拆开，各自使用独立的资源。数据库需要更多内存和稳定的磁盘，前端更看重网络，文件存储主要看容量。拆开之后，各部分可以按各自的需要单独调整，某个模块出了问题，也不会连带影响其他模块。拆分本身需要调整应用的连接方式和部署，要有计划地进行。

企业不同发展阶段，应该采用怎样的资源规划策略？

创业初期：优先控制资源投入

这个阶段的核心是把产品做出来，验证业务能不能成立。资源只要覆盖核心功能的上线、开发测试和基础的业务运行就行，不必为“以后可能的增长”提前配得太高。投入控制住，等业务验证有了结果，再决定下一步。

业务成长期：建立定期资源评估机制

用户和数据开始稳定增长之后，临时应付就不够了。可以固定一个节奏，比如每个月或每个季度，查看一次CPU、内存、磁盘和带宽的使用情况，对照用户增长、访问量和业务数据的变化，判断是否需要调整。这个机制本身并不复杂，关键在于坚持，别等出了问题才想起来。

业务成熟期：优化多实例资源分配

业务稳定下来之后，往往已经有了多台实例、多个业务模块。这个阶段的重点不再是一味加资源，而是看各个模块的负载特点有什么不同，把资源分配得更合理：负载一直很低的实例，可以适当调低；承担关键业务的，则要留出更多余量。

规模化运营阶段：建立容量预测与扩展预案

规模大了之后，临时决策的代价很高，需要靠数据来预测。可以积累历史的资源使用数据，结合业务的增长曲线，估算未来一段时间需要多少资源。同时要把“扩展周期”考虑进去，也就是从决定扩容到资源真正可用，中间要花多长时间。再配合一定的资源预留机制，遇到突发情况时才有预案可用。

云主机资源增长，为什么还需要持续的服务能力？

纵向也好，横向也好，听起来都像是“点一下”就能完成的事，真正操作起来，会碰到不少技术细节。以一次完整的资源调整为例。

升级之前，先要确认应用的兼容性。有些程序对运行环境有要求，调整配置之后能不能正常运行，最好先在测试环境里验证一下。

如果扩展的是数据盘，磁盘容量变大了，操作系统里并不会自动用上全部空间，还需要处理分区和文件系统，新增的容量才算真正可用。

多实例扩展，则要检查数据共享和业务状态的管理：几台实例之间怎么共享文件，用户的登录状态存在哪里，数据库的连接数够不够。

网络资源的调整，要考虑IP和访问策略。比如增加或更换IP之后，白名单、域名解析、防火墙规则要不要跟着改。

业务发生较大变化时，往往需要重新评估整体的资源规划，不能只在原有的配置上修修补补。

这些环节，企业自己的技术人员能处理一部分，另一部分需要和服务商协同：产品能做哪些调整，有什么限制，操作时要注意什么。所以资源增长不是一次性的购买行为，背后需要持续的技术沟通。

恒讯科技云主机如何支持企业不同阶段的资源调整？

对照前面讲到的几种扩展思路，恒讯科技云主机在产品层面提供了下面这些基础。

配置选择方面，官网云主机提供多种实例规格，企业可以按业务需要选择CPU和内存，也可以选择带宽、云盘等资源。创业初期可以从较小的规格起步，不必一次配到位。

业务增长时，恒讯科技支持云服务器规格升级，为业务增长留出了调整空间。

部署区域方面，恒讯科技提供北京、辽宁、江苏、香港、广东五大云主机节点，企业可以结合用户分布和业务布局来做规划。

资源管理方面，企业可以通过控制台和API进行资源操作和管理，日常的调整与查看在控制台完成，需要自动化的时候再借助API。

以上能力，均可在恒讯科技云主机产品页核对。有一点需要说明白：产品支持规格升级，不等于所有实例都支持任意的在线扩容，也不等于具备自动弹性伸缩。具体的升级条件、是否需要停机以及费用，以实际产品为准，建议在升级之前向服务人员确认。

企业制定云主机扩容方案之前，需要准备哪些数据？

数据准备得越全，方案越有依据，沟通起来也越高效。可以按下面的清单整理。

现有资源的状况。包括当前的实例规格，近一个月CPU和内存的利用情况，以及磁盘空间的使用情况和增长速度。

业务运行的表现。包括网络流量的变化趋势，业务的并发量和响应时间。

对未来的预期和约束。包括预计未来半年到一年的增长情况，扩容的预算，以及业务能够接受的调整窗口，也就是哪个时间段可以停下来做操作。

云资源的管理，不该停在购买那一刻的一次性配置上。业务在变，用户在变，数据也在变，配置需要跟着持续评估。可以先把上面清单里的数据整理出来，再根据实际的使用情况，向恒讯科技咨询适合的云主机规格和升级方案。