Ruch cieni i porównanie

1) Co to jest ruch cień i dlaczego jest potrzebny

Ruch cieni (np. lusterko ruchu/ciemne uruchomienie) jest bezpiecznym „biegiem” rzeczywistych żądań/zdarzeń do nowej wersji usługi równolegle z wersją produkcyjną bez wpływu na użytkowników. Wyniki nowej wersji nie są zwracane klientowi i nie powodują zewnętrznych skutków ubocznych, ale są gromadzone w systemie porównawczym.

• Sprawdzanie zgodności: programy, umowy, logika biznesowa.
• Ocena wydajności: opóźnienie, rezystancja pod rzeczywistym obciążeniem.
• Wykrywanie dryfów: różnice w odpowiedziach, rozkładzie, częstości błędów.
• Przygotowanie do wydania kanaryjskiego: Zmniejszenie ryzyka przed faktyczną zmianą ruchu.

• Przepisywanie jądra/algorytmów, migracja bazy danych/pamięci podręcznej, przełączanie na inny czas trwania/SDK, zmiana dostawcy zewnętrznego interfejsu API.

2) Wzory architektoniczne ruchu cieni

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

Proxy akceptuje żądanie → daje odpowiedź bojową ze starej wersji → asynchronicznie odzwierciedla kopię żądania w „cień”.

Nadaje się do synchronicznych API.
Kontrola filtra udostępniania/lustrzanego: w drodze, nagłówek, użytkownik, najemca.

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 autobusy imprezowe (Kafka/Wątki)

• Producent pisze jak zwykle → prod konsumentów czytać.
• Równolegle cień-rurociąg czyta ten sam strumień do oddzielnej piaskownicy.

Opcje: MirrorMaker/Replikator, dual-write (uwaga), źródło → prod + mosty cieni.

2. 3 Replayer (record/play)

Migawka rzeczywistych żądań/szlaków (dostęp PCAP/NGINX, krany gRPC) → odtwarzanie do „cienia” w kontrolowanym tempie.

2. 4 „Syntetyczny cień”

Generowanie profilu obciążenia z kłód produkcyjnych + faza wypełniania przypadków krawędzi jest przydatne dla ograniczeń poufności.

3) Izolacja stanu i skutków ubocznych

Złota zasada: cień nie zmienia świata zewnętrznego.

Dostęp do bazy danych/pamięci podręcznej lub oddzielnej skrzynki piaskowej (migawka/replika).
Zakaz wychodzących skutków ubocznych: płatności, litery, puchary, haki internetowe → stub/blackhole/record-only.
Polecenie/POST idempotencja: Cień nie powinien być zarejestrowany jako powtórzenie oryginału.
PII/tajne maskowanie, żetony dostawcy testów.

Przykład: maskowanie w lustrze

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

4) Strategie pobierania próbek i bezpieczne załadunek

Udział w ruchu: 1-10% na początku; wzrost, jeśli v2 jest w budżecie.
Kryteria wyboru: według trasy, użytkownika, rozmiaru żądania, typu operacji (bezpieczniejsze).
Budżet Perf: lustracja nie powinna zwiększać p95/p99 usługi walki. Cień zawsze jest asynchroniczny.
Ciśnienie wsteczne: gdy łańcuch cieni przegrzewa się, upuść cień, a nie zwalczyć żądania.
Czas: Minimum 24-72 godziny na pokrycie na diem i wzory szczytowe.

5) Porównanie wyników: metody i poziomy

5. 1 Poziomy porównawcze

1. Byte diff: Ciało odpowiedzi/zdarzenia jednorazowego. Proste, ale delikatne (znaczniki czasowe, kolejność kluczy).
2. Różnica semantyczna: normalizować i sortować pola, ignorować epemerydy (traceId, znaczniki czasu, liczniki).
3. Niezmienne przedsiębiorstwa: czy te same kwoty, statusy, ilości, granice.
4. Analiza statystyczna: Czy dystrybucje metryczne pasują? (p50/p95, próba KS, kategoryczna, ≤ ²).

5. 2 Polityka porównawcza

Maski/ignoruj listy pól (np. „updples At”, „etag”).
Dokładność: błąd bezwzględny/względny dla liczb (np. ± 1e-6).

Pasma tolerancji: "różnica cen ≤ 0. 01”, „nie więcej niż + 0 błędów. 1% w stosunku do prod'

Pseudokoda porównawcza

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 Porównanie zaproszeń

Wymagany jest identyfikator korelacji.
Łącze przęsła: ścieżka cieni dostaje link do bitwy.

6) Obserwowalność i artefakty porównawcze

• „shadow _ requests _ total {route,...}”
• „shadow _ differences _ total {type = byte 'semantic' invariant}”
• 'shadow _ error _ ratio' 'shadow _ slo _ breach _ total'
• Perf: „shadow _ latencies _ ms {p50, p95, p99}”
• Dzienniki rozproszone: kompaktowe delty JSON według klucza.
• Sprawozdawczość: dzienny raport z najwyższymi rozbieżnościami N, mapy ciepła według tras/najemców.
• UI „diff explorer”: filtry według typu, trasy, pola, eksport w CSV.

7) Specjalne okazje i subtelności

7. 1 Spójność i spójność

Żądania cienia mogą przyjść później/wcześniej; normalizować do wersji/godzin (Lamport/wektor) lub tolerancji okien.
Read-after-write: cień z repliką bez synchronicznej replikacji daje różne odpowiedzi - porównaj przez okna lag.

7. 2 Pamięć podręczna/zalecenia

Nie mieszać buforów prod i cienia.
Dla ML/rekomendatorów porównaj mierniki online i mierniki offline oddzielnie; zegarek na funkcje wejściowe drift.

7. 3 Dostawcy zewnętrzni

Owiń klientów w tryb tylko rekord/stub.
Dla usług rozrachunkowych (podatki, stawki) - ustalić migawkę katalogów dla obu stron.

8) Zestaw kanaryjski/niebiesko-zielony

Cień: zero ryzyka dla użytkowników, ale bez rzeczywistych skutków ubocznych; świetnie nadaje się do logiki i perf.
Canary: niewielki procent rzeczywistych odpowiedzi z nowej wersji; wymaga gotowej strategii rollback i SLA.
Niebiesko-zielony: natychmiastowe przełączanie po walidacji; Cień jest często używany przed nim.

9) Plan realizacji (w stylu GitOps)

1. Cele i wskaźniki: które niezmienne i tolerancje sprawdzają, które SLO pod kątem rozbieżności.
2. Ślad: Korelacja-ID, rozproszone linki śladowe.
3. Konfiguracja serwera proxy: polityka lustrzana, pobieranie próbek, redakcja.
4. Izolacja: piaskownica/pamięć podręczna bazy danych, klucze boczne, klucze testowe.
5. Porównanie: normalizacja, ignorowanie-mapy, niezmienne, raporty.
6. Plan obciążenia: start od 1-5%, wzrost do 20-50% z zielonymi metrami.
7. Obserwowalność: deski rozdzielcze „rozbieżność/perf/objętość”.
8. Kryteria wyjścia: "0 rozbieżności krytycznych 48 h", "błędy nie gorsze niż prod'," perf w granicach ± 5% ".
9. Przenieś się do kanarka: Zawierać prawdziwe odpowiedzi z bezpiecznym udostępnieniem i automatycznych reguł garda.

10) Przykłady konfiguracji

10. 1 Istio (lustro ruchu)

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 Kafka Tee (szkic)

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

10. 3 Zasady porównywania (polityka 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) Anty-wzory

Cień wypisuje: prawdziwe płatności/powiadomienia z cienia.
Wspólna pamięć podręczna/wspólne kolejki: uderzenie krzyżowe i zanieczyszczenie.
Brak normalizacji: dyfuzje bajtowe są „czerwone” ze względu na kolejność zegara/klucza.
Zbyt wysoki procent w podróży: degradacja pióra prod.
Długi „wieczny cień”: drugi system żyje oddzielnie i odbiega od rzeczywistości.

12) Lista kontrolna uruchamiania trybu cienia

• Serwer proxy jest skonfigurowany z lustrem z akcją i redakcją.
• Odizolowany cień: DB/bufory/integracje zewnętrzne - tylko czytelnie/stub.
• Korelacja-ID jest rzucana wszędzie; ślady są ze sobą powiązane.
• Komparator może ignorować/normalizować i sprawdzać niezmienne.
• Deski rozdzielcze i wpisy dotyczące rozbieżności i obciążenia.
• Pobieranie próbek drogą/najemcami; ograniczenia i ciśnienie wsteczne.
• Zdefiniowano tolerancje i kryteria światła zielonego.
• Przejście na plan kanaryjski/niebiesko-zielony i rollback.

13) FAQ

P: W jaki sposób Cień różni się od A/B?
Odp.: W A/B obie wersje zwracają użytkownikom odpowiedzi (eksperyment podzielony), w Shadow nowa wersja nie wpływa na użytkownika - jego odpowiedzi są analizowane tylko.

P: Czy POST/PUT można zacienić?
Odp.: Tak, jeśli izolacja skutków ubocznych (stub) i idempotencja są gwarantowane. Często zaczynaj od GET, a następnie rozwiń.

P: Jak porównać odpowiedzi, gdy kolejność przedmiotów nie jest ustalona?
Odp.: Sortuj za pomocą stabilnego klucza przed porównaniem lub porównaniem jako zestawy/klucze.

P: Co zrobić z opóźnieniami repliki bazy danych?
Odp.: Wprowadź „okna porównawcze” i migawki książek referencyjnych; Zagregowane wyniki w wersji, a nie w godzinach ściennych.

14) Kwoty całkowite

Ruch cieni to „bezbolesna próba produkcji”: rzeczywiste obciążenie, zero ryzyka dla użytkowników, szczegółowa analiza rozbieżności. O sukcesie decyduje izolacja, prawidłowe pobieranie próbek, porównanie jakości i obserwowalność. Zgodnie z proponowanym planem, otrzymasz powtarzalną praktykę, która pewnie łączy ścieżkę do kanaryjskich/niebiesko-zielonych wydań i przyspiesza ewolucję architektury.