Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comprendre les règles relatives aux indicateurs de fonctionnalités multivariantes

Lorsque vous créez une variante d'indicateur de fonctionnalité, vous spécifiez une règle pour celle-ci. Les règles sont des expressions qui prennent des valeurs de contexte en entrée et produisent un résultat booléen en sortie. Par exemple, vous pouvez définir une règle pour sélectionner une variante d'indicateur pour les utilisateurs bêta, identifiés par leur identifiant de compte, pour tester une actualisation de l'interface utilisateur. Dans ce scénario, vous devez effectuer les opérations suivantes :

Lors du AWS AppConfig traitement de la demande d'indicateur de fonctionnalité, il compare d'abord le contexte fourni, qui inclut le AccountId (pour cet exemple) à la BetaUsers variante. Si le contexte correspond à la règle pour BetaUsers, AWS AppConfig renvoie les données de configuration pour l'expérience bêta. Si le contexte n'inclut pas d'identifiant de compte ou si celui-ci se termine par une valeur autre que 123, AWS AppConfig renvoie les données de configuration pour la règle par défaut, ce qui signifie que l'utilisateur visualise l'expérience actuelle en production.

Comprendre l'opérateur de division

La section suivante décrit le comportement de l'splitopérateur lorsqu'il est utilisé dans différents scénarios. Pour rappel, split évalue à true un pourcentage donné du trafic sur la base d'un hachage cohérent de la valeur de contexte fournie. Pour mieux comprendre cela, considérez le scénario de référence suivant qui utilise la division en deux variantes :

A: (split by::$uniqueId pct::20)
C: <no rule>

Comme prévu, la fourniture d'un ensemble aléatoire de uniqueId valeurs produit une distribution approximative :

A: 20%
C: 80%

Si vous ajoutez une troisième variante, mais que vous utilisez le même pourcentage de division, comme suit :

A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::20)
C: <default>

Vous vous retrouvez avec la distribution suivante :

A: 20%
B: 0%
C: 80%

Cette distribution potentiellement inattendue se produit car chaque règle de variante est évaluée dans l'ordre et la première correspondance détermine la variante renvoyée. Lorsque la règle A est évaluée, 20 % des uniqueId valeurs y correspondent. La première variante est donc renvoyée. Ensuite, la règle B est évaluée. Cependant, toutes les uniqueId valeurs qui auraient pu correspondre à la deuxième instruction fractionnée correspondaient déjà à la règle de variante A, donc aucune valeur ne correspond à B. La variante par défaut est renvoyée à la place.

Prenons maintenant un troisième exemple.

A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::25)
C: <default>

Comme dans l'exemple précédent, les 20 % premières des uniqueId valeurs correspondent à la règle A. Pour la règle de variante B, 25 % de toutes les uniqueId valeurs correspondraient, mais la plupart de celles correspondant précédemment à la règle A. Cela laisse 5 % du total pour la variante B, le reste recevant la variante C. La distribution se présenterait comme suit :

A: 20%
B: 5%
C: 75%

Utilisation de la propriété de la graine

Vous pouvez utiliser cette seed propriété pour vous assurer que le trafic est réparti de manière cohérente pour une valeur de contexte donnée, quel que soit l'endroit où l'opérateur de division est utilisé. Si vous ne le spécifiez passeed, le hachage est cohérent localement, ce qui signifie que le trafic sera divisé de manière cohérente pour cet indicateur, mais d'autres indicateurs recevant la même valeur de contexte peuvent répartir le trafic différemment. Si elle seed est fournie, chaque valeur unique est garantie pour répartir le trafic de manière cohérente entre les indicateurs de fonctionnalités, les profils de configuration et Comptes AWS.

En règle générale, les clients utilisent la même seed valeur pour toutes les variantes d'un indicateur lorsqu'ils répartissent le trafic sur la même propriété de contexte. Cependant, il peut parfois être judicieux d'utiliser une valeur de départ différente. Voici un exemple qui utilise des graines différentes pour les règles A et B :

A: (split by::$uniqueId pct::20 seed::"seed_one")
B: (split by::$uniqueId pct::25 seed::"seed_two")
C: <default>

Comme précédemment, 20 % des uniqueId valeurs correspondantes correspondent à la règle A. Cela signifie que 80 % des valeurs échouent et sont testées par rapport à la règle de variante B. Comme la valeur de départ est différente, il n'y a aucune corrélation entre les valeurs correspondant à A et les valeurs correspondant à B. Il n'y a toutefois que 80 % des uniqueId valeurs à diviser, 25 % de ce nombre correspondant à la règle B et 75 % non. Cela correspond à la distribution suivante :

A: 20%
B: 20% (25% of what falls through from A, or 25% of 80%) 
C: 60%