برنامج الأسواق الإلكترونية
نظام السوق الإلكتروني لا يستقبل الطلبات فحسب: بل يعزل بيانات آلاف البائعين في قاعدة البيانات نفسها، ويقسّم الطلب الخارج من سلة واحدة على أطراف متعددة، ويفعل ذلك تحت الحركة المفاجئة في أيام الحملات. وتشرح هذه الصفحة كيف بُنيت المعمارية.
- كل قدرة توجد أولاً كواجهة API
- API-firstكل قدرة توجد أولاً كواجهة API
- طبقة التطبيق بلا حالة؛ ويُزاد عدد النسخ
- توسّع أفقيطبقة التطبيق بلا حالة؛ ويُزاد عدد النسخ
- خيار التشغيل على خادمك الخاص
- سحابي أو on-premiseخيار التشغيل على خادمك الخاص
- قاعدة البيانات والملفات تحت سيطرتك
- ملكية البياناتقاعدة البيانات والملفات تحت سيطرتك
لماذا تكون القرارات المعمارية أغلى القرارات تصحيحاً لاحقاً؟
الأسئلة التي تُطرَح عند اختيار برنامج marketplace تختلف عن تلك التي تُطرَح عند اختيار حزمة تجارة إلكترونية أحادية البائع. فالنظام هنا لا يستقبل الطلبات فحسب؛ بل يعزل في قاعدة البيانات نفسها بيانات آلاف البائعين الذين لا يعرف بعضهم بعضاً، ويطبّق نطاق صلاحيات منفصلاً لكل بائع، ويقسّم الطلب الخارج من سلة واحدة على أطراف متعددة، ويفعل ذلك كله تحت الحركة المفاجئة في أيام الحملات.
ولهذا فإن القرارات المعمارية هي أغلى القرارات تصحيحاً في وقت لاحق. فعمق شجرة التصنيفات، وطريقة حفظ خصائص المنتجات، وما إذا كانت طبقة البحث منفصلة عن قاعدة البيانات، وأين يقع تخزين الملفات؛ هذه كلها لا تظهر في الأشهر الأولى، لكنها تحدّد سقف النظام عند حجم المليون سجل. وكذلك ينبغي تصميم نموذج المصادقة والصلاحيات ملائماً للبنية متعددة المستأجرين من البداية.
والمسألة الثالثة هي الاستقلالية. فمؤسسة الدفع وشركة الشحن وخدمة الفوترة تتغيّر مع الوقت؛ والنظام الموصول بها مباشرةً يُعاد كتابته عند كل تغيير. والواجهات المستقلة عن المزوّد تزيل هذا الخطر. والمنطق نفسه يسري على جانب التركيب: فكون البرنامج لا يعمل إلا لدى مزوّد سحابي واحد قيدٌ على المدى الطويل.
طبقات التطبيق والبيانات
على اليمين كيف يُقسَّم منطق العمل، وعلى اليسار أين تقع البيانات. وكلما كبر الحجم صار العمود الأيسر هو الحاسم.
طبقات التطبيق
- طبقة API: كل قدرة توجد أولاً كنقطة نهاية، والواجهات تستهلكها
- منطق عمل معياري: مجالات الطلبات والدفع والشحن والبائعين في وحدات منفصلة
- واجهات مستقلة عن المزوّد: تُربَط تكاملات الدفع والشحن والفوترة بعقد موحّد
- محرّك سير العمل: تُعرَّف الأتمتة القائمة على القواعد دون تغيير برمجي
- طبقة الواجهة: واجهة تُبنى على الخادم ومفتوحة لمحركات البحث
- لوحة الإدارة ولوحة البائع واجهتان منفصلتان بواجهة API مشتركة
طبقات البيانات والبنية التحتية
- قاعدة بيانات علائقية: للبيانات التي تتطلب اتساقاً كالطلبات والمدفوعات والمستحقات
- محرّك بحث (Typesense): فصل بحث الكتالوج عن قاعدة البيانات
- طبقة تخزين مؤقت: لتفادي إعادة احتساب بيانات الكتالوج والمحتوى كثيرة القراءة
- تخزين كائنات: لصور المنتجات والملفات؛ مع التوزيع عبر CDN
- الطوابير والمهام الخلفية: الاستيراد الجماعي والإشعارات وإرسال webhook
- سجلات العمليات وسجل التدقيق
الضمانات التقنية التي توفّرها البنية
عزل البيانات متعدد المستأجرين
تُفصَل بيانات البائعين على مستوى المنظمة؛ ويمر كل استعلام بفحص النطاق. ويُمنَع معمارياً وصولُ بائع إلى بيانات بائع آخر.
التحكم بالوصول القائم على الأدوار
نطاقات صلاحيات منفصلة لمدير المنصة والبائع وموظف البائع والعميل. وتُعرَّف الأذونات على مستوى المورد.
طبقة بحث منفصلة
لا يُحمِّل بحثُ الكتالوج قاعدةَ البيانات. تحمّل للأخطاء الإملائية، وفلترة متعددة الأوجه، واستجابة بأجزاء من الثانية عند حجم المليون سجل.
التوسّع الأفقي
تعمل طبقة التطبيق بلا حالة؛ فيُزاد عدد النسخ عند ارتفاع الحركة. وتُضاف الموارد دون انقطاع في أيام الحملات.
معمارية التخزين المؤقت وCDN
يُخزَّن الكتالوج والمحتوى مؤقتاً، وتُوزَّع الصور عبر CDN. فينخفض عدد الطلبات الواصلة إلى الخادم المصدر بوضوح.
محرّك سير العمل
تُعرَّف قواعد الشرط والإجراء من اللوحة؛ فلا يلزم إصدار نسخة جديدة لأتمتة جديدة.
طبقة Webhook والأحداث
تُرسَل أحداث النظام إلى الأنظمة الخارجية بطلبات موقّعة؛ وتُعاد محاولة الإرسال الفاشل ويُوضَع في الطابور.
بنية متعددة اللغات والعملات
يُدار المحتوى والكتالوج على مستوى اللغة؛ وتُنتَج بنية الروابط والبيانات المنظّمة لكل لغة على حدة.
طبقة الأمان
مصادقة قائمة على الرموز، ومفاتيح API على أساس النطاق، وحدود المعدل، وسجل التدقيق.
واجهة مفتوحة لمحركات البحث
تُبنى صفحات الواجهة على الخادم؛ فيرى محرك البحث المحتوى دون تشغيل JavaScript. وتأتي البيانات المنظّمة وإدارة canonical جاهزة.
إدارة الإصدارات والنشر
تُفصَل بيئات الاختبار والتحضير والإنتاج؛ وتُطبَّق التحديثات بشكل محكوم.
قابلية التوسيع
تُوصَل الوحدات الإضافية وتطبيقات الأطراف الثالثة عبر طبقة API نفسها؛ دون تغيير الكود الأساسي.
مقارنة بين السحابي وOn-Premise والهجين
يُتَّخذ القرار عادةً بدافع الامتثال لا التقنية: فالحاسم هو أين يجب أن تبقى البيانات.
| المعيار | سحابي (مُدار) | On-premise | هجين |
|---|---|---|---|
| مسؤولية الخادم | علينا | عليك | مشتركة |
| موقع البيانات | السحابة في المنطقة المختارة | مركز بياناتك أنت | البيانات الحساسة لديك والباقي في السحابة |
| التوسّع | إضافة الموارد سريعة ومرنة | محدود بسعة العتاد | يختلف بحسب الطبقة |
| التكلفة الابتدائية | منخفضة | تتطلب استثماراً في العتاد | متوسطة |
| متطلبات الامتثال | كافٍ لمعظم السيناريوهات | مناسب إن وجب بقاء البيانات داخل البلد | مناسب عند وجود قيود جزئية |
| الصيانة والتحديث | من جانبنا | يُخطَّط له مع فريق تقنية المعلومات لديك | مُقتسَمة |
لأي الفرق تناسب هذه البنية؟
الشركات التي لديها فريق تطوير خاص
يستطيع فريقك كتابة واجهته الأمامية باستخدام طبقة API، وإضافة وحدات مخصصة، وربطها بأنظمته الحالية. وتستمر في تلقّي تحديثات النواة.
طبقة API وWebhookأصحاب متطلبات تقنية المعلومات والامتثال المؤسسي
يُضبَط تعاقدياً أين تبقى البيانات ومن يصل إليها وكيف تُنسَخ احتياطياً. والتركيب on-premise وسجل التدقيق جاهزان لهذه السيناريوهات.
المشاريع عالية الحركة
في المشاريع التي تتضاعف فيها الحركة أيام الحملات، تعمل معاً طبقةُ البحث المنفصلة والتخزينُ المؤقت والتوسّعُ الأفقي.
الراغبون في استخدام headless
يمكنك استخدام المنصة كطبقة بيانات ومنطق عمل فقط، وكتابة الواجهة بالتقنية التي تختارها.
التجارة الإلكترونية Headlessأربع مسائل تُتابَع بعد الانتقال إلى الإنتاج
المراقبة والتنبيه
تُراقَب أزمنة الاستجابة ونسب الأخطاء وتأخيرات الطوابير؛ ويُنتَج تنبيه عند تجاوز العتبة.
النسخ الاحتياطي والاستعادة
نسخ احتياطي منتظم وتمرين استعادة؛ فالمهم ليس وجود النسخة بل القدرة على العودة.
انضباط الوصول
يُقيَّد الوصول إلى بيئة الإنتاج على أساس الأدوار وتُسجَّل جميع العمليات في سجل التدقيق.
تخطيط السعة
يُخطَّط لاختبار الحمل وزيادة الموارد قبل الحملات؛ فقرار التوسّع لا يُتَّخذ بعد وصول الحركة.
الأسئلة الشائعة
أكثر الأسئلة تكراراً لدى الفرق التقنية وصنّاع قرار تقنية المعلومات.
صفحات ذات صلة
التجارة الإلكترونية متعددة البائعين
الجانب التشغيلي للعمل: ديناميكيات السوق ثنائي الجانب ونسبة العمولة والعمليات.
تكامل API للسوق الإلكتروني
سطح REST API وأحداث webhook وأنماط التكامل.
التجارة الإلكترونية Headless
كتابة الواجهة بتقنيتك واستخدام المنصة كطبقة بيانات.
جميع ميزات السوق الإلكتروني
شرح كامل لوحدات البنية وتفاصيلها التقنية.
لنقيّم معاً متطلباتك المعمارية
لنخطّط لاجتماع تقني حول الحجم المتوقع وقائمة التكاملات ونموذج تركيبك.
خيار on-premise · ملكية البيانات لك · دعم على مدار الساعة