了解多变体功能标志规则
在创建功能标志变体时，可以为其指定规则。规则是将上下文值作为输入并生成布尔结果作为输出的表达式。例如，可以定义一条规则来为测试版用户（由其账户 ID 标识）选择标志变体，同时测试用户界面刷新。对于此场景，请执行以下操作：
-
创建一个名为 UI Refresh 的新功能标志配置文件。
-
创建一个名为 ui_refresh 的新功能标志。
-
在创建功能标志后，对其进行编辑来添加变体。
-
创建并启用名为 BetaUsers 的新变体。
-
为 BetaUsers 定义一条规则，如果请求上下文中的账户 ID 位于获准查看新测试版体验的账户 ID 列表中，此规则将选择该变体。
-
确认默认变量的状态设置为禁用。
注意
根据在控制台中定义的顺序，将变体作为有序列表进行评估。将首先评估列表顶部的变体。如果没有规则与提供的上下文匹配，则 Amazon AppConfig 返回默认变体。
在 Amazon AppConfig 处理功能标志请求时，它首先将提供的上下文 [包括 AccountID（对于本示例] 与 BetaUsers 变体进行比较。如果上下文与 BetaUsers 的规则相匹配，Amazon AppConfig 返回测试版体验的配置数据。如果上下文不包含账户 ID 或者账户 ID 以 123 之外的任意值结尾，则 Amazon AppConfig 返回默认规则的配置数据，这意味着用户会在生产环境中看到当前体验。
注意
有关检索多变量功能标志的信息，请参阅 检索基本和多变体功能标志。
理解拆分运算符
以下部分描述了 split 运算符在不同场景中使用时的行为。提醒一下，split 基于所提供上下文值的一致哈希，对给定百分比的流量评估为 true。为了更好地理解这一点，请考虑以下使用拆分运算符和两个变量的基准场景：
A: (split by::$uniqueId pct::20) C: <no rule>
正如预期的那样，提供一组随机的 uniqueId 值会产生大约如下的分布：
A: 20% C: 80%
如果您添加第三个变量，但使用相同的拆分百分比，如下所示：
A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::20) C: <default>
您将得到以下分布：
A: 20% B: 0% C: 80%
这种可能出乎意料的分布之所以发生，是因为每个变量规则按顺序评估，且第一个匹配项就决定了返回的变量。当规则 A 被评估时，20% 的 uniqueId 值与其匹配，因此返回第一个变量。接着，评估规则 B。然而，所有本应匹配第二个拆分语句的 uniqueId 值已被变量规则 A 匹配，因此没有值匹配 B。系统转而返回默认变量。
现在考虑第三个例子。
A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::25) C: <default>
与上一个例子类似，前 20% 的 uniqueId 值匹配规则 A。对于变量规则 B，全部 uniqueId 值中的 25% 本应匹配，但其中大部分先前已匹配规则 A。这导致变量 B 仅分配到总量的 5%，其余部分则接收变量 C。分布将如下所示：
A: 20% B: 5% C: 75%
使用 seed 属性
您可以使用 seed 属性来确保对于给定的上下文值，无论拆分运算符在何处使用，流量拆分都能保持一致。如果您不指定 seed，则哈希值是本地一致的，这意味着该标志的流量将被一致地拆分，但接收相同上下文值的其它标志可能会以不同的方式拆分流量。如果提供了 seed，则每个唯一值都可以保证在功能标志、配置文件和 Amazon Web Services 账户之间一致地拆分流量。
通常，客户在对同一上下文属性进行流量拆分时，会在一个标志内的各个变量间使用相同的 seed 值。然而，有时使用不同的种子值可能更有意义。以下是一个对规则 A 和 B 使用不同种子值的示例：
A: (split by::$uniqueId pct::20 seed::"seed_one") B: (split by::$uniqueId pct::25 seed::"seed_two") C: <default>
如前所述，20% 的匹配 uniqueId 值匹配规则 A。这意味着 80% 的值会落入后续流程，并针对变量规则 B 进行测试。由于种子值不同，匹配 A 的值与匹配 B 的值之间没有关联。然而，此时仅剩下 80% 的 uniqueId 值用于拆分，其中 25% 匹配规则 B，75% 不匹配。最终计算出以下分布：
A: 20% B: 20% (25% of what falls through from A, or 25% of 80%) C: 60%