Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Grundlegendes zu Feature-Flag-Regeln mit mehreren Varianten
Wenn Sie eine Feature-Flag-Variante erstellen, geben Sie eine Regel dafür an. Regeln sind Ausdrücke, die Kontextwerte als Eingabe verwenden und als Ausgabe ein boolesches Ergebnis erzeugen. Sie könnten beispielsweise eine Regel definieren, um eine Flag-Variante für Beta-Benutzer auszuwählen, die anhand ihrer Konto-ID identifiziert werden, um eine Aktualisierung der Benutzeroberfläche zu testen. Für dieses Szenario gehen Sie wie folgt vor:
-
Erstellen Sie ein neues Feature-Flag-Konfigurationsprofil mit dem Namen UI Refresh.
-
Erstellen Sie ein neues Feature-Flag namens ui_refresh.
-
Bearbeiten Sie das Feature-Flag, nachdem Sie es erstellt haben, um Varianten hinzuzufügen.
-
Erstellen und aktivieren Sie eine neue Variante mit dem Namen BetaUsers.
-
Definieren Sie eine Regel, die die Variante auswählt BetaUsers, wenn die Konto-ID aus dem Anforderungskontext in einer Liste von Konto-IDs enthalten ist, die für die Nutzung der neuen Betaversion genehmigt wurden.
-
Vergewissern Sie sich, dass der Status der Standardvariante auf Deaktiviert gesetzt ist.
Anmerkung
Varianten werden anhand der Reihenfolge, in der sie in der Konsole definiert sind, als geordnete Liste ausgewertet. Die Variante, die oben in der Liste steht, wird zuerst ausgewertet. Wenn keine Regeln dem angegebenen Kontext entsprechen, wird die Standardvariante AWS AppConfig zurückgegeben.
Bei AWS AppConfig der Verarbeitung der Feature-Flag-Anforderung wird zuerst der angegebene Kontext, der die AccountID (für dieses Beispiel) enthält, mit der BetaUsers Variante verglichen. Wenn der Kontext der Regel für entspricht BetaUsers, werden die Konfigurationsdaten für das Beta-Erlebnis AWS AppConfig zurückgegeben. Wenn der Kontext keine Konto-ID enthält oder wenn die Konto-ID auf etwas anderes als 123 endet, werden die Konfigurationsdaten für die Standardregel AWS AppConfig zurückgegeben, was bedeutet, dass der Benutzer das aktuelle Erlebnis in der Produktion betrachtet.
Anmerkung
Hinweise zum Abrufen von Feature-Flags mit mehreren Varianten finden Sie unter. Abrufen grundlegender und variantenreicher Feature-Flags
Den Split-Operator verstehen
Im folgenden Abschnitt wird beschrieben, wie sich der split Operator verhält, wenn er in verschiedenen Szenarien verwendet wird. Zur Erinnerung: Berechnet split true für einen bestimmten Prozentsatz des Datenverkehrs auf der Grundlage eines konsistenten Hashwerts des angegebenen Kontextwerts bis. Um dies besser zu verstehen, sollten Sie das folgende Basisszenario betrachten, das Split mit zwei Varianten verwendet:
A: (split by::$uniqueId pct::20) C: <no rule>
Wie erwartet ergibt die Angabe eines zufälligen Satzes von uniqueId Werten eine Verteilung, die ungefähr wie folgt aussieht:
A: 20% C: 80%
Wenn Sie eine dritte Variante hinzufügen, aber den gleichen Teilungsprozentsatz wie folgt verwenden:
A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::20) C: <default>
Am Ende hast du die folgende Verteilung:
A: 20% B: 0% C: 80%
Diese potenziell unerwartete Verteilung ist darauf zurückzuführen, dass jede Variantenregel der Reihe nach ausgewertet wird und die erste Übereinstimmung die zurückgegebene Variante bestimmt. Wenn Regel A ausgewertet wird, stimmen 20% der uniqueId Werte mit ihr überein, sodass die erste Variante zurückgegeben wird. Als Nächstes wird Regel B ausgewertet. Alle uniqueId Werte, die mit der zweiten Split-Anweisung übereinstimmen würden, wurden jedoch bereits mit Variantenregel A abgeglichen, sodass keine Werte mit B übereinstimmen. Stattdessen wird die Standardvariante zurückgegeben.
Betrachten Sie nun ein drittes Beispiel.
A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::25) C: <default>
Wie im vorherigen Beispiel entsprechen die ersten 20% der uniqueId Werte Regel A. Bei Variantenregel B würden 25% aller uniqueId Werte übereinstimmen, aber die meisten der zuvor erfüllten Werte für Regel A. Somit bleiben 5% der Gesamtsumme für Variante B übrig, während der Rest Variante C erhält. Die Verteilung würde wie folgt aussehen:
A: 20% B: 5% C: 75%
Verwendung der
Sie können die seed Eigenschaft verwenden, um sicherzustellen, dass der Verkehr für einen bestimmten Kontextwert konsistent aufgeteilt wird, unabhängig davon, wo der Split-Operator verwendet wird. Wenn Sie dies nicht angebenseed, ist der Hash lokal konsistent, was bedeutet, dass der Verkehr für dieses Flag konsistent aufgeteilt wird. Andere Flags, die denselben Kontextwert erhalten, können den Verkehr jedoch unterschiedlich aufteilen. Wenn angegeben, seed wird garantiert, dass jeder eindeutige Wert den Datenverkehr konsistent auf Feature-Flags, Konfigurationsprofile usw. aufteilt AWS-Konten.
In der Regel verwenden Kunden den gleichen seed Wert für alle Varianten innerhalb eines Flags, wenn sie den Traffic für dieselbe Kontexteigenschaft aufteilen. Gelegentlich kann es jedoch sinnvoll sein, einen anderen Startwert zu verwenden. Hier ist ein Beispiel, das unterschiedliche Startwerte für die Regeln A und B verwendet:
A: (split by::$uniqueId pct::20 seed::"seed_one") B: (split by::$uniqueId pct::25 seed::"seed_two") C: <default>
Wie zuvor entsprechen 20% der übereinstimmenden uniqueId Werte Regel A. Das bedeutet, dass 80% der Werte durch die Variantenregel B fallen und anhand dieser getestet werden. Da der Startwert unterschiedlich ist, besteht keine Korrelation zwischen den Werten, die mit A übereinstimmen, und den Werten, die mit B übereinstimmen. Es müssen jedoch nur 80% so viele uniqueId Werte geteilt werden, wobei 25% dieser Zahl mit Regel B übereinstimmen und 75% nicht. Das ergibt die folgende Verteilung:
A: 20% B: 20% (25% of what falls through from A, or 25% of 80%) C: 60%
