استراتژی های انتشار: آبی سبز و قناری

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

آبی سبز یک سوئیچ فوری بین دو پشته کامل (آبی/سبز) با ساده ترین بازپرداخت می دهد. Canary به تدریج سهم ترافیک را به نسخه جدید تحت کنترل دروازه های SLO (تاخیر، نرخ خطا، معیارهای کسب و کار) افزایش می دهد. برای iGaming، این یک راه برای انتشار بدون خرابی در اوج مسابقات و تبلیغات، در حالی که حفظ P99 پایدار و کیفیت است.

1) هنگامی که برای انتخاب

آبی سبز - انتشار سریع، حداقل پیچیدگی، شما نیاز به یک «دو» خوشه/بودجه منابع. خوب برای API/جلو بدون مهاجرت حالت پیچیده.
Canary - انتشار در معرض خطر (جریان جدید، تغییرات بحرانی)، به شما امکان می دهد تخریب 1-5٪ از ترافیک را «بگیرید». نیاز به تله متری و دروازه های اتوماتیک.

2) اصول معماری

1. مسیریابی سطح L7: متعادل کننده/ورود/سرویس مش (ماژول های ترافیک وزن، کوکی ها/مسیریابی پرچم).
2. وابستگی های جداگانه: تنظیمات، فیشفلگ ها، اسرار، انبارها - به طور جداگانه برای تجدید نظر.
3. سازگاری داده ها: رو به جلو سازگار (گسترش → مهاجرت → قرارداد) مهاجرت پایگاه داده.
4. قابلیت مشاهده: برچسب های فردی/برچسب های نسخه در متریک/سیاهههای مربوط/آهنگ.
5. Autogates: مقایسه p95/p99، نرخ خطا، KPI کسب و کار ؛ برگشت خودکار.

3) آبی سبز: الگوی پایه

جریان آب

1. گسترش سبز (یک کپی از آبی) → گرم کردن انبارها/اتصالات.
2. تست سلامت/دود را اجرا کنید.
3. انتقال ترافیک (DNS/LB/Ingress) به سبز.
4. ما آبی را در حالت «گرم» به عنوان یک عقب نشینی تا انتهای پنجره نگه می داریم.

مثال: ورود به سطح سوئیچینگ (ایده)

yaml
Annotated/Backend Option - In Prod, it is usually controlled by the spec operator/rollout:
rules:
- host: api. example. com http:
paths:
- path: /
backend:
service:
name: api-green # used to be api-blue port:
number: 80

جوانب مثبت/منفی

بازگشت ساده (آبی بازگشت).

زمان انتشار قابل پیش بینی

نیاز به تکرار منابع

خطر «انفجار بزرگ» بدون اندازه گیری قناری

4) قناری: ساخت تدریجی

جریان آب

1. ترافیک سایه (اختیاری) → 1٪ از ترافیک واقعی → 5٪ → 25٪ → 50٪ → 100٪.
2. در هر مرحله - دروازه های معیارهای SLO/کسب و کار.
3. در طول تخریب - بازگشت خودکار و حفظ مصنوعات تشخیصی.

مثال: Argo Rollouts (قطعه)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: payments-api }
spec:
strategy:
canary:
canaryService: payments-canary stableService: payments-stable steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: slo-latency
- setWeight: 25
- pause: { duration: 10m }
- analysis:
templates:
- templateName: error-rate
- setWeight: 50
- pause: { duration: 20m }
- setWeight: 100

مثال: Flagger + Istio/NGINX (ایده)

yaml apiVersion: flagger. app/v1beta1 kind: Canary metadata: { name: games-api }
spec:
targetRef:
apiVersion: apps/v1 kind: Deployment name: games-api service:
port: 80 analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

5) گرم کردن و مدیریت شرایط

کش/منابع: گرم کردن REDIS/کش HTTP/CDN، آماده اتصالات گرم استخر به پایگاه داده/PSP.
ML/LLM/مدل: بارگذاری وزن/شاخص/تعبیه، حافظه پنهان KV، درخواست اولیه برای «گرم کردن».
فایل ها/مصنوعات: محتوای استاتیک، قالب ها، پیکربندی ها - از قبل به volume/sidecar محلی ارسال کنید.
Ficheflags: گسترش در 1-5٪ از مخاطبان/بخش، فرصت اضطراری کشتن.

6) پایگاه داده: «گسترش → مهاجرت → قرارداد» استراتژی

1. گسترش: اضافه کردن ستون های nullable/جدید/شاخص ها، پشتیبانی از هر دو نسخه.
2. مهاجرت: کد با استفاده از یک طرح جدید ؛ راه های قدیمی همچنان معتبر هستند.
3. قرارداد: حذف زمینه های قدیمی/شاخص پس از باز کردن کامل.

در سیاهههای مربوط، رفع طرح و مشتری نسخه ؛ همه تغييرات بيهوده هستند.
برای مهاجرت سنگین - ضربه محکم و ناگهانی پس زمینه، throttling و «توقف جهان» پنجره به عنوان توافق.

7) قابلیت مشاهده و دروازه (SLO/SLA)

معیارهای SRE: p50/p95/p99، میزان خطا، اشباع (CPU/GPU/IO)، عمق صف، زمان شروع سرد.
معیارهای کسب و کار: تبدیل پرداخت، موفقیت پیشنهاد، زمان برداشت (TTW)، پاسخ های تبلیغاتی.
کیفیت محتوا/LLM: نشانه/S، طول پاسخ، سمیت، RAG-نمره.
گیتس: ارتقاء خودکار/بازگشت زمانی که فراتر از آستانه و/یا زمانی که «متریک مفید» می افتد.

gate:
p95_latency_ms <= 250 error_rate %  <= 1. 0 payment_conv  >= baseline - 0. 3%
action:
promote      rollback

8) انتشار ارکستراسیون و ادغام با CI/CD

GitOps: تغییرات نسخه/وزن - از طریق PR به مخزن آشکار.
چک کردن خودکار دود/e2e قبل از شروع ترافیک.
طرح انتشار: برنامه گام قناری, مسئول, ChatOps کانال, پنجره برگشت.
مصنوعات بایگانی: تنظیمات مسیریابی، عکس های فوری داشبورد، سیاهههای مربوط به مقایسه متریک.

9) چند منطقه و لبه

سفارش: ابتدا منطقه «کمترین بحرانی »/ROR، سپس موارد اصلی.
مسیریابی مبتنی بر تأخیر: نظارت بر SLO های محلی ؛ بدون هیچ دلیلی ترافیک را مخلوط نکنید.
DR-چشم انداز: آبی در منطقه-A می تواند DR-سایت برای سبز در منطقه-B.

10) انتشار ایمنی و انطباق

امضا به نظر می رسد/نمودار، SBOM ؛ چک کردن امضا در سیاست های پذیرش

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

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

NGINX: Canary Branch by کوکی/هدر (ایده)

nginx map $http_x_canary $canary {
default 0;
"1"   1;
}

upstream api_stable { server stable:80; }
upstream api_canary { server canary:80; }

server {
location / {
if ($canary) { proxy_pass http://api_canary; }
proxy_pass http://api_stable;
}
}

ویژگی پرچم «اجرای کسری» (شبه)

yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true

12) Runbooks (سناریوهای معمولی)

رشد p99 در قناری: توقف ارتقاء → افزایش دسته/timeout, خاموش کردن ویژگی های سنگین از طریق پرچم → راه اندازی مجدد برخی از غلاف.
قطره تبدیل پرداخت: مقایسه مسیرهای PSP/ویژگی ها، فعال کردن ورود به سیستم سایه، بازگشت به پایدار است.
مشکل با مهاجرت پایگاه داده: مسدود کردن ترافیک برای نوشتن، فعال کردن حالت فقط خواندنی، بازگرداندن طرح (در صورت امکان)، جابجایی اضطراری.
حادثه PII: قطع نسخه قناری، لغو اسرار، گزارش و حسابرسی.

13) چک لیست پیاده سازی

1. سیاست را تعریف کنید: جایی که آبی سبز، جایی که قناری ؛ که «انتقادی» محسوب می شود.
2. پیکربندی مسیریابی وزن (Ingress/mesh/router).
3. ضبط دروازه های آستانه SLO و بازگشت خودکار.

4. پیاده سازی گسترش → مهاجرت → قرارداد برای پایگاه داده ؛ تست های مهاجرت

5. فعال کردن گرم کردن انبارها/مدل ها و اتصالات گرم استخر.
6. GitOps را وارد کنید و تمام اقدامات انتشار را وارد کنید.
7. مقایسه معیارها را تجسم کنید (canary vs stable).
8. صرف روز بازی: شبیه سازی بازگشت دروازه/شکست/مشکل پایگاه داده.
9. کتاب های اجرا و سوئیچ کشتن را مستند کنید.
10. برنامه ریزی انتشار چندگانه به نوبه خود، نه در همان زمان.

14) ضد الگوهای

آزادی قناری بدون دروازه و تله متری → تشخیص دیر هنگام تخریب.

مخلوط کردن طرح DB: مهاجرت های مخرب برای باز کردن کد

یک کش/صف مشترک برای آبی و سبز بدون انزوا → تاثیر متقابل.
تعویض DNS با TTL کم بدون تأیید - ترافیک «flapping».
اسرار/پیکربندی مشترک برای هر دو تجدید نظر → بازگشت پیچیده.
ترافیک به مواد غذایی بدون سایه/دود یک خطر بزرگ است.
بدون سوئیچ کشتن/ویژگی پرچم برای خاموش کردن سریع.

خلاصه

آبی سبز امکان تعویض سریع و آسان، خطر مدیریت شده قناری و تشخیص زود هنگام مشکل را فراهم می کند. در iGaming، هر دو الگو ترکیب می شوند: canary در تغییرات «تیز» + آبی سبز به عنوان یک مکانیسم اساسی بدون خرابی. اضافه کردن دروازه های SLO، GitOps، گرم شدن، سازگاری با پایگاه داده و جداسازی وابستگی - و انتشار قابل پیش بینی خواهد بود، رول ها سریع هستند، و p99 و معیارهای کسب و کار حتی در طول دوره های اوج پایدار هستند.