بریف معماری / EDGE / LOGISTICS

به‌روزرسانی پیوسته در لبهٔ شبکه

معماری استقرار برای بیش از ۲۰۰ نود در مراکز تفکیک مرسولات؛ با در نظر گرفتن ارتباط ناپایدار و دامنه‌های خرابی مستقل.

k3sGoGitOpsEdge

این مطالعه‌ها بر اساس بریف ارائه‌شده برای سایت نوشته شده‌اند. اعداد مربوط به دامنهٔ پروژه هستند؛ نتایج عملیاتی مستقلاً تأیید نشده‌اند.

200+نود در بریف پروژه
k3sارکستریشن سبک
N+1طراحی افزونگی
توپولوژی سیستم
توپولوژی سیستمCI: build and sign → Container registry; Container registry → Versioned desired state; Versioned desired state → Sorting center A: k3s; Versioned desired state → Sorting center B: k3s; Sorting center A: k3s → Durable local queue; Sorting center B: k3s → Durable local queue; Durable local queue → Cloud ingestion: deduplicate; Durable local queue → Cloud ingestion: deduplicateCI: build and signContainer registryVersioned desired stateSorting center A: k3sSorting center B: k3sDurable local queueDurable local queueCloud ingestion:deduplicate

مسئله و محدودیت‌ها

بریف پروژه از ناوگانی با بیش از ۲۰۰ نود در مراکز تفکیک مرسولات صحبت می‌کند. مسئلهٔ معماری، یکسان نگه داشتن نسخه‌ها بدون وابسته کردن عملیات محلی به ارتباط دائمی با مرکز است.

این سند طراحی پیشنهادی و فرض‌های عملیاتی آن را توضیح می‌دهد. نتیجهٔ استقرار یا عملکرد در محیط واقعی، بدون شواهد و تله‌متری ادعا نمی‌شود.

تصمیم‌های استقرار

هر مرکز یک دامنهٔ خرابی مستقل است. کلاستر سبک k3s سرویس‌های محلی و صف پایدار رویدادها را اجرا می‌کند. مخزن وضعیت مطلوب، تاریخچهٔ نسخه‌ها را قابل ممیزی نگه می‌دارد و ایمیج‌ها با digest ثابت انتخاب می‌شوند.

انتشار از یک مرکز آزمایشی شروع می‌شود. بررسی آمادگی، ورود ترافیک را کنترل می‌کند. بودجهٔ اختلال و ظرفیت آزاد کافی امکان جایگزینی تدریجی را فراهم می‌کنند. شکست بررسی آمادگی باید ارتقای نسخه در بقیهٔ ناوگان را متوقف کند.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

استقرار بدون وقفه یک هدف است؛ تحقق آن به ظرفیت آزاد سالم، بررسی آمادگی صحیح و تغییرات سازگار دیتابیس وابسته است.

رفتار هنگام قطع شبکه

هر رویداد شناسهٔ ثابت و شناسهٔ مرکز دارد. لبه پیش از تأیید دریافت، رویداد را روی دیسک ثبت می‌کند. همگام‌سازی با تأخیر افزایشی تلاش می‌کند و مرکز رویدادهای تکراری را حذف می‌کند. تضمین ارسال، حداقل یک بار است و پردازش باید idempotent باشد.

تحلیل خرابی و راهنمای عملیات

  • رجیستری در دسترس نیست: نسخهٔ سالم قبلی حفظ و انتشار متوقف شود.
  • ارتباط ابری قطع شده: رویدادها محلی بمانند؛ سن صف و ظرفیت دیسک پایش شود.
  • بررسی آمادگی شکست خورده: وضعیت مطلوب قبلی بازگردانده شود.
  • مهاجرت ناسازگار: از الگوی گسترش و سپس حذف تدریجی فیلدهای قدیمی استفاده شود.

برنامهٔ اعتبارسنجی

سن صف، همگرایی نسخه‌ها، نرخ خطا و زمان بازیابی را با قطع عمدی ارتباط اندازه بگیرید. برای انتشار گزارش حادثهٔ واقعی، خط زمانی، دامنهٔ اثر و شواهد هر بهبود باید اضافه شود.