Trafic în umbră și comparație

1) Ce este traficul Shadow și de ce este necesar

Traficul din umbră (oglindirea traficului/lansarea întunecată) este o „rulare” sigură a cererilor/evenimentelor reale către o nouă versiune a serviciului în paralel cu versiunea de producție fără a afecta utilizatorii. Rezultatele noii versiuni nu sunt returnate clientului și nu produc efecte secundare externe, ci sunt colectate într-un sistem de comparație.

• Verificarea compatibilității: scheme, contracte, logica de afaceri.
• Evaluarea performanței: latență, rezistență la sarcină reală.
• Detectarea driftului: diferențe în răspunsuri, distribuții, rata de eroare.
• Pregătirea pentru lansări canare: Reducerea riscului înainte de a comuta efectiv traficul.

• Rescrierea nucleului/algoritmilor, migrarea bazei de date/memoriei cache, trecerea la un alt runtime/SDK, schimbarea furnizorului API extern.

2) Modele arhitecturale de trafic umbră

2. 1 proxy/gateway L7 (HTTP/gRPC)

Proxy-ul acceptă cererea → oferă un răspuns de luptă din vechea versiune → oglindește asincron o copie a cererii într-o „umbră”.

Potrivit pentru API-uri sincrone.
Share/oglindire filtru de control: pe drum, antet, utilizator, chiriaș.

yaml route:
route:
cluster: prod-v1 request_mirror_policies:
- cluster: shadow-v2 runtime_fraction:
default_value:
numerator: 10 # 10% denominator: HUNDRED trace_sampled: true

nginx location /api/ {
proxy_pass http://prod_v1;
mirror/shadow; # request copy
}
location = /shadow {
internal;
proxy_pass http://shadow_v2; # answer ignored
}

2. 2 Autobuze pentru evenimente (Kafka/Threads)

• Producătorul scrie ca de obicei → consumatorii prod citi.
• În paralel, conducta umbră citește același flux într-o cutie de nisip separată.

Opțiuni: MirrorMaker/Replicator, dual-write (prudență), sursă → prod + poduri umbre.

2. 3 Replayer (înregistrare/joc)

Instantaneu de solicitări/trasee reale (acces PCAP/NGINX, robinete gRPC) → redarea la „umbra” într-un ritm controlat.

2. 4 „Umbră sintetică”

Generarea unui profil de încărcare din jurnalele de producție + faza de umplere a cazurilor de margine este utilă pentru restricțiile de confidențialitate.

3) Izolarea stării și a efectelor secundare

Regula de aur: umbra nu schimbă lumea exterioară.

Reed-on acces la baza de date/cache sau un sandbox separat (instantaneu/replica).
Interzicerea efectelor secundare de ieșire: plăți, scrisori, fluffs, carti web → ciot/blackhole/record-numai.
Command/POST idempotence: Shadow nu trebuie înregistrat ca o repetare a originalului.
PII/mascare secretă, jetoane furnizor de testare.

Exemplu: mascarea într-o oglindă

yaml shadowFilter:
headers:
redact:
- Authorization
- X-Api-Key body:
jsonPaths:
- replace "$ .email" # with token
- "$.card. number"

4) Strategii de eșantionare și încărcare sigură

Cota de trafic: 1-10% la start; crește dacă v2 se încadrează în buget.
Criterii de selecție: după traseu, utilizator, dimensiunea cererii, tipul de operare (GET-urile sunt mai sigure).
Bugetul Perf: oglindirea nu ar trebui să crească serviciul de luptă p95/p99. Umbra este întotdeauna asincronă.
Back-pressure: când lanțul de umbre se supraîncălzește, aruncați umbra, nu cereri de luptă.
Timp: Minim 24-72 ore pentru a acoperi pe diem și modele de vârf.

5) Compararea rezultatelor: metode și niveluri

5. 1 Niveluri de comparație

1. Byte diff: Corpul unui răspuns/eveniment unu-în-unu. Simplu, dar fragil (marcaje de timp, ordine cheie).
2. Diff semantic: normalizați și sortați câmpurile, ignorați epemeridele (traceId, marcajele de timp, contoarele).
3. Invarianți de afaceri: fie aceleași sume, statute, cantități, limite.
4. Analiza statistică: Se potrivesc distribuțiile metrice? (p50/p95, test KS, categoric χ ²).

5. 2 Politica de comparare

Măști/ignorați listele de câmpuri (de ex. „Actualizat”, „etag”).
Precizie: eroare absolută/relativă pentru numere (de exemplu ± 1e-6).

Benzile de toleranță: "diferența de preț ≤ 0. 01,” „nu mai mult de + 0 erori. 1% în raport cu prod'

Comparator pseudocod

pseudo compare(prod, shadow, policy):
a = normalize(prod, policy)
b = normalize(shadow, policy)
diffs = deepDiff(a, b, ignore=policy. ignore, floatTol=policy. floatTol)
invariants_ok = checkInvariants(a, b, policy. invariants)
return Result(diffs, invariants_ok)

5. 3 Compararea zapros↔otvet

ID-ul de corelare este necesar.
Se întinde link-ul: pista umbră devine legătură la luptă.

6) Observabilitate și artefacte de comparație

• 'shadow _ requests _ total {route,...}'
• 'shadow _ discrepancies _ total {type = byte' semantic 'invariant}'
• 'shadow _ error _ ratio' и 'shadow _ slo _ breach _ total'
• Perf: 'shadow _ latencies _ ms {p50, p95, p99}'
• Jurnale difuze: delte compacte JSON după cheie.
• Raportare: raport zilnic cu discrepanțe de top N, hărți termice pe rute/chiriași.
• UI „diff explorer”: filtre după tip, rută, câmp, export în CSV.

7) Ocazii speciale și subtilități

7. 1 Coerență și consecvență

Cererile de umbre pot veni mai târziu/mai devreme; normalizați la versiuni/ore (Lamport/vector) sau toleranțe la ferestre.
Read-after-write: o umbră cu citire-replica fără replicare sincronă va da răspunsuri diferite - compara prin ferestre lag.

7. 2 Cache/recomandări

Nu amestecați prod și cache umbră.
Pentru ML/recomandări, comparați metrica online și metrica offline separat; uita-te pentru drift caracteristici de intrare.

7. 3 Furnizori externi

Împachetați clienții în modul record/stub.
Pentru servicii de decontare (taxe, tarife) - fixați un instantaneu de directoare pentru ambele părți.

8) Canare juxtapunere/albastru-verde

Umbra: risc zero pentru utilizatori, dar fără efecte secundare reale; mare pentru logică și perf.
Canare: procent mic de răspunsuri reale din noua versiune; necesită o strategie de rollback gata și SLA.
Albastru-verde: comutare instantanee după validare; Umbra este adesea folosită în fața ei.

9) Planul de implementare (stil GitOps)

1. Obiective și valori: care invarianți și toleranțe verifică care SLO pentru discrepanțe.
2. Trace: Correlation-ID, link-uri de urme distribuite.
3. Configurație proxy: politica de oglindă, eșantionare, redactare.
4. Izolare: baza de date sandbox/cache, butuci laterale, chei de testare.
5. Comparator: normalizare, ignorarea hărților, invarianților, rapoartelor.
6. Planul de încărcare: începe de la 1-5%, creștere până la 20-50% cu metrici verzi.
7. Observabilitate: tablouri de bord „discrepanță/perf/volum”.
8. Criterii de ieșire: "0 discrepanțe critice 48 h", "erori nu mai rele decât prod'," perf în ± 5% ".
9. Treceți la canar: Includeți răspunsuri reale cu reguli de partajare și garda automată.

10) Exemple de configurare

10. 1 Istio (Oglindirea traficului)

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService spec:
hosts: ["svc. example"]
http:
- route: [{ destination: { host: svc, subset: v1 } }]
mirror:
host: svc subset: v2 mirrorPercentage:
value: 0. 1 # 10%

10. 2 Tee Kafka (schiță)

text source-topic -> prod-consumer-group
-> shadow-consumer-group (isolated sink/db)

10. 3 Reguli de comparație (politica yaml)

yaml ignoreFields:
- $.traceId
- $.meta. generatedAt floatTolerance:
default: 1e-6 fields:
$.price: 0. 01 invariants:
- name: "nonNegativeTotal"
expr: "$.total >= 0"
- name: "statusMapping"
expr: "map($.status in ['ok','fail'], true)"

11) Anti-modele

Shadow scrie: plăți reale/notificări din umbră.
Cache partajat/cozi partajate: impact încrucișat și contaminare.
Lipsa normalizării: difuzoarele octeților sunt „roșii” datorită ordinii ceasului/cheii.
Procent prea mare din mers: degradarea pen prod.
Lungă „umbră eternă”: al doilea sistem trăiește separat și se abate de la realitate.

12) Lista de verificare a lansării modului Shadow

• Proxy-ul este configurat cu o oglindă cu o partajare și o redactare.
• Shadow izolat: DB/caches/integrări externe - numai readonly/ciot.
• ID-ul de corelare este aruncat peste tot; urmele sunt legate.
• Comparatorul poate ignora/normaliza și verifica invarianții.
• Tablouri de bord și alerte pentru discrepanțe și sarcină.
• Prelevarea de probe pe rute/chiriași; limite și back-pressure.
• Toleranțele și criteriile luminii verzi sunt definite.
• Trecerea la planul canar/albastru-verde și rollback.

13) ÎNTREBĂRI FRECVENTE

Î: Cum este umbra diferită de A/B?
R: În A/B, ambele versiuni returnează răspunsuri utilizatorilor (experiment divizat), în Shadow noua versiune nu afectează utilizatorul - răspunsurile sale sunt doar analizate.

Î: Poate fi umbrit POST/PUT?
R: Da, dacă izolarea efectelor secundare (ciot) și idempotența sunt garantate. De multe ori începe cu GET, apoi extinde.

Î: Cum compar răspunsurile atunci când ordinea elementelor nu este fixă?
R: Sortați după tasta stabilă înainte de a compara sau compara ca seturi/după chei.

Î: Ce se poate face cu întârzieri de replica bazei de date?
R: Introduceți „ferestre de comparare” și instantanee de carte de referință; Rezultate agregate după versiune, mai degrabă decât după ora de perete.

14) Totaluri

Traficul din umbră este o „repetiție nedureroasă a producției”: sarcină reală, risc zero pentru utilizatori, analiză detaliată a discrepanțelor. Succesul este determinat de izolare, eșantionare corectă, comparator de calitate și observabilitate. In urma planului propus, vei obtine o practica reproductibila, care pune cu incredere pasul pe calea eliberarilor canare/albastru-verde si accelereaza evolutia arhitecturii.