高级 Xbox 服务沙盒
另请参阅 Xbox 服务沙盒概述。
Xbox Live Sandboxes（沙盒）为开发提供了整个专用环境。 本文将介绍什么是沙盒，它们存在的原因，如何适用于发布者，以及如何影响内部 Xbox 团队。 本文的目标受众是构建 Xbox One （或更高版本）内容和使用沙盒的发布者。
Xbox Live 开发为发布者提供了巨大的机会，让他们在生产中可以使用生产质量服务和生产 MSA 开发者帐户进行测试。 为了提升功能和灵活性，需要执行合作伙伴中心中的配置步骤，以在开发和公开发行时创建游戏数据，并管理对游戏的访问。
沙盒是分隔生产中的数据的一种方法。 由于所有内容都承载于单个生产环境中，所以沙盒充当的是“虚拟环境”，而且在一个环境中生成的数据无法跨越到另一个环境中。
隔离 Xbox Live 上的内容
在 Xbox Live 中，只有一个生产环境，所有预发行版（开发版和 Beta 版）、证书以及零售内容均驻留在此环境中。
内容隔离可确保发布者内容不在生产中泄露。 在本质上，内容隔离可以确保任何请求资源访问权限的主体用户、设备或游戏（游戏或服务）都有权访问资源。 通过内容隔离，分区被分成沙盒，其中存储游戏或服务数据；授权策略在沙盒范围内定义。
沙盒是分隔生产中数据的一种方法。
使用 Xbox 360-era 服务时，PartnerNet 和 ProductionNet 是两种截然不同的环境。
借助 Xbox One （或更高版本）服务，单个生产环境可包含 n 个独特的虚拟环境，其中每个虚拟环境都称为沙盒。
由于所有内容都承载于单个生产环境中，所以沙盒实际上是独特的虚拟环境，而且在一个环境中生成的数据无法跨越到另一个环境。
下图展示了发布者可以在其中创建专用开发沙盒的单个生产环境。 仅授权开发者帐户或开发者工具包能够访问这些沙盒。
图 1. 生产环境中的沙盒。
正如 PublisherA 拥有开发沙盒一样，其他发布者也拥有其各自的开发沙盒。 同一个游戏 ID 可能驻留在不同的沙盒中，但是沙盒内根据游戏 ID 生成的数据是不同的。
有两种系统沙盒只能由 Microsoft 填充，它们是：CERT 和 RETAIL。 顾名思义，CERT 沙盒适用于在发行前进行认证的游戏，而 RETAIL 沙盒是表示所有零售用户和设备均可访问的产生实际收入的沙盒。
之前在 Xbox Live 中游戏 ID 是唯一的，而现在游戏 ID 及沙盒 ID 是唯一的。 上述情况也适用于曾被视为唯一的产品 ID 和其他 ID 空间。 它们现在必须与沙盒 ID 配对。 将按照沙盒 ID 将 Xbox Live 中的所有数据在整个系统中进行分区。
游戏的初始设置
游戏诞生于合作伙伴中心。 为游戏分配一个游戏 ID、一个产品 ID 和一个服务配置 ID (SCID)。
游戏或产品本身对 Xbox Live 而言没有意义。 为了支持单个游戏的同步零售和开发，合作伙伴中心支持游戏实例化，以做出并保持必要的区分。 游戏实例驻留在沙盒中，这就是沙盒发挥作用的地方。
为了在合作伙伴中心创建游戏，发布者将创建一个产品组，指定产品组的类型，然后在其中创建个人产品。
图 2. 产品组、产品、产品实例以及沙盒之间的关系。
产品实例
产品实例是对某一特定沙盒中的游戏、产品和配置数据的一种投射。 此数据将从以下三方面进行描述：服务配置、目录源数据和二进制文件。
服务配置
服务配置定义（事件、统计数据、成就等）。 此服务配置是在产品实例级别定义的。
目录元数据
位于目录中的元数据包括销售文本、艺术资源、可用性/优惠信息、许可数据以及更多。
二进制文件
二进制文件可以以下两种方式中的一种呈现：
元数据仅用于启用旁加载。 这包括内容 ID、版本信息及许可信息。
整个二进制文件将被填充到 CDN，并且可供客户端下载。
获取访问权
针对 Xbox One（或更高版本）中的内容，有两种不同的访问类型：
设计时访问 — 通过合作伙伴中心从 PC 端访问 — 允许人们操作您的产品以上传、整理以及使用内容、配置和元数据，但不允许他们运行或操作产品实例。
运行时访问 — 从 Xbox 主机访问— 允许开发者、测试人员以及客户运行和操作 Product Instance（产品实例）。
注意
为了能够进行运行时访问，必须将产品实例置于沙盒中。 将生成的产品实例置于沙盒中后，有权访问该沙盒的合作伙伴中心用户或开发者工具包设备便可以运行该实例。 为执行此操作，它们使用自己的某个开发帐户，通过 Xbox 控制台登录到合作伙伴中心，这些帐户是特殊帐户，可充当用于运行时访问的虚拟用户。
当我们谈及沙盒时，我们通常都是在谈论对在 Xbox Live 上运行的内容的运行时访问。 访问 Xbox Live 中的服务时，需要游戏 ID。 MicrosoftGame 包含了游戏 ID 后，控制台会将游戏 ID 发送到 Xbox Live。 只有当相关主体（设备或用户）获得游戏访问权限时，Xbox Live 安全服务才会返回有效的令牌。
此验证过程是内容隔离的关键。 从非常高的层面来看：
主体组可以包括 Xbox ID (XUID)、设备 ID、游戏 ID 以及服务 ID。
沙盒可以包括游戏 ID、产品 ID 或服务配置 ID (SCID)。
主体组有权访问沙盒。
因此，用户或设备若想访问沙盒中的预发行游戏，则必须首先通过合作伙伴中心获得访问权限。
图 3. 通过合作伙伴中心设置访问权限的模型
内容隔离的有效性基于您的组织拥有以下流程这一事实：
创建合作伙伴中心用户帐户、每个用户用来登录以进行运行时访问的开发者帐户，以及均有成员资格的用户组成的用户组。
创建受信任主机的设备组。
针对每个开发沙盒进行精确指定，而用户组和设备组有权访问其中的产品实例。
此设置的示例在下图中进行了说明。
图 4. 未经授权的用户的凭据无法访问沙盒，授权的合作伙伴中心用户帐户的普通凭据也是如此。 只有授权的合作伙伴中心用户帐户所拥有的开发者帐户凭据才能成功地对沙盒进行运行时访问，以及对该沙盒当前包含的所有产品实例进行访问。
开发者帐户设置
Xbox One（或更高版本）中的开发帐户就是应用了特殊规则的标准 Microsoft 帐户 (MSA)。 开发者帐户在 Xbox Live 中用于开发。
开发者帐户：
必须在合作伙伴中心创建。
被分配外部开发者角色（如果由发布者创建）。
与创建开发者帐户的合作伙伴中心帐户相关联。
只能登录到开发者工具包。 不能在零售设备上登录到开发者帐户。
可以免费购买 Xbox Live 开发者金会员订阅或其他订阅以进行测试。
用户组设置
用户组，即第一种主体组，是合作伙伴中心用户的集合。 将合作伙伴中心用户添加到用户组后，其开发者帐户将与这些合作伙伴中心用户一起流动。
因此，在将用户组分配到沙盒后，将与该用户组中的合作伙伴中心用户关联的开发者帐户添加到相应的主体组中，并使用设置回该沙盒的主要资源集为这些主体组设置策略。
注意
为访问沙盒而创建的用户组就是用于阻止访问产品组和产品的合作伙伴中心中的配置数据的用户组。
设备设置
设备也将被添加到主体组。 如果通过游戏开发者应用商店购买权利，并将设备预配为开发者工具包，则该设备只能用作开发者工具包。
设备一旦预配为开发者工具包，就会显示在可添加到设备组的设备列表中。
设备组设置
设备组，即第二种主体组，也可以获得沙盒访问权限。 其设置与上面详述的用户组设置类似。
沙盒
什么是沙盒？
简而言之，沙盒是分隔生产中的数据的一种方法。
我们为什么需要沙盒？
正如用户和设备访问游戏一样，游戏可以访问服务。 我们引入了“游戏组”的概念，相当于向成组的游戏授予对服务资源的访问权限。
Xbox One（或更高版本）的所有内容，不管是预发布版还是零售版，均使用同一个生产环境。 因此，需要防止游戏的多个实例（预发布/零售）在相同的资源实例上运行。
沙盒中有什么？
沙盒包含添加到沙盒中的每个游戏的产品实例。
什么是沙盒 ID？
沙盒 ID 是作品、产品或服务配置数据的分隔单元。多个作品可以位于同一个沙盒中，这是这些作品可以共享任何服务配置数据的先决条件。
沙盒 ID（区分大小写）是采用以下格式的字符串：<PublisherMoniker>.n。
例如，沙盒 ID XLDP.5 的说明如下：
发布者名字对象在所有发布者中是唯一的。 因此，“XLPD”是此特定发布者的名字对象。 当开发人员帐户管理器在合作伙伴中心中“激活”某个发布者后，就会创建对应的发布者名字对象。
数字“n”标识沙盒的数目。 在这种情况下，“5”是指为此发布者创建的第六个沙盒。
当游戏数据在各服务中移动时，Xbox 服务使用沙盒 ID 来唯一标识为数据生成的“环境”。
什么是沙盒化数据？
下图显示了哪些用户和游戏数据可实现沙盒化。
全局替代沙盒
由于开发者在开发者工具包中设置沙盒 ID，因此，可以设置在其中运行该开发者工具包的沙盒；这也称为全局替代沙盒。 因此，从开发者工具包中的所有游戏（shell 应用和常规应用）向 Xbox Live 服务（例如，成就、匹配、许可和 EDS 等）发出的所有请求都是在该沙盒中发出的。
全局替代沙盒还意味着，只有全局替代沙盒中引入的内容才在浏览时可见。
沙盒类型
有两种不同类别的沙盒。 这些类别的定义如下：
发布者沙盒。 发布者可访问其开发中的沙盒。 这些沙盒可能看起来像 XLDP.0、XLDP.1、XLDP.2、XLDP.3 等。这是发布者放置其游戏产品实例的位置。 对于发布者向其授予访问权限的用户/设备来说，其对这些沙盒的访问受到限制。
Microsoft 沙盒。 这些是内置沙盒：RETAIL 和 CERT。只有 Microsoft 才能发布到这些受保护的沙盒。
CERT 沙盒
如果游戏已准备好公开发行，则首先需要进行认证。 CERT 沙盒是 Microsoft 控制的沙盒，只有认证中的个人用户才能访问该沙盒。 发布者可以查看他们拥有的哪些内容将进行认证。
在认证过程中失败的产品实例可被返回至开发沙盒，由发布者使用合作伙伴中心进行调试和修复。
RETAIL 沙盒
RETAIL 沙盒是为 Xbox One（或更高版本）创建的所有内容的最终目的地。
游戏通过认证后，就会添加到 RETAIL 沙箱中。 只有绿色签名内容才能在 RETAIL 沙盒中运行。 这暗示着发布者驱动的 Beta 版也是在 RETAIL 沙盒中完成的。 在 RETAIL 沙盒中生成的数据其实是客户生产数据。
您仍然可以通过内容隔离来控制对 RETAIL 沙盒中内容的访问权限。 例如，发布者驱动的 Beta 版在 RETAIL 沙盒中运行，其中，发布者可以选择哪些主体组有权访问发布者定义的 Beta 版资源集游戏。 由 Beta 版游戏生成的服务数据其实是生产数据，这些数据在游戏公开发行后依然存在。
跨沙盒数据交互
按照定义，沙盒是限制数据共享的容器。 因此，跨沙盒数据交互是不可能的。
组织您的沙盒
此部分提供了发布者如何组织沙盒的示例。 发布者需要了解如何使用沙盒组织数据。
下面的示例仅说明了如何使用内容隔离管理运行时访问。
场景 1：两个游戏、一个沙盒
对于发布者，基本结构可能是：
两个游戏，可供发布者拥有的所有用户和设备进行设计时和运行时访问。
一个游戏对应一个产品实例。
在这种情况下，发布者只需对所有预发行版内容使用单个沙盒即可。
下图显示了用户组。 发布者可以选择使用设备组而非用户组（如果更容易）。 另外，此用户组有权对沙盒 XLDP.1 和此沙盒中的游戏进行运行时和设计时访问。
场景 2：一个游戏、不同的团队
在这种模型中，要求如下：
一个游戏。
开发者团队负责每天生成版本。
QA 团队负责处理每周 LKG。
如果出现错误，开发者团队需要调试每周 LKG。
财务团队需要访问与游戏的目录发布有关的价格卡和其他元数据。
下图显示了 TitleX 有两个产品实例：PI-1 和 PI 2。 产品实例必须位于沙盒中，而且同一游戏的两个产品实例不能位于同一个沙盒中。 因此，TitleX-PI-1 位于沙盒 XLDP.1 中，而 TitleX-PI-2 位于沙盒 XLDP.2 中。
开发者用户组可以访问这两个沙盒，而 QA 用户组只能访问沙盒 XLDP.2。
此外，财务用户（组 C）可对 TitleX 进行设计时访问。 由于财务用户组通常不需要对游戏执行任何运行时调试，因此会被分离出来。
注意
不论组织如何，合作伙伴中心用户都可以属于多个用户组。
场景 3：两个游戏，完全独立
在此示例中，要求略有不同：
两个游戏。
对每个游戏的访问应限定于某些个人。
一个游戏对应一个产品实例。
需要访问游戏的设计时合作伙伴中心配置数据的管理员用户组。 此组中的用户都是发布者的管理员，可以控制发布到目录（目录元数据、财务、营销、认证提交等）的所有数据。
在此模型中，发布者已选择使这两个游戏完全保持独立，因而将这两个游戏分配到两种不同的沙盒中。 发布者还选择了创建单独的管理员用户组，并分配了两个产品的访问权限。
场景 4：您喜欢的任何方式
由于连接数较多，因此，为了简单起见，我们选择了仅显示沙盒运行时连接。 您还可以自由添加其他设计时访问权限。
在此示例中，要求如下：
只有某些用户才能访问其发布者的某些游戏。
发布者与来自不同公司的供应商合作。这些供应商可能是短期合作伙伴。
发布者应该能够解除游戏授权，以此阻止访问供应商或 FTE 曾经可以访问的任何数据。
为了对此要求建模，可以采用如下结构。
该模型如下：
TitleX 和 TitleY 在沙盒 XLDP.1 中只能各有一个产品实例。
TitleZ 有两个产品实例，一个位于沙盒 XLDP.2 中，而另一个位于沙盒 XLDP.3 中。
FTE 用户组 B 可访问所有沙盒中的产品示例。
供应商用户组 A 是仅限供应商的用户组，可访问沙盒 XLDP.1。
供应商设备组 C 是仅限供应商的用户组，可访问沙盒 XLDP.3。
确定您的设备面向的沙盒
Xbox 服务 API 包含应用配置单一实例，可通过它在运行时查看游戏所面向的沙箱。 如果使用 GDK，则通过 XSystemGetXboxLiveSandboxId 来完成。