高级 XBOX 服务沙盒

另请参阅 XBOX 服务沙盒概述。 XBOX Live 沙盒为开发提供了一个完整的私有环境。本文解释沙盒是什么、它们为什么存在、它们如何应用于发布者，以及它们如何影响内部 XBOX 团队。本文的受众是构建 XBOX One（或更高版本）内容并使用沙盒的发布者。 XBOX Live 开发为发布者提供了在生产环境中使用生产质量服务和生产 MSA 开发人员帐户进行测试的巨大机会。功能和灵活性的增加需要在 Partner Center 执行配置步骤，以创建标题数据并在开发中和正式发布时管理对标题的访问。 沙盒是在生产环境中对数据进行分区的一种方式。由于所有内容只有一个生产环境，因此沙盒充当”虚拟环境”，在一个环境中生成的数据不会跨越到另一个环境。

​

在 XBOX Live 上隔离内容

在 XBOX Live 中，只有一个生产环境，其中包含所有预发布（开发中和 beta）、认证和零售内容。 内容隔离是确保生产环境中没有发布者内容泄漏的方法。内容隔离的核心是确保任何请求访问资源（标题或服务）权限的主体用户、设备或标题都已获得访问该资源的授权。使用内容隔离，分区被分成沙盒，其中存储着标题或服务数据；授权策略在沙盒范围内定义。 沙盒是一种对生产环境中的数据进行分区的方式。

• 使用 XBOX 360 时代的服务，PartnerNet 和 ProductionNet 是两个截然不同的环境。
• 使用 XBOX One（或更高版本）服务，单个生产环境包含 n 个不同的虚拟环境，其中每个虚拟环境称为沙盒。

由于所有内容只有一个生产环境，沙盒实际上是唯一的虚拟环境，在一个环境中生成的数据无法跨越到另一个环境。 下图显示了一个单一的生产环境，其中发布者可以创建他们的私有开发沙盒。只有授权的开发人员帐户或开发工具包才被允许访问这些沙盒。 图 1. 生产环境中的沙盒。 正如 PublisherA 有开发沙盒一样，其他发布者也有自己的开发沙盒。相同的 title ID 可能存在于不同的沙盒中，但为该 title ID 生成的数据在各个沙盒之间是不同的。 有两个系统沙盒只能由 Microsoft 填充：CERT 和 RETAIL。顾名思义，CERT 沙盒用于发布前正在经过认证的标题，而 RETAIL 沙盒代表真实美元的沙盒，可由所有零售用户和设备访问。 以前 title ID 在 XBOX Live 中是唯一的，现在 title ID 加上沙盒 ID 才是唯一的。这同样适用于产品 ID 和其他曾经被视为唯一的 ID 空间。它们现在必须与沙盒 ID 配对。XBOX Live 中的所有数据将在整个系统中主要按沙盒 ID 进行分区。

​

标题的初始设置

标题在 Partner Center 诞生。为标题分配了 title ID、product ID 和服务配置 ID (SCID)。 标题或产品本身对 XBOX Live 没有任何意义。为了支持单个标题同时在零售和开发中使用，Partner Center 支持标题的实例化，以便进行和维护必要的区分。标题的实例驻留在沙盒中，这就是沙盒的用武之地。 为了在 Partner Center 创建标题，发布者创建产品组，为产品组指定类型，然后在其中创建单个产品。 图 2. 产品组、产品、产品实例和沙盒之间的关系。

​

产品实例

产品实例是特定沙盒中标题、产品和配置数据的投影。此数据在以下三个方面描述：服务配置、目录元数据和二进制文件。

​

服务配置

服务配置定义（事件、统计信息、成就等）。服务配置在产品实例级别定义。

​

目录元数据

存在于目录中的元数据，包括销售文本、艺术资产、可用性/优惠信息、许可数据等。

​

二进制文件

二进制文件可以以下两种方式之一表示：

1. 仅元数据以启用旁加载。这包括内容 ID、版本信息和许可信息。
2. 传播到 CDN 并可供客户端下载的完整二进制文件。

​

获得正确的访问权限

在 XBOX One（或更高版本）中，对你内容的访问有两种不同的类型： 设计时访问——通过 Partner Center 从 PC 访问 - 允许在你产品上工作的人员上传、组织和使用内容、配置和元数据，但不允许他们运行或播放你产品的实例。 运行时访问——从 XBOX 主机访问 - 允许你的开发人员、测试人员、审阅者，最终允许你的客户运行和玩产品实例。 当我们谈论沙盒时，我们通常谈论的是对在 XBOX Live 上运行的内容的运行时访问。为了访问 XBOX Live 中的服务，需要 title ID。一旦 MicrosoftGame.config 包含 title ID，主机就会将 title ID 发送到 XBOX Live。除非主体（设备或用户）已被授予访问标题的权限，否则 XBOX Live 安全服务不会返回有效的令牌。 此验证过程是内容隔离的关键。从非常高的层面来看：

• 主体组可以包含 XBOX 用户 ID (XUID)、设备 ID、title ID 或 service ID。
• 沙盒可以包含 title ID、product ID 或 service config ID (SCID)。
• 授予主体组对沙盒的访问权限。

因此，对于用户或设备访问沙盒中的预发布标题，必须首先通过 Partner Center 授予访问权限。 图 3. 通过 Partner Center 设置访问权限的模型 内容隔离的有效性基于你的组织拥有以下流程的事实：

• 创建你的 Partner Center 用户帐户、每个用户将用于运行时访问登录的开发人员帐户，以及每个用户被授予成员资格的用户组。
• 创建受信任主机的设备组。
• 为你的每个开发沙盒精确指定哪些用户组和设备组可以访问其中的产品实例。

下图展示了此设置的一个示例。 图 4. 未经授权的用户凭据无法获得对沙盒的访问权限，授权的 Partner Center 用户帐户的普通凭据也无法获得访问权限。只有由授权的 Partner Center 用户帐户拥有的开发人员帐户的凭据才能成功获得对沙盒及其当前所有产品实例的运行时访问权限。

​

开发人员帐户设置

XBOX One（或更高版本）中的开发人员帐户只是应用了特殊规则的标准 Microsoft 帐户 (MSA)。开发人员帐户在 XBOX Live 中用于开发。 开发人员帐户：

• 必须在 Partner Center 创建。
• 在发布者创建时被分配外部开发人员角色。
• 绑定到创建该开发人员帐户的 Partner Center 帐户。
• 只能登录到开发工具包。开发人员帐户在零售设备上被拒绝登录。
• 可以购买 XBOX Live 开发人员金牌订阅或其他订阅以进行免费测试。

​

用户组设置

用户组是主体组的第一种类型，是 Partner Center 用户的集合。当 Partner Center 用户被添加到用户组时，他们的开发人员帐户也随这些 Partner Center 用户一起流转。 因此，当用户组被分配到沙盒时，与该用户组中的 Partner Center 用户关联的开发人员帐户将被添加到相应的主体组，并且主体组将获得支持沙盒的主要资源集的策略设置。

​

设备设置

设备也会被添加到主体组。只有通过 Game Developer Store 购买了权益并配置为开发工具包后，设备才可以用作开发工具包。 一旦设备被配置为开发工具包，该设备就会出现在可以添加到设备组的设备列表中。

​

设备组设置

设备组是主体组的第二种类型，也可以被授予对沙盒的访问权限。设置类似于上面详述的用户组设置。

​

沙盒

​

什么是沙盒？

简而言之，沙盒是在生产环境中对数据进行分区的一种方式。

​

为什么需要沙盒？

正如用户和设备访问标题一样，标题访问服务。我们引入”标题组”的概念，其中标题集被授予对服务资源的访问权限。 对于 XBOX One（或更高版本），所有内容（无论是预发布还是零售）都有一个单一的生产环境。因此，必须防止标题的多个实例（预发布/零售）在相同的资源实例上操作。

​

沙盒中有什么？

沙盒包含添加到沙盒中的每个标题的产品实例。

​

什么是沙盒 ID？

沙盒 ID 是标题、产品或服务配置的数据分区单位。多个标题可以存在于同一沙盒中，这是它们共享任何服务配置数据的先决条件。 沙盒 ID（区分大小写）是以下格式的字符串：<PublisherMoniker>.n。 下面解释了一个示例沙盒 ID XLDP.5：

• 发布者名称在所有发布者中是唯一的。因此，“XLPD”是这个特定发布者的发布者名称。发布者名称是在 Partner Center 中由开发人员客户经理”激活”发布者时创建的。
• 数字 “n” 标识沙盒的编号。在本例中，“5”是为该发布者创建的第六个沙盒。

当标题数据经过服务时，XBOX 服务使用沙盒 ID 唯一地标识所生成数据的”环境”。

​

什么数据被沙盒化？

下图显示了哪些用户和标题数据是沙盒化的。

​

全局覆盖沙盒

开发人员在开发工具包上设置沙盒 ID，从而设置开发工具包运行所在的沙盒；这也称为全局覆盖沙盒。因此，从开发工具包中的标题（shell 应用程序和常规应用程序）向 XBOX Live 服务（例如成就、匹配、许可、EDS 等）发出的所有请求都在该沙盒中进行。 全局覆盖沙盒还意味着在浏览时只有在全局覆盖沙盒中摄取的内容才可见。

​

沙盒类型

有两种不同类别的沙盒。这些类别的定义如下：

• 发布者沙盒。发布者可以访问他们的开发中沙盒。这些可能类似于 XLDP.0、XLDP.1、XLDP.2、XLDP.3 等。这是发布者放置其标题产品实例的地方。对这些沙盒的访问受限于发布者授予访问权限的用户/设备。
• Microsoft 沙盒。这些是内置沙盒：RETAIL 和 CERT。只有 Microsoft 被允许发布到这些受保护的沙盒。

​

CERT 沙盒

当标题准备好正式发布时，它需要首先经过认证。CERT 沙盒是由 Microsoft 控制的沙盒，只有认证部门的人员才能访问。发布者可以看到他们拥有的哪些内容正在经过认证。 任何在认证期间失败的产品实例都可以被带回开发沙盒，由发布者使用 Partner Center 进行调试和修复。

​

RETAIL 沙盒

RETAIL 沙盒是为 XBOX One（或更高版本）创建的所有内容的最终目的地。 标题通过认证后，将被添加到 RETAIL 沙盒。只允许绿色签名的内容在 RETAIL 沙盒中运行。这有一个重要的含义，即发布者驱动的 beta 也在 RETAIL 沙盒中进行。在 RETAIL 沙盒中生成的数据代表真实的客户生产数据。 对 RETAIL 沙盒中内容的访问仍然可以通过内容隔离进行控制。例如，发布者驱动的 beta 在 RETAIL 沙盒中运行，发布者选择哪些主体组可以访问发布者定义的 beta 资源集标题。beta 标题生成的服务数据是真实的 prod（生产）数据，在标题正式发布后继续存在。

​

跨沙盒数据交互

按照定义，沙盒是一个限制数据共享的容器。因此，跨沙盒数据交互是不可能的。

​

组织你的沙盒

本节提供了发布者如何组织沙盒的示例。发布者需要了解如何使用沙盒来组织数据。 以下示例仅显示了使用内容隔离的运行时访问管理。

​

场景 1：两个标题，一个沙盒

发布者的基本结构可以是：

• 两个标题，可由发布者拥有的所有用户和设备在设计时和运行时访问。
• 每个标题一个产品实例。

在这种情况下，发布者只需要一个沙盒来存放所有预发布内容。 下图显示了一个用户组。如果被认为更容易，发布者可以选择使用设备组而不是用户组。此外，此用户组对沙盒 XLDP.1 及其中的标题具有运行时和设计时访问权限。

​

场景 2：一个标题，不同团队

在此模型中，要求是：

• 一个标题。
• 开发团队处理每日构建。
• QA 团队处理每周 LKG。
• 开发团队在出现 bug 时需要调试每周 LKG。
• 财务团队需要访问与标题目录发布相关的价格卡和其他元数据。

下图显示 TitleX 有两个产品实例：PI-1 和 PI-2。产品实例必须在沙盒中，并且相同标题的两个产品实例不能位于同一沙盒中。因此，TitleX-PI-1 在沙盒 XLDP.1 中，TitleX-PI-2 在沙盒 XLDP.2 中。 开发用户组可以访问两个沙盒，而 QA 用户组只能访问沙盒 XLDP.2。 此外，财务用户（组 C）对 TitleX 具有设计时访问权限。由于财务用户组通常不会对标题进行任何运行时调试，因此将它们分开。

​

场景 3：两个标题，完全分开

在此示例中，要求略有变化：

• 两个标题。
• 对每个标题的访问应限于一组特定个人。
• 每个标题一个产品实例。
• 需要访问标题的设计时 Partner Center 配置数据的管理员用户组。此组中的个人都是发布者的管理员，可以控制发布到目录的所有数据（目录元数据、财务、营销、认证提交等）

在此模型中，发布者选择将两个标题完全分开，因此将这两个标题分配到两个不同的沙盒。发布者还选择创建一个单独的管理员用户组，并授予对这两个产品的访问权限。

​

场景 4：随你所愿

由于连接数量众多且为了保持文字简短，我们选择只显示沙盒运行时连接。没有什么阻止你添加其他设计时访问权限。 在此示例中，要求是：

• 只有某些人可以访问其发布者内的某些标题。
• 发布者与来自不同公司的供应商合作，这些供应商可能是短期的。
• 发布者应能够停用标题，并通过这样做防止访问供应商或 FTE 曾经访问的任何数据。

为了模拟此要求，可以采用如下结构。 遵循的模型为：

• TitleX 和 TitleY 在沙盒 XLDP.1 中各有一个产品实例。
• TitleZ 有两个产品实例，一个在沙盒 XLDP.2 中，另一个在沙盒 XLDP.3 中。
• FTE 用户组 B 被授予对所有沙盒中的产品实例的访问权限。
• 供应商用户组 A 是仅供应商用户组，被授予对沙盒 XLDP.1 的访问权限。
• 供应商设备组 C 是仅供应商用户组，被授予对沙盒 XLDP.3 的访问权限。

​

确定你的设备目标的沙盒

XBOX 服务 API 包含一个应用程序配置单例，允许你在运行时查看你的标题目标的沙盒。如果使用 GDK，则通过 XSystemGetXboxLiveSandboxId 完成。