View a markdown version of this page

Informazioni sulle regole relative ai contrassegni delle funzionalità con più varianti - AWS AppConfig
Comprendere l'operatore di divisione

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Informazioni sulle regole relative ai contrassegni delle funzionalità con più varianti

Quando crei una variante di feature flag, ne specifichi una regola. Le regole sono espressioni che accettano valori di contesto come input e producono un risultato booleano come output. Ad esempio, potresti definire una regola per selezionare una variante di bandiera per gli utenti beta, identificata dal relativo ID account, testando un aggiornamento dell'interfaccia utente. Per questo scenario, procedi come segue:

  1. Create un nuovo profilo di configurazione del Feature Flag chiamato UI Refresh.

  2. Create un nuovo feature flag chiamato ui_refresh.

  3. Modifica il contrassegno della funzionalità dopo averlo creato per aggiungere varianti.

  4. Crea e abilita una nuova variante denominata BetaUsers.

  5. Definisci una regola per BetaUsers selezionare la variante se l'ID dell'account nel contesto della richiesta si trova in un elenco di ID account approvati per visualizzare la nuova esperienza beta.

  6. Verifica che lo stato della variante predefinita sia impostato su Disabilitato.

Nota

Le varianti vengono valutate come un elenco ordinato in base all'ordine in cui sono definite nella console. La variante in cima all'elenco viene valutata per prima. Se nessuna regola corrisponde al contesto fornito, AWS AppConfig restituisce la variante predefinita.

Quando AWS AppConfig elabora la richiesta di feature flag, confronta innanzitutto il contesto fornito, che include l'AccountID (per questo esempio) con la BetaUsers variante. Se il contesto corrisponde alla regola di BetaUsers, AWS AppConfig restituisce i dati di configurazione per l'esperienza beta. Se il contesto non include un ID account o se l'ID dell'account termina con un valore diverso da 123, AWS AppConfig restituisce i dati di configurazione per la regola predefinita, il che significa che l'utente visualizza l'esperienza corrente in produzione.

Nota

Per informazioni sul recupero dei flag di funzionalità con più varianti, consulta. Recupero dei flag delle funzionalità di base e con più varianti

Comprendere l'operatore di divisione

La sezione seguente descrive come si comporta l'splitoperatore quando viene utilizzato in diversi scenari. Come promemoria, split restituisce una determinata percentuale di traffico in base a true un hash coerente del valore di contesto fornito. Per comprenderlo meglio, considera il seguente scenario di base che utilizza la divisione con due varianti:

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

Come previsto, la fornitura di un set casuale di uniqueId valori produce una distribuzione approssimativamente:

A: 20%
C: 80%

Se aggiungi una terza variante, ma usi la stessa percentuale di divisione in questo modo:



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

Ti ritroverai con la seguente distribuzione:

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

Questa distribuzione potenzialmente inaspettata si verifica perché ogni regola di variante viene valutata in ordine e la prima corrispondenza determina la variante restituita. Quando viene valutata la regola A, il 20% dei uniqueId valori corrisponde, quindi viene restituita la prima variante. Successivamente, viene valutata la regola B. Tuttavia, tutti i uniqueId valori che avrebbero dovuto corrispondere alla seconda istruzione split erano già corrispondenti alla regola variante A, quindi nessun valore corrisponde a B. Viene invece restituita la variante predefinita.

Consideriamo ora un terzo esempio.

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

Come nell'esempio precedente, il primo 20% dei uniqueId valori corrisponde alla regola A. Per la variante B, il 25% di tutti i uniqueId valori corrisponderebbe, ma la maggior parte di quelli precedentemente corrisponderebbe alla regola A. Rimane il 5% del totale per la variante B, mentre il resto riceverebbe la variante C. La distribuzione sarebbe simile alla seguente:

A: 20%
B: 5%
C: 75%
Utilizzo della proprietà seed

È possibile utilizzare la seed proprietà per garantire che il traffico venga suddiviso in modo coerente per un determinato valore di contesto indipendentemente da dove viene utilizzato l'operatore di divisione. Se non lo specifichiseed, l'hash è coerente a livello locale, il che significa che il traffico verrà suddiviso in modo coerente per quel flag, ma altri flag che ricevono lo stesso valore di contesto potrebbero suddividere il traffico in modo diverso. Se seed viene fornito, è garantito che ogni valore univoco ripartirà il traffico in modo coerente tra flag di funzionalità, profili di configurazione e. Account AWS

In genere, i clienti utilizzano lo stesso seed valore tra le varianti all'interno di un flag quando suddividono il traffico sulla stessa proprietà di contesto. Tuttavia, occasionalmente può avere senso utilizzare un valore iniziale diverso. Ecco un esempio che utilizza semi diversi per le regole A e B:

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

Come in precedenza, il 20% dei uniqueId valori corrispondenti corrisponde alla regola A. Ciò significa che l'80% dei valori corrisponde e viene testato in base alla regola variante B. Poiché il seme è diverso, non esiste alcuna correlazione tra i valori corrispondenti ad A e i valori che corrispondono a B. Tuttavia, vi è solo l'80% dei uniqueId valori da dividere, con il 25% di quel numero che corrisponde alla regola B e il 75% no. Ciò si traduce nella seguente distribuzione:

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