容量规划注意事项
基本容量规划从一些简单的计算开始，但有一些因素可能使过程变得复杂。 除了简单的当前和预测使用量，还必须考虑以下因素：
- 服务限制和配额
- 成本限制
- 代码和配置效率低下
- 依赖关系
在本单元中，你将了解这些考虑因素对容量计划的影响，还将了解如何应对每个因素。
服务限制和配额
人们倾向于将云计算视为一种不受限的资源。 与传统的服务器/数据中心模型相比，云的容量似乎是无限的。 云确实能够提供前所未有的规模。 但是，像其他所有技术一样，它也存在一些限制。 进行容量计划时，需要了解何时会达到这些服务限制。
审视系统及其体系结构时，需要了解你使用的云服务的限制。 例如，默认情况下，Azure 中的每个 VM 可用性集最多可以包含 200 个 VM。 如果刚开始使用，这些 VM 看起来像是绰绰有余了。 不过，如果达到改限制，你就无法额外预配任何 VM，这可能会导致服务中断。
同样，默认情况下，每个订阅在每个区域可以有 250 个存储帐户。 这些限制都是可调高的软限制的示例。 但某些服务有最大限制，可通过以下链接了解详细信息。
需要注意和监视这些限制和配额。 让我们看看应该怎么做。
Azure 门户
可在导航窗格中“订阅”->“设置”下的“使用情况和配额”部分查看服务配额，并了解还要用多少才会达到这些限制。 可筛选服务类别（例如网络/计算）和 Azure 区域。 这将显示还要用多少才会达到限制。
通过代码
可以使用任何 Azure 服务的 Usage - List 终结点来获取当前资源使用情况信息及订阅下计算资源的限制，如下面不完整的示例中所示。
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2023-03-01
{
"currentValue": 124,
"/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/westeurope/usages/VirtualNetworks",
"limit": 1000,
"name": {
"localizedValue": "Virtual Networks",
"value": "VirtualNetworks"
},
"unit": "Count"
}
可以看到，当前使用的 Azure 虚拟网络 (VNet) 数量为 124，限制为 1000。 需要发出支持请求才能提升限制阈值，因此请务必提前了解何时会接近阈值。
成本限制
缩放不是简单地投入更多资源来缓解问题。 你的组织必须了解云环境的成本，并了解添加更多资源通常等于增加更多成本。 请注意这一成本，并与财务团队合作，确保你们就当前云支出和预计云支出达成一致。
最初设计系统时和对已在运行的系统进行定期审查时都应预测成本。 Azure 提供的工具可帮助你：
- 使用 Azure 计算器来规划环境成本。
- 在 Azure 门户中查看当前和预计每月支出。
- 在 Microsoft 成本管理中设置预算。 此工具可以让你在不同范围（包括管理组、资源组和订阅等）检查成本。
代码和配置效率低下
有时，分配更多资源可以解决问题，但这会产生费用。 有时扩展并不能解决问题，或者说不能完全解决问题。 在某些情况下，可能看起来需要扩展，而实际上是编程或配置不良导致的问题。
在横向扩展资源之前，先查找 bug 也许可以节省资金和时间。 这种方法的一些示例包括：
- 如果带有热分区的数据库设计不佳（例如在大型 noSQL 数据库上只使用一个分区），则无论缩放到多大，速度都会很慢。
- 如果有效率低下的数据库查询，在向数据库投入更多资源之前，请提升这些查询的性能。 有时，只是基于常见查询向数据库添加正确的索引，就可以显著降低成本。
- 如果超时时间设置错误，数据库连接可能会由于服务器和数据库之间的超时时间不一致而变得饱和。 在这种情况下，需要在缩放数据库之前修复设置。
- 如果开发人员的代码效率低下，你可以编写更高效的代码来解决问题吗？ 也许代码在可释放内存时没有释放，所以你在不需要使用较大内存的 VM 时却一直在使用这些 VM。 这样的修复可以显著节约成本。
依赖关系
解决本模块中描述的某些问题所需的更改通常依赖于应用程序的开发人员。 这里建议的一些解决方案和最佳做法需要你和这些开发人员协作才能实现。
你可能无法完全自行实现所有这些建议。 不过，如果你了解云系统及其功能和特征，你就可以成为改进系统及其可伸缩性和可靠性的变革驱动者。