ترافیک سایه و مقایسه

1) ترافیک سایه چیست و چرا لازم است

ترافیک سایه (با نام مستعار ترافیک معکوس/راه اندازی تاریک) یک «اجرای» امن از درخواست ها/رویدادهای واقعی به یک نسخه جدید از سرویس به صورت موازی با نسخه تولید بدون تاثیر بر کاربران است. نتایج نسخه جدید به مشتری بازگردانده نمی شود و عوارض جانبی خارجی ایجاد نمی کند، بلکه در یک سیستم مقایسه جمع آوری می شود.

• بررسی سازگاری: طرح ها، قراردادها، منطق کسب و کار.
• ارزیابی عملکرد: تاخیر، مقاومت در برابر بار واقعی.
• تشخیص رانش: تفاوت در پاسخ، توزیع، نرخ خطا.
• آماده سازی برای انتشار قناری: کاهش خطر قبل از تغییر در واقع ترافیک.

• بازنویسی هسته/الگوریتم ها، مهاجرت پایگاه داده/کش، تعویض به یک runtime/SDK دیگر، تغییر ارائه دهنده API خارجی.

2) الگوهای معماری ترافیک سایه

2. 1 L7 پروکسی/دروازه (HTTP/gRPC)

پروکسی درخواست را می پذیرد → یک پاسخ جنگی از نسخه قدیمی ارائه می دهد → به طور غیر همزمان یک کپی از درخواست را به «سایه» نشان می دهد.

مناسب برای API های همزمان.
به اشتراک گذاری/آینه کنترل فیلتر: در راه، هدر، کاربر، مستاجر.

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 اتوبوس رویداد (کافکا/موضوعات)

• تولید کننده می نویسد به طور معمول → تحریک مصرف کنندگان خواندن.
• به موازات، خط لوله سایه همان جریان را به یک جعبه ماسه جداگانه می خواند.

گزینه ها: MirrorMaker/Replicator، دو نوشتن (احتیاط)، منبع → prod + پل های سایه.

2. 3 پخش کننده (رکورد/بازی)

Snapshot of real requests/trails (دسترسی PCAP/NGINX، شیپور خاموشی gRPC) → بازی به «سایه» در یک سرعت کنترل شده.

2. 4 «سایه مصنوعی»

تولید یک پروفایل بار از سیاهههای مربوط تولید + فاز پر کردن موارد لبه برای محدودیت های محرمانه مفید است.

3) جداسازی دولت و عوارض جانبی

قانون طلایی: سایه دنیای بیرون را تغییر نمیدهد.

دسترسی Reed-on به پایگاه داده/کش یا یک sandbox جداگانه (snapshot/replica).
ممنوعیت عوارض جانبی خروجی: پرداخت، حروف، fluffs، webhooks → خرد/سوراخ سیاه/رکورد تنها.
Command/POST idempotence: سایه نباید به عنوان تکرار اصلی ثبت شود.
PII/ماسک مخفی، نشانه های ارائه دهنده آزمون.

مثال: ماسک زدن در آینه

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

4) استراتژی های نمونه برداری و بارگیری ایمن

سهم ترافیک: 1-10٪ در آغاز ؛ افزایش اگر V2 در بودجه باشد.
معیارهای انتخاب: بر اساس مسیر، کاربر، اندازه درخواست، نوع عملیات (GET ها امن تر هستند).
بودجه Perf: آینه سازی نباید خدمات جنگی p95/p99 را افزایش دهد. سایه همیشه ناهمگام است.
فشار برگشتی: هنگامی که زنجیره سایه بیش از حد گرم می شود، سایه را رها کنید، نه درخواست های مبارزه.
زمان: حداقل 24-72 ساعت برای پوشش در هر روز و الگوهای اوج.

5) مقایسه نتایج: روش ها و سطوح

5. 1 سطح مقایسه

1. بایت تفاوت: بدن از یک پاسخ/رویداد یک در یک. ساده اما شکننده (زمان بندی، نظم کلیدی).
2. تفاوت معنایی: عادی سازی و مرتب سازی زمینه ها، نادیده گرفتن epemerides (traceId، timestamps، شمارنده).
3. متغیرهای کسب و کار: چه همان مقدار، وضعیت، مقادیر، مرزها.
4. تجزیه و تحلیل آماری: آیا توزیع متریک مطابقت دارد ؟ (p50/p95، آزمون KS، χ ² قطعی).

5. 2 سیاست مقایسه

ماسک/نادیده گرفتن لیست زمینه (به عنوان مثال،. 'updatedAt'، 'etag').
دقت: خطای مطلق/نسبی برای اعداد (به عنوان مثال ± 1e-6).

باندهای تحمل: "تفاوت قیمت ≤ 0. 01»، «بیش از 0 + خطا نیست. 1٪ نسبت به PROD"

مقایسه کننده شبه کد

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. ۳ مقایسه zapros↔otvet

شناسه همبستگی مورد نیاز است.
طول لینک: مسیر سایه می شود لینک به نبرد.

6) قابل مشاهده و مقایسه مصنوعات

• 'shadow _ requests _ total {مسیر،...}'
• 'shadow _ discrepancies _ total {type = byte' symantic 'invariant}'
• 'shadow _ error _ ratio' и 'shadow _ slo _ breach _ total'
• Perf: 'shadow _ latencies _ ms {p50, p95, p99}'
• سیاهههای مربوط به پخش: دلتای JSON جمع و جور توسط کلید.
• گزارش: گزارش روزانه با N اختلاف بالا، نقشه های گرما توسط مسیرها/مستاجران.
• UI «diff explorer»: فیلترها بر اساس نوع، مسیر، زمینه، صادرات در CSV.

7) موارد خاص و ظرافت

7. ۱ ثبات و انسجام

درخواست های سایه می تواند بعد/قبل از آن باشد ؛ عادی به نسخه/ساعت (Lamport/بردار) و یا تحمل پنجره.
Read-after-write: یک سایه با reading-replica بدون تکرار همزمان پاسخ های مختلفی را ارائه می دهد - از طریق پنجره های تاخیر مقایسه می شود.

7. 2 کش/توصیه

سایه ها و سایه ها را با هم مخلوط نکنید.
برای ML/recommenders، معیارهای آنلاین و معیارهای آفلاین را به طور جداگانه مقایسه کنید. مراقب ویژگی های ورودی رانش باشید.

7. 3 ارائه دهندگان خارجی

قرار دادن مشتریان در حالت رکورد تنها/خرد.
برای خدمات حل و فصل (مالیات، نرخ) - رفع یک عکس فوری از دایرکتوری برای هر دو طرف.

8) هماهنگی قناری/آبی سبز

سایه: خطر صفر برای کاربران، اما هیچ عوارض جانبی واقعی ؛ بزرگ برای منطق و perf.
Canary: درصد کمی از پاسخ های واقعی از نسخه جدید ؛ نیاز به یک استراتژی بازگشت آماده و SLA دارد.
آبی-سبز: تعویض فوری پس از اعتبارسنجی ؛ سایه اغلب در جلوی آن استفاده می شود.

9) طرح پیاده سازی (سبک GitOps)

1. اهداف و معیارها: کدام متغیر ها و تحمل ها SLO را برای اختلافات بررسی می کنند.
2. ردیابی: شناسه همبستگی، پیوندهای ردیابی توزیع شده.
3. پیکربندی پروکسی: سیاست آینه، نمونه برداری، اصلاح.
4. جداسازی: sandbox پایگاه داده/کش، ته مانده های جانبی، کلیدهای تست.
5. مقایسه کننده: عادی سازی، چشم پوشی از نقشه ها، ناورداها، گزارش ها.
6. طرح بار: شروع از 1-5٪، رشد تا 20-50٪ با معیارهای سبز.
7. قابلیت مشاهده: داشبورد «اختلاف/perf/volume».
8. معیارهای خروج: «0 اختلافات بحرانی 48 ساعت»، «خطاها بدتر از prod نیستند»، «perf در ± 5٪».
9. حرکت به قناری: شامل پاسخ های واقعی با سهم امن و قوانین گاردا خودکار.

10) نمونه های پیکربندی

10. 1 ایستگاه (آینه ترافیک)

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 کافکا سه راهی (طرح)

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

10. 3 قوانین مقایسه (سیاست یامل)

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) ضد الگوهای

Shadow می نویسد: پرداخت های واقعی/اطلاعیه ها از سایه ها.

کش مشترک/صف های مشترک: تاثیر متقابل و آلودگی

عدم نرمالیزاسیون: دیفیوزهای بایت به دلیل ترتیب ساعت/کلید «قرمز» هستند.
درصد بیش از حد بالا در حال حرکت: تخریب قلم تحریک.
«سایه ابدی» طولانی: سیستم دوم به طور جداگانه زندگی می کند و از واقعیت جدا می شود.

12) چک لیست راه اندازی حالت سایه

• پروکسی با یک آینه با یک سهم و یک redaction پیکربندی شده است.
• سایه جدا شده: DB/caches/ادغام خارجی - فقط خواندنی/خرد.
• همبستگی ID در همه جا پرتاب می شود ؛ ردپاها مرتبط است.
• مقایسه کننده می تواند ناورداها را نادیده بگیرد/نرمال کند و بررسی کند.
• داشبورد و هشدار برای اختلاف و بار.
• نمونه برداری توسط مسیرهای/مستاجران ؛ محدودیت ها و فشار برگشتی
• تحمل و معیارهای نور سبز تعریف شده است.
• انتقال به برنامه قناری/آبی-سبز و عقب نشینی.

13) سوالات متداول

س: چگونه سایه از A/B متفاوت است ؟

A: در A/B، هر دو نسخه پاسخ به کاربران (تقسیم آزمایش)، در سایه نسخه جدید کاربر تاثیر نمی گذارد - پاسخ آن تنها تجزیه و تحلیل.

س: آیا POST/PUT می تواند سایه باشد ؟

A: بله، اگر عوارض جانبی انزوا (خرد) و idempotence تضمین شده است. اغلب با GET شروع می شود، سپس گسترش می یابد.

س: چگونه می توانم پاسخ ها را مقایسه کنم وقتی سفارش اقلام ثابت نیست ؟

A: مرتب سازی بر اساس کلید پایدار قبل از مقایسه یا مقایسه به عنوان مجموعه/با کلید.

س: چه کاری با تاخیر ماکت پایگاه داده انجام دهید ؟

A: «پنجره های مقایسه» و عکس های مرجع کتاب را وارد کنید ؛ نتایج جمع آوری شده توسط نسخه به جای ساعت دیواری.

14) مجموع

ترافیک سایه یک «تمرین بدون درد تولید» است: بار واقعی، خطر صفر برای کاربران، تجزیه و تحلیل دقیق اختلافات. موفقیت با انزوا، نمونه گیری صحیح، مقایسه کننده کیفیت و مشاهده پذیری تعیین می شود. پس از طرح پیشنهادی، شما یک عمل تجدید پذیر دریافت خواهید کرد که با اطمینان مسیر را به انتشار قناری/آبی سبز متصل می کند و تکامل معماری را تسریع می کند.