一般指南和最佳实践

  • 项目

命名约定

为 Azure 中的任何服务挑选名称至关重要，因为：

  • 以后再更改名称会很困难。
  • 名称必须满足其特定资源类型的要求。

一致的命名约定让您能够轻松找到服务。 名称还可以指示服务在解决方案中扮演的角色。

请参阅命名约定文章，该文章概述了 Azure 服务的命名规则和限制，以及关于命名约定的一组基准建议。

资源组

在 Azure 中，所有资源都是在资源管理组中分配的。 资源组提供资源的逻辑分组，使它们更易于作为集合使用，从而可以按生存期、所有者或其他条件进行管理。

有关所有详细信息，请参阅管理资源组页面。

Azure 存储区域

如果不同存储资源的输入和输出位于不同的区域，则您需要为在区域之间移动数据支付费用。 有关详细信息，请参阅带宽定价详细信息。 在同一区域中配对 Azure 服务，以避免出站数据传输。

提示

尝试使用最靠近大多数用户的区域。

安全性

在使用 Azure 设计、部署和管理云解决方案时，请参阅此安全最佳实践集合。 这些最佳实践来自我们的 Azure 的体验以及像您这样的开发者的经验。

白皮书的各部分以单独的文章形式发布，如下所列：

有关其他安全最佳实践，请参阅 Azure 安全最佳实践和模式。

另请查看 Azure DDoS 防护：最佳实践和参考体系结构文档。

隐私

为了减少隐私责任足迹，请利用某些存储用户数据的服务所提供的功能：

Azure 资源管理器

利用 Azure 资源管理器创建、更新和删除您的 Azure 订阅中的资源。 如果遇到问题，请参阅使用 Azure 资源管理器解决常见的 Azure 部署错误和解决资源提供程序注册错误。

Azure 事件中心分区

一旦创建分区，将无法更改分区数。 当您计划进入生产阶段并且可能会从大量用户那里接收事件时，您应该事先进行一些计算，并结合负载测试和数据使用情况，找出所需的确切分区数量。

有关基于 Azure 事件中心设计全球范围遥测平台和调整其大小的完整视频指南，请观看此视频。

1 吞吐量单位（下文以 TU 表示）等于 1 MB/秒或 1000 条消息/秒，以先达到者为准。 您将需要为 TU 付费；要调整成本，您可以根据负载要求更改 TU。

每个单独分区的最大入口限制为 1 MB/秒或 1000 条消息/秒，以先达到者为准。 请参考以下原则来确定分区数：

  • 分区提供高可用性。 如果您要向事件中心发送消息并希望发送成功，则应创建多个分区并使用 EventHubClient.Send 发送。
  • 分区数将决定事件中心管道的宽度以及您可以接收和处理消息的速度。 如果您的 Azure 事件中心有 16 个分区，则其最大容量为 16 TU。 打个比方，分区就相当于高速公路上的车道。
  • TU 在命名空间级别进行配置。 同样，一个事件中心命名空间可以有多个 Azure 事件中心。 每个 Azure 事件中心可以有不同数量的分区。

您不能使用多于分区数的 TU：如果您有 3 个分区，则无法使用 3 个以上的 TU。 分区数通常多于 TU 数，原因如下：

  • 当流量增加时，您可以增加 TU 数，但不能更改分区数。
  • 您的并发读取器的数量不能多于分区数。 如果您需要 10 个并发读取器，则需要 10 个分区。

提示

推荐的路径是在开发解决方案时以 1 TU 为起点对分区数进行建模。 完成此阶段后，当您在封闭测试期间进行负载测试时，增加 TU 来适应您的负载。 提醒一下，您可以在同一事件中心命名空间中拥有多个 Azure 事件中心。 因此，在 Azure 事件中心命名空间级别具有 20 个 TU 和具有 4 个分区的 10 个事件中心的情况下，每个可以在整个 Azure 事件中心命名空间中提供 20 MBPS。

Azure Cosmos DB

Azure Cosmos DB 资源依据设置的吞吐量和存储计费。 Azure Cosmos DB 吞吐量以每秒请求单位的形式表示（下文以 RU/s 表示）。

为了提供可预测的性能，您应该以 100 RU/秒为单位预留吞吐量。 您可以使用 Azure Cosmos DB 请求单位计算器来估计吞吐量需求。

提示

根据经验/最佳实践，最大 RU 数不应超过最小/稳态吞吐量的 20 倍。

  • 您可以立即提高到初始设置吞吐量的 2 倍。 您可以异步增加到任何吞吐量值，最高异步提高到 1M（通过支持票证可进一步提高）。
  • 您可以立即降低到初始设置吞吐量的 10 倍（总范围为 20 倍）。 但在某些情况下，有可能降低到此范围以外。

有关详细信息，请参阅在 Azure Cosmos 容器和数据库上设置吞吐量。

Azure 存储帐户限制

Azure 存储具有某些限制，详见 Azure 订阅服务限制页面。

如果您的游戏需求超出了单个存储帐户的可伸缩性目标，您可以构建应用程序以使用多个存储帐户。 然后，您可以跨这些存储帐户对数据对象进行分区。

Azure 存储资源管理器

Azure 存储资源管理器是一种工具，可让您轻松管理 Azure 存储资源。 上传、下载和管理 blob、文件、队列、表和 Azure Cosmos DB 实体。 轻松访问以管理您的虚拟机磁盘。 支持 Windows、MacOS 和 Linux。

Azure 流分析单位

选择特定作业所需的流单位（下文以 SU 表示）的数量取决于作业中定义的输入和查询分区配置。 最佳实践是分配多于所需数量的 SU。 Azure 流分析处理引擎以分配额外内存为代价对延迟和吞吐量进行优化。

通常，最佳实践是对于不使用 PARTITION BY 的查询，从 6 个 SU 开始，然后使用试错法（即：传入具有代表性的数据量后，检查 SU% 利用率指标，然后修改 SU 数）确定最佳数量。 流分析作业所能使用的最大流单元数取决于为作业定义的查询中的步骤数，以及每一步中的分区数。 可在此处了解有关这些限制的详细信息。

有关选择合适数量的 SU 的详细信息，请参阅下面的页面：缩放 Azure 流分析作业以增加吞吐量

备注

选择特定作业所需的 SU 数目时，需根据输入的分区配置以及为作业定义的查询来决定。 您可以为一项作业选择最多达到您的配额的 SU。 默认情况下，对于特定区域中的所有分析作业，每个 Azure 订阅有多达 200 SU 的配额。 要使订阅的 SU 数量超出此配额，必须与 Microsoft 支持联系。 每个作业的 SU 的有效值为 1、3、6，以 6 为增量递增。

此外，Azure 流分析使用可变大小批次处理事件和写入输出。 通常，Azure 流分析引擎不会一次写入一条消息，而是使用批处理来提高效率。 当传入和传出事件的发生率都很高时，它将使用较大的批次。 当出口速率较低时，它将使用较小的批次，以保持较低的延迟。 请参阅输出批次大小页面，该页面介绍一些关于输出批次的 Azure 流分析注意事项。

Azure Database for MySQL

使用 Azure Database for MySQL 开发“云-本机”游戏应用程序时，重试逻辑和连接池是必不可少的组件。 将 Azure Database for MySQL 数据库游戏构建为检测和重试断开的连接和失败的事务至关重要。 当应用程序重试时，应用程序的连接将透明地重定向到新创建的实例，该实例接管发生故障的实例。 Azure 内部使用网关将连接重定向到此新实例。 发生中断时，整个故障转移过程通常需要数十秒钟。 由于重定向是由网关内部处理的，因此外部连接字符串对于客户端应用程序保持不变。 大多数游戏应用程序对延迟的要求都很低，因此强烈建议为运行在 Azure Database for MySQL 上的游戏应用程序使用连接池。 如果不使用连接池，在会话结束时打开和关闭连接可能会导致额外的延迟开销。 请参阅管理连接，了解如何在访问数据库时合理使用连接。

关于纵向扩展或收缩：当纵向扩展或收缩 Azure Database for MySQL 时，将创建具有指定大小的新服务器实例。 现有数据存储与原始实例分离，然后附加到新实例。 在缩放操作期间，数据库连接将发生中断。 客户端应用程序断开连接，打开的未提交事务将被取消。 客户端应用程序重试连接或建立新连接后，网关将连接定向到新调整大小的实例。 有关详细信息，请参阅缩放资源。

以下链接介绍容量、存储引擎支持、权限支持、数据操作语句支持以及数据库服务中的功能限制。

值得注意的是，当可用存储空间不足 5 GB 或设置存储的 5% 时，服务器会被标记为只读，建议您设置警报以在服务器存储空间接近阈值时通知您，以便您可以避免进入只读状态。 有关详细信息，请参阅有关如何设置警报的文档。

Azure 容器实例

通常，建议在 Windows 上通过 Azure 容器实例使用 Linux，因为 Windows 容器通常是较重的部署映像，需要更长的时间来启动和加载。 此外，通过 Azure 容器实例使用 Linux 还能提供一些 Windows 当前尚不支持的功能集，例如虚拟网络。