ما علّمني إياه بناء ERP متعدد المستأجرين عن معمارية SaaS
عزل المستأجرين يبدو قرار قاعدة بيانات، لكنه في الحقيقة انضباط يغطي التطبيق كله. دروس من بناء نظام ERP متعدد المستأجرين.
يُشرح تعدد المستأجرين عادة كاستراتيجية مخططات: قاعدة مشتركة مع tenant_id، أو مخطط لكل مستأجر، أو قاعدة لكل مستأجر. عمليًا، قاعدة البيانات هي الجزء السهل.
العزلة يجب أن تصمد في كل طبقة
الدروس الصعبة جاءت من كل مكان عدا طبقة البيانات:
- التخزين المؤقت — مفتاح cache دون تحديد المستأجر ثغرة بيانات منتظرة
- المهام الخلفية — يجب أن يحمل العمال سياق المستأجر صراحة؛ لا يوجد طلب HTTP لاستنتاجه منه
- تخزين الملفات — المسارات والـ buckets والروابط الموقعة كلها تحتاج حدود مستأجرين
- السجلات — السجلات تسرّب. جمّعها لكل مستأجر أو نظّفها.
المعيارية تسدد ثمنها
نظمنا النظام في نطاقات عمل معيارية (مخزون، فوترة، موارد بشرية) بعقود API صارمة بينها. عندما اختلفت المتطلبات حسب شريحة العملاء، تطورت الوحدات دون جر المونوليث كله.
زاوية الوكيل الذكي
دمج وكيل LLM في سير عمل ERP رفع الرهان: نطاق استرجاع الوكيل وجب أن يكون محدودًا بالمستأجر بالبناء، لا بتعليمات prompt. العزل على مستوى prompt ليس عزلًا.
FAQ
ما هو عزل المستأجرين في SaaS؟
عزل المستأجرين يضمن أن مستأجرًا لا يستطيع أبدًا الوصول إلى بيانات مستأجر آخر أو مراقبة نشاطه. يجب أن ينطبق على كل طبقة: استعلامات قاعدة البيانات، مفاتيح cache، المهام الخلفية، تخزين الملفات، السجلات، ونطاقات استرجاع وكلاء LLM.
أيهما أفضل: مخطط لكل مستأجر أم عمود tenant_id مشترك؟
لا يوجد خيار أفضل عالميًا. الجدول المشترك مع tenant_id هو الأرخص ويبسّط الترحيلات؛ المخطط لكل مستأجر يوفر عزلًا أقوى للعملاء الملتزمين بمعايير صارمة بتكلفة تشغيل أعلى. اختيار قاعدة البيانات أقل أهمية من فرض سياق المستأجر في كل طبقة تطبيقية.
كيف تؤمّن وكيل LLM داخل نظام متعدد المستأجرين؟
يجب أن يكون نطاق استرجاع الوكيل محدودًا بالمستأجر بالبناء — مفروضًا في طبقة البيانات وتوجيه الاستعلامات، وليس بتعليمات prompt فقط. العزل على مستوى prompt ليس عزلًا.