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

أنت تبني منصة تخدم عدة عملاء من نشر واحد. يتوقع كل عميل بيانات معزولة، وتجارب ذات علامة تجارية، وفوترة لكل مستأجر — ولكن لا يمكنك تحمل تكلفة تشغيل بنية تحتية منفصلة لكل منهم. أنت بحاجة إلى اقتصاديات البنية التحتية المشتركة مع ضمانات العزل للأنظمة المخصصة. هذا هو التوتر الأساسي في هندسة SaaS، وارتكاب خطأ في نموذج العزل مبكرًا هو أحد أغلى الأخطاء في تطوير المنصات.
Explore more design patterns and system architectures
يمكن لفريق معماري لدينا مساعدتك في تصميم وبناء الأنظمة باستخدام هذا النمط لمتطلباتك المحددة.
تواصل معناتوفر هندسة 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_id. لـ schema-per-tenant: توجيه اتصال ديناميكي مع إدارة تجميع الاتصالات. لـ database-per-tenant: أتمتة التوفير باستخدام Terraform/Pulumiacme.yourapp.com) أنظف لمنتجات العلامة البيضاء (white-label) وتسمح بشهادات TLS لكل مستأجر. النمط القائم على المسار (Path-based) (yourapp.com/acme/) أبسط في التنفيذ ويتجنب تعقيد wildcard DNS. توصي MW بتحديد المستأجر على أساس النطاق الفرعي لـ B2B SaaS مع متطلبات العلامة البيضاء، والنمط القائم على المسار للأدوات الداخلية متعددة المستأجرين.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).
النماذج لا تعمل من تلقاء نفسها. خط الأنابيب الذي يدرب نماذجك ويتحقق منها وينشرها ويراقبها هو المنتج الفعلي — النموذج هو مجرد ناتج واحد.
الخيار الأمثل يعتمد على متطلبات عزل المستأجرين لديك وحجم العمل. توصي MicrocosmWorks عادةً بنهج قاعدة بيانات مشتركة ومخطط منفصل لمعظم منتجات SaaS من نوع B2B لأنه يوازن بين كفاءة التكلفة وعزل البيانات، على الرغم من أننا نطبق نموذج قاعدة بيانات لكل مستأجر للعملاء في الصناعات المنظمة مثل الرعاية الصحية أو المالية حيث يكون الفصل الصارم للبيانات إلزاميًا. يقوم مهندسونا بتقييم احتياجات الامتثال الخاصة بك، وعدد المستأجرين المتوقع، وأنماط الاستعلام قبل التوصية بنموذج الاستضافة الصحيح.
تطبق MicrocosmWorks تقنيات tenant-aware rate limiting، وconnection pooling مع per-tenant quotas، وresource isolation على مستوى الـcompute layer لمنع noisy-neighbor problems. نستخدم أساليب مثل weighted fair queuing وtenant-specific caching tiers لضمان أن الارتفاع المفاجئ من عميل واحد لا يتسبب في latency للآخرين. بالنسبة لـenterprise-tier tenants، يمكننا provision dedicated compute partitions مع الحفاظ على سلامة الـshared control plane.
تقدم MicrocosmWorks خدمات تصميم وتنفيذ البنية بأسعار استشارية تتراوح بين 15 و 45 دولارًا أمريكيًا في الساعة، اعتمادًا على التعقيد ودرجة خبرة الفريق المطلوبة. تستغرق مهمة تصميم بنية SaaS متعددة المستأجرين (multi-tenant SaaS architecture) النموذجية — التي تشمل تصميم قاعدة البيانات (database design)، وعزل المستأجرين (tenant isolation)، والمصادقة (authentication)، وخطوط أنابيب النشر (deployment pipelines) — من 8 إلى 16 أسبوعًا مع فريق متعدد التخصصات. نحدد نطاق كل مشروع من خلال مرحلة اكتشاف بسعر ثابت لتوفير رؤية كاملة للتكلفة قبل الالتزام بالبناء.
تبني MicrocosmWorks مسارات آلية لتهيئة المستأجرين تتعامل مع إنشاء المخططات، وتهيئة DNS، وتهيئة علامات الميزات، ونشر البيانات الأولية في غضون دقائق من التسجيل الجديد. نحن نستخدم أدوات infrastructure-as-code مثل Terraform أو Pulumi بالاقتران مع مسارات عمل تعتمد على الأحداث، بحيث يحصل كل مستأجر جديد على بيئة مهيأة بالكامل دون تدخل يدوي. يتيح هذا النهج لعملائنا التوسع من 10 مستأجرين إلى 10,000 دون تغيير عملية انضمام المستأجرين.
تطبق MicrocosmWorks طبقة تخصيص قائمة على التهيئة باستخدام feature flags و metadata خاصة بالمستأجرين، وهندسة معمارية قائمة على المكونات الإضافية (plugin architecture) تتيح سلوكًا خاصًا لكل مستأجر دون تفرع في الكود. نصمم نقاط قابلية التوسع في طبقات UI theming و workflow engine والتكامل، بحيث يمكن للمستأجرين الحصول على علامة تجارية فريدة وقواعد عمل واتصالات مع أطراف ثالثة، تُدار جميعها من خلال التهيئة. وهذا يحافظ على فريقكم الهندسي في إدارة قاعدة أكواد واحدة مع دعم متطلبات العملاء المتنوعة.