为业务增长做好准备
你可能听说过“工欲善其事，必先利其器”。 要实现顺畅、成功、可靠的增长，这句话尤其正确。
云计算的最大优势之一是能够进行缩放。 这种能力使得有人做出错误的假设，那就是因为云能够无限缩放，因此不需要针对云中的增长进行准备或规划。
确实，云中的资源对满足你应用程序的需求而言很可能绰绰有余。 不过，了解容量需求仍然很重要，原因如下：
尽管云中可能有大量资源来满足你的需求，但并不是你使用的所有服务能自动缩放或继承缩放能力。 因此，你需要了解服务限制，并知道何时需要对服务和资源进行纵向扩展。
云资源可能不受限制，但你的预算却不太可能。 你必须考虑成本，而你在财务部门的朋友需要了解你预测的云支出。
为有机增长制定计划
商业领域的有机增长指的是组织扩展其自身容量的过程，依赖于内部资源和技能来促进更慢、更自然的增长。
随着业务有机增长而需要计划云中容量时，应该做的第一件事是映射出应用程序中较大组件的当前资源需求。
场景：有机增长
现在返回到我们在本模块的前面部分查看过的体系结构。 Tailwind Traders 即将推出一种创新型新产品，并预期它会带来急剧的业务增长。 温馨提示，该公司的体系结构图如下所示。
要开始容量规划，需要确定较大的组件。 在此示例中，这包括：
- Azure Kubernetes 服务群集
- Azure 应用服务中运行的 Rewards 应用
- 各种数据库，例如 Cosmos DB、Azure SQL 等。
对于以上每个大型组件，需要了解其当前资源使用量，以帮助你计划将来的使用量。 让我们来看看其中一个大型组件的资源使用情况。
在 Cosmos DB 中度量容量
在 Cosmos DB 中，以 GB 为单位度量存储空间并自动缩放，但出于成本原因，你仍然需要了解度量值。
预配了吞吐量，可使用名为“请求单位”的指标来衡量它。 请求单位 (RU) 是内存、CPU 和 IOPS 的结合，它提供单一指标，你可用它来规划容量。 你以每秒 100 个 RU 的增量预配 RU。
每个数据库操作都以 RU/秒为单位。 读取操作非常简单：1 KB 的读取操作是 1 个请求单位。 其他操作根据多个因素计算，例如项的大小、数据一致性、查询模式等。
在分析应用程序时，来自 Cosmos DB 的每个响应都包含请求费用标头，它显示该请求具体使用了多少个 RU。 可将使用的 RU 数与预配的 RU 数进行比较，以验证当前容量是否充足。
最好将资源使用量关联到业务指标，例如月度活跃用户或收入。 这种相关性可帮助你根据预期的业务增长方式计划容量。 可以在 Azure Monitor 中检索这些容量度量值。 了解系统的资源使用情况可以帮助你了解何时需要纵向扩展，以及随时间推移而产生多少成本。
让我们具体一点，来查看 Tailwind Traders 的 CosmosDB 使用情况数据。 下面是其用量图。
在此示例中，Tailwind Traders 以 2,500 名月度活跃用户 (MAU) 的平均速率增长，当前用户基数为 10,000。
如果查看存储，可以看到，其数据库使用了 5 TB 可用空间中的 300 GB (6%)。 增长速率为 50 GB/月（即每月增长 1%）。
从吞吐量角度来看，其当前值为 300/1000，增长速率为 10%/月：
现在我们了解了系统资源指标，知道了什么时候可能必须缩放吞吐量，以及随着时间的推移会有多少成本。
现在，我们可以生成一个图表来帮助我们进行容量计划。
现在我们知道，我们的数据库将在 5 月达到 RU 容量，因此需要在此之前进行缩放。 另一个有趣的见解是，该公司甚至可以立即纵向缩减其 CosmosDB 数据库，因为其使用量离预配容量还很远。
为无机增长制定计划
在上面的示例中，你为有机增长制定了计划。 无机增长来自外部因素，而不是公司自身业务活动的增加。 这种情况不是自然发展，倾向于涉及更突然、更剧烈的使用量增加。
有时，真的无法预知流量、用户等的增长。 预见到这类情况时，需要构建系统，尽可能提升其自动缩放能力，并使其在确实无法缩放时顺利地正常报错。 我们将在此模块的稍后部分介绍相关内容。
在其他时候，例如即将推出产品时，你可能会遇到无机增长，你可针对这种情况做好规划和准备。 如果你的团队在工程、产品、营销和财务方面协作，并且你知道如何获取资源使用情况和增长模式。 你可做出合理的努力来预测这些事件对资源要求的影响，并相应地实施更改。
正确做到这一点由你的组织和具体事件而论。 你不一定总能做好，但尽量做好准备会让你有个良好的开端。
场景：无机增长
让我们以另一种假设情况作为为无机增长制定计划的示例。 在 Tailwind Traders，我们即将举办一场市场营销活动，来推出一款高调的创新型新产品。 预期该活动会向公司销售点吸引来 5000 多名用户。
如果使用上述有机增长示例中的数据，并（根据一定的因果关系）将其关联到你从产品/市场营销团队获得的业务指标（例如用户数量）， 就可以开始为无机增长制定计划了。
你从上一场景中了解到，2500 名用户大约需要 50 GB 的存储空间和 100 个 RU。 现在可以使用该数据来确定自己是否已准备好举办这场活动。 如果我们可以预期增长 5000 用户，就需要 100 GB 的存储空间和 200 RU。
可以看到，存储容量可以充分满足活动预期带来的增长。 这些容量会自动缩放，因此这里唯一需要了解的就是新增成本，稍后将对此进行讲解。
你还可以预测其 RU 在活动后仅达到 50% 的容量。 因此，对于这场活动，该公司无需担心 Cosmos DB 容量。
但是，该活动会影响成本。
可以看到，100 GB 的额外存储空间每月将额外产生 25 美元的成本。 吞吐量价格保持不变，因为客户为预配的 RU 付费，而预配的请求单位已绰绰有余。 因此，此市场营销活动很可能使其 CosmosDB 费用增加 $25 美元。