آبی سبز و قناری منتشر شد

(بخش: معماری و پروتکل ها)

1) چرا ما نیاز به «rollouts امن»

در سیستم های مدرن، انتشار نه تنها تحویل کد است، بلکه یک آزمایش کنترل شده در فروش است: ما به طور همزمان خطر را به حداقل می رسانیم (کاربران را شکست نمی دهیم) و زمان بازخورد را کاهش می دهیم (به سرعت اثر را ببینید). دو استراتژی کلاسیک - Blue-Green و Canary - این را به روش های مختلف حل می کنند، اما با یک هدف مشترک: خرابی صفر، بازگشت سریع، مشاهده توسط SLO.

2) تعاریف اساسی

آبی سبز

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

قناری

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

3) چه زمانی بهتر است

• ما به یک عقب نشینی فوری بدون مانورهای پیچیده نیاز داریم.
• معماری/بودجه اجازه می دهد تا برای تکرار زیرساخت های دوگانه.
• ما می خواهیم به انجام مهاجرت در مقیاس بزرگ و یا به روز رسانی پلت فرم (OS/JDK/زمان اجرا) در انزوا.
• استخرهای برنامه/اتصال به حالت تدریجی «مخلوط» حساس هستند.

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

4) اصول کلی برای انتشار موفقیت آمیز

مصنوعات ساخت Idempotent: همان تصویر/بسته در تمام مراحل.
پیکربندی قطعی: پیکربندی به عنوان کد، مقایسه محیط.
قابلیت مشاهده توسط طراحی: سیاهههای مربوط، معیارها، ردیابی، هشدارها ؛ SLI/SLO در پیشبرد.
سریع، بازگشت خودکار: دکمه برگشت/فرمان بخشی از خط لوله است، نه سحر و جادو دستی.
تغییرات طرح سازگار: استراتژی گسترش-مهاجرت-قرارداد (نگاه کنید به § 10).
مسیریابی L7 (مطلوب): انعطاف پذیری در هدر API/کوکی ها/مسیرها/نسخه ها.

5) آبی سبز: معماری و فرآیند

5. 1 توپولوژی

دو دسته محصول: آبی (فعال) و سبز (کاندید).
وابستگی های خارجی مشترک: CDN، API های خارجی، صف ؛ DB یک مورد خاص است (نگاه کنید به § 10).
نقطه سوئیچ: متعادل کننده/ورودی/دروازه.

5. 2 جریان گام به گام

1. ما سبز را تحت یک محصول جدید (vNext) افزایش می دهیم، ما آزمایش های اسمک را انجام می دهیم.
2. اجرای خودکار در برابر سبز (e2e، قرارداد، رگرسیون).
3. گرم کردن کش/جلسات (در صورت وجود), Jabs پس زمینه همگام سازی/صف.
4. ترافیک را به سبز تغییر دهید: تلنگر اتمی (DNS TTL کم، مبادله مسیر/شنونده، وزن ورودی = 100٪).
5. ما SLO را در دقیقه/ساعت اول مشاهده می کنیم (سیگنال های طلایی: تاخیر، خطاها، اشباع + معیارهای تجاری).
6. در مورد مشکلات - بازگشت فوری به آبی (تلنگر به عقب).

5. 3 جوانب مثبت/منفی

مزایا: بازگشت فوری، مدل ذهنی ساده، انزوای خالص.
معایب: دو برابر شدن زیرساخت ها، مشکل در اجزای stateful و مهاجرت داده ها.

6) معماری و فرآیند قناری

6. 1 توپولوژی

خوشه تولید تک ؛ چندین نسخه از خدمات (پایدار و قناری) در پشت یک جبهه واحد.
ترافیک بر اساس وزن (1-5-10-25-50-100٪) یا اهداف (با هدر/کوکی/شناسه) تقسیم می شود.

6. 2 جریان گام به گام

1. استقرار نسخه های قناری به همان خوشه/ASG/NSG.
2. مسیر برخی از ترافیک (به عنوان مثال، 1-5٪) به canary.
3. چک های خودکار از SLI/SLO و معیارهای کسب و کار ؛ دروازه ها در CI/CD (میزان خطا، تاخیر p95، CPU/RES، تبدیل، امتناع/بازگشت).
4. افزایش گام به گام در سهم ترافیک در هنگام عبور از دروازه.
5. گسترش کامل به 100% و غیر فعال کردن نسخه های قدیمی; در صورت تخریب - بازگشت خودکار.

6. 3 جوانب مثبت/منفی

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

7) مسیریابی ترافیک

لایه L4: تعادل توسط IP/پورت ؛ انعطاف پذیری ساده اما کمی

سطح L7: قوانین HTTP/S - در مسیر، میزبان، هدر، کوکی ها، عامل کاربر، GeoIP، SNI.

• مسیریابی وزنی (وزن 1-100٪).
• مبتنی بر سربرگ/مبتنی بر کوکی.
• چسبندگی جلسه (برای اسکریپتهای stateful/cached مهم است).
• سایه/ترافیک آینه (درخواست آینه به نسخه جدید «بی سر و صدا»).

8) ابزار و پیاده سازی (مثال)

Kubernetes: Ingress (NGINX، Contour)، مش سرویس (Istio/Linkerd)، Argo Rollouts، Flagger.
Облака: AWS ALB/ELB، مسیر 53 سوابق وزن، ECS/EKS ؛ تعادل بار GCP + NEG ؛ Azure Front Door/دروازه برنامه.
سیستم عامل های سی دی: Spinnaker، Argo CD، GitHub Actions + افزونه های تحویل پیشرفته، GitLab/CD.

9) قابلیت مشاهده، SLI/SLO و دروازه

سیگنال های طلایی: تاخیر (p95/p99)، نرخ خطا (5xx/4xx по типам)، RPS، اشباع (CPU/حافظه/GC)، تاخیر صف.
معیارهای کسب و کار: تبدیل، مجوز، پرداخت/موفقیت، چک متوسط، امتناع از مراحل قیف.

• آستانه خطا (به عنوان مثال، نرخ خطا canary ≤ baseline + X٪).
• تاخیر P95 بدتر از پایه بیش از Δ نیست.
• آستانه کسب و کار (به عنوان مثال افت تبدیل
• بودجه خطای SLO نباید سریعتر از بین برود.

مدت زمان مرحله: حداقل زمان کافی برای اهمیت آماری (بستگی به ترافیک دارد).

10) مهاجرت پایگاه داده و سازگاری طرح

قانون اصلی: اگر نسخه های عقب و جلو سازگار باشند، نسخه ها ایمن هستند.

1. گسترش: اضافه کردن ستون های جدید/شاخص/جداول بدون شکستن نسخه قدیمی.

2. استقرار برنامه vNext (می خواند/می نویسد: به طرح جدید، اما می داند که چگونه به کار با یکی از قدیمی).

3. مهاجرت داده ها (پس زمینه/دسته ای، idempotent، با checkpoints).

4. قرارداد: حذف زمینه ها/ویژگی های قدیمی پس از تثبیت.

ضد الگوهای: مهاجرت نیاز به مسدود کردن منحصر به فرد در نقطه سوئیچ آبی سبز ؛ عدم توانایی در پایین آوردن برنامه «دوبار نوشتن» بدون deduplication.

11) عقب نشینی و برنامه های اضطراری

آبی سبز: تلنگر فوری در آبی ؛ نظارت بر دم از مشاغل پس زمینه سبز.
قناری: بازگشت وزن (به عنوان مثال، از 25٪ به 5٪ یا 0٪) ؛ لغو خودکار در هشدار.
داده ها: یک سیاست به خوبی فکر شده از تکرار/جبران (کلید idempotency، «صندوق ورودی/صندوق» الگوی، پیام deduplication).
Ficheflags: یک سوئیچ kill سریع برای بستن فرصت هایی که تا حدی از بین رفته اند.

12) کار با دولت و جلسات

جلسات چسبنده برای قناری ها، یا ذخیره سازی جلسات در خارج (Redis/Memcached) به طوری که نسخه ها قابل تعویض هستند.
کش به گرم کردن در پیش (سبز گرم کردن) و به حساب باطل زمانی که تلنگر.
کارگران پس زمینه: اجازه نمی دهد «نژادها» بین نسخه - جدایی صف و یا «رهبری» توسط نسخه.

13) ایمنی و انطباق

دسترسی به سبز/قناری - توسط Zero Trust: حساب های خدمات، حداقل نقش های مورد نیاز.
اسرار و کلیدها - از طریق KMS/Secrets Manager ؛ چرخش را بچرخون.
ترافیک - فقط TLS ؛ نسخه های پایانی به وضوح مشخص شده اند ؛ حسابرسی مسیریابی و فعالیت های آزاد.

14) هزینه و عملکرد

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

15) چک لیست

قبل از انتشار

• تصویر/ساخت از یک منبع واحد ترویج، امضا تایید شده است.
• برنامه تست، هشدارها و دروازه های SLO پیکربندی شده اند.
• مهاجرت پایگاه داده - در حالت گسترش، برنامه های downgrade در دسترس هستند.
• طرح برگشت - چک در مرحله بندی/تولید مانند.

در زمان انتشار

• معیارها و سیاهههای مربوط با baseline مقایسه می شوند.
• برای قناری، مراحل و آستانه ها ثابت هستند ؛ برای آبی سبز - آمادگی تلنگر.
• دستورات on-call در know هستند، یک پنجره بازخورد وجود دارد.

پس از انتشار

• SLO غرق نشد، بودجه خطا طبیعی است.
• مهاجرت پس از انتشار/پاکسازی تکمیل شده است.
• به روز رسانی گذشته نگر و playbook.

16) خطاهای مکرر و ضد الگوهای

Rollout without metrics: no data - هیچ راه حل مدیریت شده ای وجود ندارد.
مخلوط کردن طرح های پایگاه داده ناسازگار، عدم استراتژی downgrade.
مخلوط کردن ترافیک تصادفی: بدون چسبندگی، کاربران «پرش» بین نسخه ها.
وابستگی های حالت پنهان (دیسک های محلی، حافظه های پنهان در حافظه).
DNS-TTL طولانی با تلنگر سریع (آبی سبز) تداخل دارد.
عدم وجود autogates: راه حل های دستی «توسط چشم» کم کردن سرعت و افزایش خطرات.

17) رویکردهای ترکیبی

آبی سبز + قناری: ابتدا سبز را رول کنید، سپس در داخل سبز قناری را برای خدمات فردی رول کنید.
ترافیک سایه/مهاجرت: قبل از Canary، ما ترافیک آینه را به نسخه جدید اجرا می کنیم.
پرچم های ویژگی (تحویل پیشرفته): قابلیت در بالای نسخه پایدار توسط پرچم های «تاریک» توسط بخش ها گنجانده شده است.

18) سناریوهای نمونه (طرح)

1. استقرار سبز (V2) برای شنونده جدید/ورود.

2. مخازن را گرم کنید، فقط چک کنید، سیگار بکشید.

3. ما وزن را به سبز = 100٪ تغییر می دهیم.

4. SLO را برای 30-60 دقیقه مشاهده کنید. اگر همه چیز خوب است - Blue را خاموش کنید.

1. استقرار قناری vNext (کپی 5٪).

2. ما شامل 5٪ ترافیک برای حساب های داخلی/بخش آزمون.

3. Autogate: میزان خطا ≤ پایه + 0. 3٪، p95 ≤ + 20 میلی ثانیه.

4. ما 10٪ → 25٪ → 50٪ در هر N دقیقه هنگام عبور از دروازه.

5. ما ficheflag را 100٪ برای همه بخش ها ترجمه می کنیم. حذف نسخه قدیمی

19) تغییرات برای معماری های مختلف

Monolith: آبی سبز ساده تر است، Canary به دلیل غیر قابل تفکیک بودن ویژگی ها مشکل تر است. استفاده از ficheflags.

خدمات میکروسکوپی: قناری طبیعی است ؛ نظارت بر قراردادهای مصرف کننده

خدمات Stateful: ترجیح می دهند آبی سبز با مهاجرت دقت گردد و چسبندگی.

20) مقایسه مختصر (خلاصه)

سرعت چرخش: آبی سبز = لحظه ای ؛ قناری = سریع اما با عقب نشینی در وزن.

هزینه زیرساخت: ↑ آبی-سبز ؛ ↔︎/↓ قناری

خطر برای کاربران: قناری پایین تر است (ما سهم را کنترل می کنیم).
دشواری پیاده سازی: آبی سبز برای شروع آسان تر است ؛ قناری نیاز به قابلیت مشاهده و اتوماسیون قوی دارد.
سازگاری داده ها/مدار: برای هر دو مهم است ؛ برنامه گسترش-مهاجرت-قرارداد.

21) خط پایین

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