المستأجرون والمضيف ومرشّح البيانات
يقوم ToRun على نموذج تعدد المستأجرين في ABP Framework. الصف الموسوم بـ IsMultiTenant يحتوي على عمود TenantId يرشّح الإطار عليه تلقائيًا؛ فالاستعلامات التي تُنفَّذ في سياق مستأجر لا ترى أبدًا صفوف مستأجر آخر. أما سياق المضيف (TenantId == null) فيرى شريحة منفصلة: هناك توجد الكتالوجات القياسية مثل SubscriptionPlan وAiProvider وLegalDocument.
لماذا نعامل المضيف كمشارك كامل
تضيف معظم منتجات SaaS المضيف على شكل "أدوات إدارة". أما نحن فنمذجه كمستأجر شقيق: للمضيف لوحات معلوماته وسياسات الذكاء الاصطناعي الخاصة به وعلاقات الفوترة الخاصة به. وهذا يتيح لنا تشغيل حركة الإنتاج الخاصة بنا على المكوّنات نفسها التي يستخدمها كل عميل.
ميزات مرتبطة بالخطة لكل مستأجر
تحمل خطط الاشتراك صفوف FeatureLimit وEntitlement وCapability وMode. وعندما يفعّل مستأجر خطة، تكون مجموعة الميزات المتاحة له هي التقاطع بين خطته والكتالوج العام. ولا تتطلب إضافة وضع جديد تعديل كل مستأجر: إذ يحصل عليه تلقائيًا إذا كانت الخطة التي لديه تتضمنه.
حقن BYOK في كل استدعاء
حتى مع البنية التحتية المشتركة، تبقى بيانات اعتماد BYOK محصورة في المستأجر الذي يملكها. كل طلب ذكاء اصطناعي يستخرج بيانات الاعتماد داخل سياق المستأجر بمرشّح البيانات نفسه؛ ولا يمكن أن تتسرّب المفاتيح بين المستأجرين في طبقة التخزين.
ما لا نفعله عن قصد
لا نعزل المستأجرين على مستوى قاعدة البيانات أو العملية. فتكلفة توسيع قاعدة بيانات منفصلة لكل مستأجر تقضي على اقتصاديات الوحدة لمنتج SaaS متعدد المستأجرين. ويكفي مرشّح البيانات مع ذاكرة تخزين مؤقت مفصولة لكل مستأجر حين يُصمَّم المخطط لذلك منذ اليوم الأول.