هسته چند مستاجر

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

1) مدل مستاجر و مرزهای انزوا

تعاریف

Tenant/Org/Account: یک سازمان منطقی با کاربران، داده ها، سیاست ها و محدودیت های خود.
جداسازی: توانایی جلوگیری از یک مستاجر از تاثیر بر داده ها، عملکرد و امنیت دیگر.

سطح عایق

1. داده ها: پایگاه داده های فردی/طرح ها/جداول، رمزگذاری با «کلید مستاجر»، فیلتر «tenant _ id».
2. محاسبات: سهمیه CPU/RAM/IO، استخر کارگر مستاجر یا صف های وزنی.
3. شبکه: تقسیم بندی، نقاط انتهایی خصوصی/VPN، لیست مجوزها توسط مستاجر.
4. عملیات: مهاجرت، پشتیبان گیری، DR و حوادث با مرزهای تاثیر «در هر مستاجر».

الگوهای چند اجاره ای

سیلو (جداسازی سخت): خوشه های فردی/پایگاه های داده برای هر مستاجر. حداکثر امنیت، قیمت بالا.
استخر: زیرساخت مشترک با انزوای منطقی ؛ بهره وری بهتر، خطر بالاتر «همسایه پر سر و صدا».
پل/ترکیبی: ترکیبی - هواپیما کنترل مشترک + انتخابی «سیلو» برای VIP/مشتریان تنظیم شده است.

2) شناسایی و مسیریابی درخواست مستاجر

قطعنامه مستاجر

با دامنه: 'https ://{ tenant} .example. با من بیا

در طول مسیر: «/t/{ tenant }/»..

با عنوان: «X-Tenant-Id»، «X-Org» (تأیید امضا)

با علامت: تمبرهای 'tenant _ id'، 'org _ id'، 'plan'، 'scops'

مسیریابی

دروازه L7 (دروازه API/Ingress) استخراج 'tenant _ id'، غنی سازی زمینه ('طرح'، محدودیت ها، منطقه)، می نویسد به مسیرهای پیاده روی/سیاهههای مربوط.
خدمات عملکرد یک زمینه فقط خواندنی را می پذیرند. تصمیم گیری در مسیر و محدودیت ها توسط موتور دروازه/سیاست ساخته شده است.

3) داده ها و طرح ها: استراتژی ها

گزینه های ذخیره سازی

Shared-schema, row-level: یک مجموعه از جداول، فیلد 'tenant _ id'، RLS سخت (Row-Level Security).
Shared-DB، per-schema: یک DBMS، یک طرح جداگانه برای هر مستاجر ؛ تعادل بین کنترل پذیری و عایق.
Per-DB/خوشه: پایگاه داده جداگانه/خوشه در هر مستاجر ؛ گران تر، آسان تر برای ادعای حاکمیت.

روش های کلیدی

در همه جا به صراحت «tenant _ id» را منتقل می کند و آن را در کلید های ترکیبی/شاخص ها قرار می دهد.
سیاست های دسترسی در سطح RLS/DBMS + اعتبار سنجی سرویس دو قفل.
رمزگذاری: سلسله مراتب کلید (ریشه KMS → کلید پاکت در هر مستاجر → DEK در هر شی).
بایگانی/نگهداری و «حق فراموش شدن» توسط سیاست های مستاجر مدیریت می شود.

4) تنظیمات، ویژگی ها و نسخه ها

تنظیمات مستاجر

جدول/ذخیره سازی 'tenant _ config' (طرح، سهمیه، پرچم های ویژگی، محلی سازی، SLA).
اولویت های پیکربندی: پیش فرض → برنامه → مستاجر → محیط → کاربر.
پیکربندی ذخیره سازی با TTL کوتاه و ناتوانی توسط رویداد.

ویژگی های پرچم و سازگاری

فعال کردن توابع نقطه (در هر مستاجر/در هر کوهورت)، نورد قناری.
نسخه API: قرارداد پایدار + آداپتورهای در مرز (فرمت های عقب/جلو سازگار).

5) محدودیت ها، سهمیه ها و صورتحساب

سیاست های مصرف

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

صورتحساب

شمارنده توسط 'tenant _ id' (معیارهای استفاده) → → جمع کننده فاکتور.
استفاده از عکس های فوری در مرز (idempotency و حفاظت از دست دادن رویداد).
مدل ها: برنامه ثابت + مصرف، پس از پرداخت/قبل از پرداخت، تخفیف «ردیف».

6) امنیت و دسترسی

احراز هویت/مجوز

OIDC/SAML با علامت های «tenant _ id»، «نقش ها»، «حوزه ها».

RBAC/ABAC - نقش سطح مستاجر (مالک/مدیر/خواننده)، ویژگی های پروژه/بخش

سرویس به سرویس با mTLS و نشانه های محدود.

مرزهای اعتماد

درخواست سیاست های پذیرش: تایید امضای هدر، nonce/timestamp، اتصال منبع.
اسرار و کلید: چرخش در هر مستاجر، زمینه های فردی KMS، ممیزی عملیات کلیدی.

اقامت چند منطقه ای و داده ها: پیوستن یک مستاجر به یک منطقه، کنترل جریان های بین منطقه ای

7) قابل مشاهده بودن «توسط مستاجران»

ردیابی و معیارها

برچسب های مورد نیاز 'tenant _ id', 'plan', 'region', 'endpoint', 'status'.
SLI/SLO در هر مستاجر: «در دسترس بودن»، «تأخیر p95»، «بودجه خطا».
داشبورد و هشدارها بر اساس بخش (VIP/regulated/new).

گزارش ها و ممیزی ها

سیاهههای مربوط به فعالیت (چه کسی/چه/زمانی/کجا) با ذخیره سازی و نگهداری غیر قابل تغییر با توجه به سیاست مستاجر.
پیش جمع آوری رویدادها برای ذخیره سازی ارزان، ترمیم جزئیات «با کلیک».

8) عملکرد و «همسایه پر سر و صدا»

اقدامات ضد سر و صدا

محدودیت در سطح صف/کارگران، CPU-سهام و نسبت IO به ازای هر مستاجر.
جداسازی حافظه پنهان: مستاجر پیشوندهای کلیدی: {id}:... '، TTL توسط برنامه ها، حفاظت در برابر «حافظه پنهان».
فهرست ها و برنامه های پرس و جو بر اساس انتخاب «tenant _ id».

شروع سرد و استخرهای «گرم»

پیش گرم کردن برای پنجره های VIP/پیک.
استخرهای الاستیک کارگران بر اساس سیگنال های متریک (backpressure/autoscaling).

9) ارتقاء و مهاجرت بدون خرابی

استراتژی ها

مهاجرت سازگار با عقب (گسترش → مهاجرت → قرارداد).
مهاجرت «توسط مستاجران»: دسته با کنترل پیشرفت، «مکث/برگشت» برای یک «tenant _ id» خاص.
نمونه برداری و مهاجرت «قناری» در یک زیر مجموعه از مستاجران.

DR و حوادث

طرح DR با RTO/RPO در هر مستاجر ؛ «حالت فقط خواندنی» جزئی بدون خرابی جهانی.
جداسازی حادثه: با استفاده از «tenant _ id»، خاموش کردن مستاجر «داغ» بقیه را تحت تاثیر قرار نمی دهد.

10) API ها و پروتکل ها

REST/gRPC با زمینه اجباری مستاجر (در تمبر/هدر).
رویدادها (رویداد محور): موضوعاتی با نام 'مستاجر {id} .event'، فیلترها و ACL ها برای اشتراک.
نقاط ورود جهانی: دروازه L7 زمینه را تأیید می کند، محدودیت ها را اعمال می کند، PII را با توجه به سیاست مستاجر رمزگذاری می کند.

11) چرخه زندگی مستاجر

1. تأمین: ایجاد یک رکورد مستاجر، تولید کلید/پیکربندی، اتصال یک منطقه.
2. فعال سازی: انتشار مشتری OIDC/SAML، ایجاد نقش ها/سیاست ها، سهمیه های اولیه.
3. عملیات: نظارت، صورتحساب، به روز رسانی پرچم/برنامه.
4. تعلیق/throttling: توقف با حفظ داده ها/صادرات.
5. حذف/صادرات: حفظ، پشتیبان گیری mothballed، رمزنگاری خرد.

12) معماری مینی مرجع (طرح کلامی)

لبه (دروازه API): TLS/mTLS، استخراج 'tenant _ id'، محدودیت ها، حسابرسی.
کنترل هواپیما: کاتالوگ مستاجران، تنظیمات، پرچم های ویژگی، صدور صورت حساب، سیاست.
Data Plane (خدمات): خدمات بدون وضعیت، صف، کارگران سهمیه بندی ؛ Redis/kv توسط مستاجر پیشوند.
ذخیره سازی: RLS-DB/طرح های فردی/DB ؛ KMS با کلید در هر مستاجر ؛ ذخیره سازی شی با رمزگذاری پاکت.
قابلیت مشاهده: ردیابی/متریک/سیاهههای مربوط با برچسب 'tenant _ id'، هشدارها در هر برنامه.
مدیر: عملیات جداگانه (مهاجرت/پشتیبان گیری) در یک زیر مجموعه از مستاجران.

13) چک لیست پیش فروش

• یک راه واحد برای تعریف tenant _ id در مرز و در خدمات.
• سیاست های RLS/ACL با تست ها و «اسکریپت های منفی» آزمایش می شوند.
• سهمیه/محدودیت/صدور صورت حساب در بارهای واقعی اعتبار ؛ حفاظت در برابر «قطره صورتحساب» وجود دارد.
• قابلیت مشاهده و SLO در هر مستاجر ؛ هشدار برای VIP/تنظیم شده است.
• مهاجرت سازگار است، rollback جزئی و دسته وام دهنده وجود دارد.
• سناریوهای DR با RTO/RPO در هر مستاجر و تمرینات منظم.
• رمزگذاری کلید مستاجر، چرخش کلید و ممیزی کلید.
• مستندات قراردادهای API/حوادث و سیاست های نسخه.

14) خطاهای معمول

مهاجرت جهانی «در یک سقوط سقوط کرد» بدون توانایی متوقف کردن مستاجر مشکل.
وابستگی پنهان به کش/صف tenant _ id 'in → نشت داده/صف عبور.
مخلوط کردن زمینه (عملیات مدیر به طور تصادفی بدون 'tenant _ id').
عدم وجود «قفل دوگانه»: تنها بررسی سرویس بدون RLS در پایگاه داده.
یک محدود کننده برای کل خوشه → «همسایه پر سر و صدا» و نقض SLO.
صدور صورت حساب غیر شفاف بدون idemotency و دنباله حسابرسی.

15) انتخاب استراتژی سریع

جداسازی/تنظیم دقیق: سیلو (پایگاه داده ها/خوشه های جداگانه)، قفل منطقه.
بهره وری متعادل: مشترک DB در هر طرح + RLS، کلید در هر مستاجر.
ترافیک در زمان واقعی بالا: صف های مشترک با سهمیه های «وزن» و کارگران اختصاصی برای VIP.
بسیاری از سفارشی سازی ها: پرچم های ویژگی + آداپتورهای API، ذخیره سازی پیکربندی بر اساس اولویت.

نتیجه گیری

هسته چند مستاجر نظم و انضباط مرزهای مهندسی است: تعریف صریح «tenant _ id»، انزوای شدید در تمام لایه ها، سهمیه های مدیریت شده و صورتحساب شفاف، به علاوه قابلیت مشاهده و سازگاری انتشار. به دنبال الگوهای توصیف شده اجازه می دهد تا شما را به مقیاس محصول بدون به خطر انداختن ایمنی، کیفیت و سرعت تغییر برای هر مستاجر.