MicrocosmWorksابتكار وتصميم الكون الرقمي
من نحناتصل بنا
MicrocosmWorksابتكار وتصميم الكون الرقمي

نقدم حلول تقنية المعلومات المهمة. نحن شغوفون بالتقنية والأمان ومساعدة الشركات على النمو من خلال بنية تحتية موثوقة ومبتكرة لتقنية المعلومات.

[email protected]
+91 7011868196
New Delhi, India

مركز نمو AI

مركز AIابتكار الشركات الناشئةمسرّع المؤسسات

الحلول

جميع الحلولتطبيقات الصحة واللياقةمنصة فيديو AIتطوير وكلاء AI

الموارد

رؤىأدلة القطاعاتمخططات حالات الاستخدامأنماط المعماريةدراسات الحالة

الشركة

من نحناتصل بناأعمالنا

الخدمات

الاستشارات الرقميةالبنية التحتية السحابيةتطوير SaaSتطوير AIتقنية الفيديو
تطوير ERPتخصيص Zohoتطوير Odooتكامل Salesforceتطوير CRM مخصص
تكامل QuickBooksحلول IoTتطوير بلوكتشين
استشارات الأمن السيبرانيالدعم التقني - L3

© 2026 MicrocosmWorks. جميع الحقوق محفوظة.

سياسة الخصوصيةشروط الخدمة
العودة إلى أنماط العمارة
ApplicationAdvanced

هندسة SaaS متعددة المستأجرين

قاعدة بيانات واحدة، مئات المستأجرين، صفر تسرب للبيانات — أساس كل عمل SaaS قابل للتطوير.

June 22, 2026
|
3 topics covered
ناقش هذه العمارة
multi-tenant-saas-architecture.webp
Application
Category
Advanced
Complexity
الرعاية الصحية, تقنيات التعليم
Industries
3+
Technologies

متى تحتاج هذا

أنت تبني منصة تخدم عدة عملاء من نشر واحد. يتوقع كل عميل بيانات معزولة، وتجارب ذات علامة تجارية، وفوترة لكل مستأجر — ولكن لا يمكنك تحمل تكلفة تشغيل بنية تحتية منفصلة لكل منهم. أنت بحاجة إلى اقتصاديات البنية التحتية المشتركة مع ضمانات العزل للأنظمة المخصصة. هذا هو التوتر الأساسي في هندسة SaaS، وارتكاب خطأ في نموذج العزل مبكرًا هو أحد أغلى الأخطاء في تطوير المنصات.

نظرة عامة على النمط

هل تحتاج إلى مساعدة في تنفيذ هذه العمارة؟

يمكن لفريق معماري لدينا مساعدتك في تصميم وبناء الأنظمة باستخدام هذا النمط لمتطلباتك المحددة.

تواصل معنا

توفر هندسة SaaS متعددة المستأجرين فصلاً منطقيًا أو ماديًا بين المستأجرين مع مشاركة موارد الحوسبة والتخزين والشبكات الأساسية. يشمل النمط توفير المستأجرين، وعزل البيانات، وإدارة الميزات، وقياس الفواتير، والتخصيص ذو العلامة البيضاء (white-label). القرار التصميمي الأساسي هو نموذج العزل: قاعدة بيانات مشتركة مع أمان على مستوى الصف (row-level security)، أو مخطط لكل مستأجر (schema-per-tenant)، أو قاعدة بيانات لكل مستأجر (database-per-tenant). كل نموذج يوازن بين قوة العزل مقابل التعقيد التشغيلي وكفاءة التكلفة.

الهندسة المرجعية

يتكون النظام من ثلاث طبقات. يتعامل البوابة الواعية بالمستأجرين (tenant-aware gateway) مع المصادقة، وتحديد المستأجر (عبر النطاق الفرعي subdomain، أو مطالبة JWT، أو مفتاح API)، وتوجيه الطلبات. تعمل طبقة التطبيق (application layer) بالكامل ضمن سياق المستأجر — كل استعلام، كل مفتاح تخزين مؤقت (cache key)، كل رسالة قائمة انتظار (queue message) محددة للمستأجر المحدد. تفرض طبقة البيانات (data layer) العزل على مستوى التخزين من خلال سياسات أمان على مستوى الصف (row-level security)، وتجميع الاتصالات لكل مستأجر (connection pooling per tenant)، وتقسيم البيانات المشفرة في وضع السكون (encrypted-at-rest partitioning).

المكونات الأساسية
  • خدمة إدارة المستأجرين (Tenant Management Service): تتعامل مع التوفير (provisioning)، وسير عمل الإعداد (onboarding workflows)، وتعيين النطاقات المخصصة (custom domain mapping)، وتكوين المظهر/العلامة التجارية (theme/branding configuration)، وعلامات الميزات لكل مستأجر (per-tenant feature flags). توفر واجهة API داخلية لأحداث دورة حياة المستأجر (تم الإنشاء، تم التعليق، تم الحذف)
  • ناشر سياق المستأجر (Tenant Context Propagator): وسيط (Middleware) يحدد هوية المستأجر من الطلب (النطاق الفرعي subdomain، JWT، الرأس header) ويحقن سياق المستأجر في كل استدعاء لاحق — اتصالات قاعدة البيانات، مفاتيح التخزين المؤقت (cache keys)، رسائل قائمة الانتظار (queue messages)، إدخالات السجل (log entries)
  • محرك عزل البيانات (Data Isolation Engine): ينفذ نموذج العزل المختار. لـ RLS: سياسات PostgreSQL تقوم بتصفية كل استعلام بواسطة tenant_id. لـ schema-per-tenant: توجيه اتصال ديناميكي مع إدارة تجميع الاتصالات. لـ database-per-tenant: أتمتة التوفير باستخدام Terraform/Pulumi
  • خدمة الفوترة والقياس (Billing & Metering Service): تتبع الاستخدام مدفوع بالأحداث مع تجميع لكل مستأجر. تتكامل مع Stripe Connect أو محركات فوترة مخصصة. تدعم نماذج تسعير متعددة (لكل مقعد، على أساس الاستخدام، متدرج، هجين)

قرارات التصميم والمفاضلات

RLS مقابل Schema-per-Tenant مقابل Database-per-Tenant
تعتمد MW افتراضيًا على RLS (قاعدة بيانات مشتركة، أمان على مستوى الصف) لمعظم منتجات SaaS. إنه الأبسط في التشغيل — مسار ترحيل واحد، تجميع اتصال واحد، استراتيجية نسخ احتياطي واحدة. يكون Schema-per-tenant منطقيًا عندما يحتاج المستأجرون إلى امتدادات مخطط مخصصة (نادرة) أو عندما تتطلب المتطلبات التنظيمية عزلًا قابلاً للإثبات. يتم حجز Database-per-tenant للصفقات المؤسسية حيث يتطلب العميل بموجب العقد بنية تحتية مخصصة. لقد قمنا بتسليم الثلاثة — يعتمد الاختيار على موقفك من الامتثال وعدد المستأجرين.
تحديد المستأجر على أساس النطاق الفرعي (Subdomain) مقابل المسار (Path-Based)
النطاقات الفرعية (Subdomains) (acme.yourapp.com) أنظف لمنتجات العلامة البيضاء (white-label) وتسمح بشهادات TLS لكل مستأجر. النمط القائم على المسار (Path-based) (yourapp.com/acme/) أبسط في التنفيذ ويتجنب تعقيد wildcard DNS. توصي MW بتحديد المستأجر على أساس النطاق الفرعي لـ B2B SaaS مع متطلبات العلامة البيضاء، والنمط القائم على المسار للأدوات الداخلية متعددة المستأجرين.
علامات الميزات المشتركة مقابل التكوين لكل مستأجر
نستخدم نظام علامات ميزات ثنائي الطبقات: تتحكم العلامات العامة في النشر عبر المنصة، وتسمح التجاوزات على مستوى المستأجر بتمكين الميزات التجريبية لعملاء محددين أو تعطيل الميزات للمستأجرين على خطط ذات مستوى أدنى. يدعم Edge Config أو LaunchDarkly هذا بقراءات في أقل من مللي ثانية.
التخزين المؤقت الواعي بالمستأجر (Tenant-Aware Caching)
يجب أن يكون كل مفتاح تخزين مؤقت (cache key) محددًا بـ tenant_id. قد يبدو هذا واضحًا، لكن تصادمات مفتاح التخزين المؤقت عبر المستأجرين هي أحد أكثر الأخطاء شيوعًا في الأنظمة متعددة المستأجرين. نفرض ذلك من خلال مصنع لمفاتيح التخزين المؤقت يقوم بإضافة سياق المستأجر تلقائيًا.

خيارات التكنولوجيا

الطبقةالتقنيات
الحوسبة (Compute)Node.js (NestJS), Python (FastAPI), يتم تشغيله في حاويات على ECS Fargate أو Kubernetes
البيانات (Data)PostgreSQL مع RLS، Redis (محدد بالمستأجر)، S3 (دلاء مقسمة بالمستأجر)
الهوية (Identity)Clerk، Auth0، أو Okta مع منظمات محددة بالمستأجر
الفوترة (Billing)Stripe Connect (نموذج السوق)، Stripe Billing (اشتراكات مقاسة)
المراقبة (Observability)Datadog مع علامات أبعاد المستأجر، تسجيل منظم مع tenant_id على كل إدخال

متى تستخدم / متى تتجنب

تستخدم عندماتتجنب عندما
بناء منصة B2B تخدم 10+ عملاء من بنية تحتية مشتركةيتطلب كل عميل بنية تحتية مخصصة بالكامل (امتثال/تعاقدي)
تحتاج إلى علامة تجارية بيضاء (white-label branding)، نطاقات مخصصة، وتحكم في الميزات لكل مستأجرلديك أقل من 3 عملاء — قد يكون النشر الأبسط لكل عميل كافيًا
يتطلب التسعير القائم على الاستخدام أو المتدرج قياسًا لكل مستأجرالمنتج هو تطبيق استهلاكي بحسابات على مستوى المستخدم، وليس مستأجرين على مستوى المؤسسة
تريد مسار نشر واحد، مكدس مراقبة واحد، دورة استدعاء واحدةلدى المستأجرين مخططات (schemas) أو منطق عمل (business logic) مختلف جوهريًا (وليس مجرد تكوين)

نهجنا

تعتبر MW التعددية المستأجرة (multi-tenancy) اهتمامًا شاملاً (cross-cutting concern)، وليست ميزة. نقوم بتنفيذ نشر سياق المستأجر على مستوى الوسيط (middleware) بحيث لا يقوم رمز التطبيق بتصفية يدوية حسب المستأجر — يتم فرض ذلك بواسطة الإطار (framework). تتضمن تطبيقات RLS لدينا مجموعات اختبار آلية تحاول الوصول إلى البيانات عبر المستأجرين في كل تشغيل CI. لقد قمنا ببناء منصات متعددة المستأجرين تخدم أكثر من 500 مستأجر على بنية تحتية مشتركة مع عدم وجود حوادث تسرب بيانات، وقمنا بترحيل الأنظمة المتجانسة ذات المستأجر الواحد (single-tenant monoliths) إلى معماريات متعددة المستأجرين باستخدام نمط التين الخانق (strangler fig pattern).

مخططات ذات صلة

  • SaaS تدريب على العافية متعدد المستأجرين (Multi-Tenant Wellness Coaching SaaS) — عزل RLS مع علامة بيضاء للعلامة التجارية لأعمال التدريب
  • منصة تعليم شخصي مدعومة بالذكاء الاصطناعي (AI-Driven Personalized Learning Platform) — EdTech متعدد المستأجرين مع مكتبات محتوى لكل مستأجر
  • منصة إدارة الفعاليات والتذاكر (Event Management & Ticketing Platform) — مستأجر لكل منظم مع إصدار تذاكر في الوقت الفعلي
  • محرك الفوترة والاشتراكات متعدد المستأجرين (Multi-Tenant Billing & Subscription Engine) — العمود الفقري للفوترة للمنصات متعددة المستأجرين

دراسات حالة ذات صلة

  • SaaS تدريب VR متعدد المستأجرين (VR Training Multi-Tenant SaaS) — منصة متعددة المستأجرين بمحتوى وتحليلات VR محددة بالمستأجر
  • منصة دردشة AI (AI Chat Platform) — SaaS دردشة متعدد النماذج مع إدارة مفاتيح API لكل مستأجر وامتثال GDPR
Related Technologies
تطوير SaaSحلول سحابيةتطوير AI

الأسئلة الشائعة

يعتمد الخيار الأمثل على متطلبات عزل المستأجرين وحجم العمل لديك. توصي MicrocosmWorks عادةً بنهج 'قاعدة بيانات مشتركة، مخططات منفصلة' (shared-database, separate-schema) لمعظم منتجات B2B SaaS لأنه يوازن بين كفاءة التكلفة وعزل البيانات، على الرغم من أننا نطبق 'قاعدة بيانات لكل مستأجر' (database-per-tenant) للعملاء في الصناعات المنظمة مثل الرعاية الصحية أو المالية حيث يكون الفصل الصارم للبيانات إلزاميًا. يقوم مهندسونا المعماريون بتقييم احتياجات الامتثال لديك، والعدد المتوقع للمستأجرين، وأنماط الاستعلام قبل التوصية بنموذج الاستئجار الصحيح.

تطبق MicrocosmWorks تحديد معدل الاستخدام المدرك للمستأجرين (tenant-aware rate limiting)، وتجميع الاتصالات (connection pooling) بحصص لكل مستأجر (per-tenant quotas)، وعزل الموارد على طبقة الحوسبة (compute layer) لمنع مشاكل 'الجيران المزعجين' (noisy-neighbor problems). نستخدم تقنيات مثل الجدولة العادلة المرجحة (weighted fair queuing) وطبقات التخزين المؤقت الخاصة بالمستأجرين (tenant-specific caching tiers) حتى لا يؤدي الارتفاع المفاجئ من عميل واحد إلى زمن انتقال (latency) للآخرين. بالنسبة للمستأجرين من فئة المؤسسات (enterprise-tier tenants)، يمكننا توفير أقسام حوسبة مخصصة (dedicated compute partitions) مع الحفاظ على مستوى التحكم المشترك (shared control plane) سليمًا.

تقدم MicrocosmWorks خدمات تصميم وتنفيذ البنية بأسعار استشارية تتراوح بين 15 و 45 دولارًا في الساعة، اعتمادًا على التعقيد وخبرة الفريق المطلوبة. تستغرق مشاريع بنية SaaS متعددة المستأجرين النموذجية — والتي تغطي تصميم قاعدة البيانات، وعزل المستأجرين، والمصادقة، ومسارات النشر (deployment pipelines) — من 8 إلى 16 أسبوعًا مع فريق متعدد الوظائف (cross-functional team). نحن نحدد نطاق كل مشروع من خلال مرحلة اكتشاف بسعر ثابت (fixed-price discovery phase) ليكون لديك رؤية كاملة للتكلفة قبل الالتزام بالبناء.

تبني MicrocosmWorks مسارات مؤتمتة لتزويد المستأجرين (automated tenant provisioning pipelines) تتعامل مع إنشاء المخطط (schema creation)، وتكوين DNS، وتهيئة علامات الميزات (feature flag initialization)، ونشر البيانات الأولية (seed data deployment) في غضون دقائق من التسجيل الجديد. نستخدم أدوات البنية التحتية كتعليمات برمجية (infrastructure-as-code tools) مثل Terraform أو Pulumi جنبًا إلى جنب مع مسارات العمل المعتمدة على الأحداث (event-driven workflows) حتى يحصل كل مستأجر جديد على بيئة مهيأة بالكامل دون تدخل يدوي. يتيح هذا النهج لعملائنا التوسع من 10 مستأجرين إلى 10,000 دون تغيير عملية الإعداد (onboarding process).

تطبق MicrocosmWorks طبقة تخصيص تعتمد على التكوين (configuration-driven customization layer) باستخدام علامات الميزات (feature flags)، والبيانات الوصفية الخاصة بالمستأجر (tenant-specific metadata)، وبنية المكونات الإضافية (plugin architecture) التي تسمح بسلوك خاص بكل مستأجر (per-tenant behavior) دون تفريع الكود (code branching). نصمم نقاط التوسع (extensibility points) في تنسيق واجهة المستخدم (UI theming)، ومحرك سير العمل (workflow engine)، وطبقات التكامل (integration layers) حتى يتمكن المستأجرون من الحصول على علامة تجارية فريدة (unique branding)، وقواعد عمل (business rules)، واتصالات طرف ثالث (third-party connections) تُدار جميعها من خلال التكوين. هذا يبقي فريق الهندسة لديك يدير قاعدة كود واحدة (single codebase) مع دعم متطلبات العملاء المتنوعة.