Laravel متعددة المستأجرين تغطي مشكلتين مختلفتين حقاً يُناقشان كواحدة.
السوق لديه العديد من البائعين المستقلين الذين لا يثقون ببعضهم البعض، استخدام غير متساوٍ بشكل كبير، تسجيل ذاتي الخدمة وواجهة متجر عامة واحدة. مجموعة تجزئة متعددة العلامات التجارية لديها عدد قليل من المستأجرين تحت مالك واحد، استخدام متقارب، تسجيل مقصود وواجهة متجر منفصلة لكل علامة تجارية. يشتركون في كلمة مستأجر ولا شيء تقريباً غير ذلك.
الحصول على البنية الصحيحة يعني أن تكون واضحاً أيهما تبني، لأن عدة قرارات تنعكس بينهما.
حلّ تحديد المستأجر: القرار الذي يتوقف عليه كل شيء
كيف يعرف التطبيق أي مستأجر ينتمي إليه الطلب. هناك ثلاثة إجابات عملية وليست متكافئة.
- النطاق أو النطاق الفرعي —
brand-a.example.com، أو نطاقات منفصلة تماماً. الإجابة الصحيحة لتجزئة العلامات التجارية المتعددة، حيث يحتاج كل علامة إلى هويتها الخاصة، سطح SEO خاص وشهاداتها الخاصة. - بادئة المسار —
/sellers/acme/. بسيطة، رخيصة، وتحافظ على كل شيء في نطاق واحد، وهذا يناسب السوق حيث العلامة التجارية للسوق هي المهمة. - سياق المستخدم المصادق عليه — لا يوجد مستأجر في عنوان URL على الإطلاق. صحيح لتطبيقات المكتب الخلفي، خاطئ لأي شيء به واجهة متجر عامة، لأن نفس العنوان يعرض بشكل مختلف لمستخدمين مختلفين ويصبح التخزين المؤقت مخاطرة.
حدد المستأجر مرة واحدة، في الطبقة الوسيطة، قبل تشغيل أي شيء آخر، واربطه في الحاوية. يجب أن يكون بإمكان كل قطعة من الكود لاحقاً أن تسأل من هو المستأجر الحالي دون معرفة كيف تم تحديد ذلك — وهذا ما يسمح لك بتغيير الإجابة لاحقاً.
الخطأ الهيكلي الأكثر شيوعاً هو تحديد المستأجر في وحدة تحكم. يعمل حتى أول مهمة مجدولة، أمر مجدول أو webhook، لا يوجد أي منها طلب لتحديده. اربطه مركزياً، واجعل حالة عدم وجود مستأجر واضحة وصاخبة.
عزل البيانات
لقد غطينا نماذج التأجير الثلاثة — المخطط المشترك، مخطط لكل مستأجر، قاعدة بيانات لكل مستأجر — واقتصادياتها في مقارنة نماذج التأجير. الآليات الخاصة بـ Laravel هي المهمة هنا.
بالنسبة لـالمخطط المشترك، الذي يناسب معظم الأسواق:
- فرض التحديد على مستوى النظام بأكمله، وليس لكل استعلام على حدة. تعمل نطاقات Laravel العالمية، لكن التحكم الأقوى هو أمان مستوى الصف في قاعدة البيانات — لأن النطاق العالمي يمكن للمطور إزالته بسرعة، أما سياسة قاعدة البيانات فلا يمكن ذلك.
- اجعل الاستعلام بدون مستأجر واضحًا. اجعل نموذجك الأساسي يرمي استثناءً عند عدم ربط مستأجر، حتى يفشل العمل الذي نسي تعيين السياق فورًا بدلاً من قراءة كل شيء.
- راقب الاستعلامات الخام وكود التقارير. استدعاءات منشئ الاستعلام التي تتجاوز Eloquent تتجاوز نطاقاتك معها. هنا تكمن التسريبات.
- قم بفهرسة tenant_id أولاً في الفهارس المركبة، وإلا ستقوم كل استعلامات بمسح أكثر مما ينبغي.
بالنسبة لـقاعدة بيانات لكل مستأجر، المناسبة لمجموعات العلامات التجارية المتعددة التي تتطلب فصلًا حقيقيًا، تتغير الآليات: تبديل الاتصال في الوسيط، وترحيلات لكل مستأجر يجب أن تكون مقاومة للفشل الجزئي عبر النظام، بالإضافة إلى بادئة ذاكرة التخزين المؤقت والطابور لكل مستأجر لضمان عدم حدوث تسرب. كل ذلك معروف جيدًا؛ ويجب أتمتته قبل أن تحصل على أعداد مستأجرين حقيقية وليس بعدها.
قوائم الانتظار هي المكان الذي يتعطل فيه تعدد المستأجرين
الجزء الذي تخطئ فيه معظم التطبيقات، والذي يسبب أسوأ الحوادث.
- قم بتسلسل المستأجر داخل العمل دائمًا. العمل الذي يحدد المستأجر من أي سياق عام سينفذ في النهاية في السياق الخطأ، والفشل يكون صامتًا وعبر المستأجرين.
- استعد سياق المستأجر في بداية كل عمل، وفشل بشكل صارم إذا لم يمكن تأسيسه.
- عزل المستأجرين المزعجين. لا يجب أن يؤخر بائع واحد يستورد 200,000 منتج تأكيدات طلبات المستأجرين الآخرين. على الأقل، افصل الطوابير حسب نوع عبء العمل، وحدود المعدل لكل مستأجر حيث يكون المستأجرون غير موثوقين.
- اجعل الأوامر المجدولة تتكرر عبر المستأجرين صراحةً، مع عزل فشل لكل مستأجر — يجب ألا يؤدي بيانات مستأجر سيئة إلى إلغاء التشغيل للجميع.
- فكر في الأعمال الفاشلة. جدول الأعمال الفاشلة بدون سياق مستأجر غير قابل للاستخدام على نطاق واسع، وإعادة المحاولة العمياء تؤدي إلى عمليات كتابة عبر المستأجرين.
اختبار مفيد: أوقف عمال الطابور، دع تراكمًا يتكون، ثم أعد التشغيل. إذا عُولجت الأعمال في سياق مستأجر خاطئ، أو إذا جاع تراكم مستأجر واحد الجميع، فقد وجدت الفشل قبل عملائك.
مشكلات خاصة بالـ marketplace
أمور لا تحتاج مجموعة علامات تجارية متعددة إلى حلها أبدًا:
- تقسيم المدفوعات والمستحقات. طلب يشمل ثلاثة بائعين هو دفعة واحدة وثلاث تسويات، مع احتساب العمولة، والاستردادات، والاعتراضات، والضريبة بشكل صحيح. عادةً ما يكون هذا أصعب مشكلة في المجال وتتبعها المالية، وليس الهندسة.
- إدخال البائع والتحقق منه. الخدمة الذاتية تعني مدخلات غير موثوقة على نطاق واسع — فحوصات الهوية، التحقق البنكي، فحص الاحتيال.
- مراقبة الجودة. بيانات المنتج، الصور، والتسعير تأتي من آلاف المصادر بدون معيار مشترك. من يملك جودة الكتالوج يملك تجربة العميل.
- الجدولة العادلة. كل مورد مشترك — الطوابير، فهرسة البحث، حدود معدل API، توليد التقارير — يحتاج إلى سياسة عدالة، وإلا يستهلك أكبر مستأجر المنصة.
- تحليلات موجهة للبائع يجب أن تكون سريعة، معزولة، وغير قادرة على كشف أي شيء عن بائع آخر.
لقد بنينا هذا النموذج أكثر من مرة — سوق Scout Arabia متعدد البائعين وPriceGuru كلاهما يعملان هنا، على بنية مختلفة لكن بمشاكل هيكلية متطابقة. منصة التجارة تتغير؛ تسوية المستحقات لا تتغير.
مشكلات التجزئة متعددة العلامات التجارية
المجموعة العكسية:
- كتالوج مشترك مع تجاوزات لكل علامة تجارية. منتج واحد يباع من قبل ثلاث علامات تجارية، بثلاثة أسعار، وثلاثة أوصاف، ويجب أن ينتشر التغيير في المنتج الأساسي بشكل متوقع.
- تقارير موحدة عبر العلامات التجارية بينما ترى كل علامة تجارية نفسها فقط.
- هوية العملاء المشتركة — أو عدمها عمدًا. هذا سؤال قانوني قبل أن يكون تقنيًا، ويختلف حسب الاختصاص القضائي.
- تخصيص لكل علامة تجارية لا يتحول إلى خمسة قواعد شفرة. الانضباط هو مكتبة مكونات مشتركة مع رموز العلامة التجارية، وليس قوالب متفرعة.
- مخزون مشترك عبر العلامات التجارية، وهو إما ميزة كبيرة أو مصدر صراع مستمر حسب كيفية تشغيل العمل فعليًا.
ما الذي يجب قراره قبل كتابة الكود
- هل يمكن للمستخدم الانتماء لأكثر من مستأجر؟ تعديل نموذج المصادقة الذي افترض خلاف ذلك هو من أصعب عمليات إعادة الهيكلة.
- هل معرف المستأجر عام؟ بمجرد ظهوره في عناوين URL وواجهات API، يبني العملاء عليه ويتوقف عن كونه ملكك لتغييره.
- أين تعيش إعدادات كل مستأجر — في بيانات المستأجر نفسه، أم في سجل مركزي؟ كلاهما يعمل؛ المزج بينهما لا يعمل.
- ماذا يحدث عند دمج أو تقسيم المستأجرين؟ نادر وقاسٍ. الأسواق تستحوذ على بعضها البعض؛ مجموعات العلامات التجارية تعيد الهيكلة.
- كيف يغادر المستأجر؟ التصدير الكامل والحذف التام هما التزامات تعاقدية في معظم الأسواق، وهما أصعب كثيرًا للإضافة لاحقًا.
هذا هو العمل الذي يقوم به فريق Laravel لدينا قبل بدء البناء، وهو جزء من ممارسة منصة Laravel الأوسع لدينا. بالنسبة لـمجموعات التجزئة الشكل متعدد العلامات التجارية هو الشائع؛ أما بالنسبة لـمنصات اللوجستيات والمالية فعادةً ما يكون أقرب إلى نهاية السوق.
الأسئلة الشائعة
هل نستخدم حزمة لتعدد المستأجرين أم نبنيها بأنفسنا؟
حزمة مُدارة جيدًا توفر وقتًا حقيقيًا في تبديل الاتصالات، ترحيلات كل مستأجر، وإضافة بادئات إلى الكاش، وتستحق الاستخدام. ما يجب أن تملِكه داخليًا هو حلّ تحديد المستأجر وفرض النطاق — فهما حدّ الأمان الخاص بكم، ولا ينبغي أن يكونا تبعية لا يمكنكم الاطّلاع عليها.
كيف نمنع مستأجرًا واحدًا من إبطاء الجميع؟
افصلوا قوائم الانتظار بحسب نوع عبء العمل، وضعوا حدود معدلات لكل مستأجر على الموارد المشتركة، وجدولة عادلة لأي عملية مكلفة مثل فهرسة البحث أو توليد التقارير. اختبروها عبر إنشاء تراكم عمل متعمد ومراقبة ما إذا كان مستأجر واحد يمكنه تجويع الآخرين.
هل يمكن للمستخدم الانتماء إلى عدة مستأجرين؟
قرروا ذلك قبل البناء. إضافة عضوية متعددة المستأجرين إلى نموذج مصادقة افترض مستأجرًا واحدًا لكل مستخدم تؤثر على الجلسات، الأذونات، كل استعلام مُقَيَّد وكل واجهة حساب المستخدم. السماح بذلك يكلف قليلًا في البداية وكثيرًا لاحقًا.
ما الذي يميز الـ marketplace عن مجموعة متعددة العلامات التجارية؟
الثقة وقابلية التوسّع. الـ marketplace يضم العديد من المستأجرين غير الموثوقين الذين يسجلون ذاتيًا ولديهم استخدام متفاوت، لذا تهيمن العزل، العدالة ومطابقة المدفوعات. أما مجموعة متعددة العلامات التجارية فتضم عددًا قليلاً من المستأجرين الموثوقين تحت مالك واحد، لذا يهيمن الكتالوج المشترك، التقارير الموحدة والتخصيص لكل علامة بدلاً من ذلك.
كيف ندير تسويات المدفوعات للبائعين؟
عاملوا ذلك كمجال للمالية لا كمشكلة هندسية. دفعة زبون واحدة تتحول إلى تسويات متعددة مع عمولة، مرتجعات، استردادات ورسوم عكسية والضريبة المنسوبة لكل بائع — ويجب أن تتطابق التسويات بدقة. أدرجوا فريق المالية في نموذج البيانات منذ الأسبوع الأول؛ هذا عادةً أصعب جزء في بناء الـ marketplace.
احصل على النموذج الصحيح أولًا
تحديد المستأجر، العزل، وسياق الطابور قرارات رخيصة وتغييراتها مكلفة. سنراجع نظامك مقارنةً بالشكل الذي تبنيه فعليًا. تحدث إلى فريقنا؛ نرد خلال يوم عمل.