المعمارية والبنية التحتية

برنامج الأسواق الإلكترونية

نظام السوق الإلكتروني لا يستقبل الطلبات فحسب: بل يعزل بيانات آلاف البائعين في قاعدة البيانات نفسها، ويقسّم الطلب الخارج من سلة واحدة على أطراف متعددة، ويفعل ذلك تحت الحركة المفاجئة في أيام الحملات. وتشرح هذه الصفحة كيف بُنيت المعمارية.

كل قدرة توجد أولاً كواجهة 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
التشغيل

أربع مسائل تُتابَع بعد الانتقال إلى الإنتاج

المراقبة والتنبيه

تُراقَب أزمنة الاستجابة ونسب الأخطاء وتأخيرات الطوابير؛ ويُنتَج تنبيه عند تجاوز العتبة.

النسخ الاحتياطي والاستعادة

نسخ احتياطي منتظم وتمرين استعادة؛ فالمهم ليس وجود النسخة بل القدرة على العودة.

انضباط الوصول

يُقيَّد الوصول إلى بيئة الإنتاج على أساس الأدوار وتُسجَّل جميع العمليات في سجل التدقيق.

تخطيط السعة

يُخطَّط لاختبار الحمل وزيادة الموارد قبل الحملات؛ فقرار التوسّع لا يُتَّخذ بعد وصول الحركة.

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

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

أكثر الأسئلة تكراراً لدى الفرق التقنية وصنّاع قرار تقنية المعلومات.

في أربع نقاط. الأولى تعدد المستأجرين: ينبغي عزل بيانات آلاف البائعين في قاعدة البيانات نفسها ومرور كل استعلام بفحص النطاق. والثانية الصلاحيات: تلزم نطاقات أذونات منفصلة لمدير المنصة والبائع وموظف البائع والعميل. والثالثة تقسيم الطلب: يُوزَّع الطلب الخارج من سلة واحدة على أطراف متعددة ويسلك كل جزء دورة حياة مستقلة. والرابعة الفصل المالي: ينبغي تسجيل العمولة والمستحقات كبندين منفصلين في كل معاملة.
القرار الحاسم هو فصل طبقة البحث عن قاعدة البيانات. فبحث الكتالوج يعمل على Typesense؛ ويمضي التحمّل للأخطاء الإملائية والفلترة المتعددة الأوجه دون تحميل قاعدة البيانات. ويُضاف إلى ذلك طبقةُ التخزين المؤقت وتوزيعُ الصور عبر CDN. ولأن طبقة التطبيق بلا حالة، يجري التوسّع الأفقي بزيادة عدد النسخ عند ارتفاع الحركة؛ وتُضاف الموارد دون انقطاع في أيام الحملات.
نعم، التركيب on-premise مدعوم. ويُفضَّل هذا الخيار خصوصاً في السيناريوهات المؤسسية التي يجب أن تبقى فيها البيانات في موقع محدد. وفي هذه الحالة تقع مسؤولية الخادم والتوسّع على فريق تقنية المعلومات لديك، ويُخطَّط للتحديثات معاً. كما تمكن التصاميم الهجينة التي تبقى فيها البيانات الحساسة لديك والباقي في السحابة.
أنت. فقاعدة البيانات وتخزين الملفات تحت سيطرتك؛ في التركيب on-premise تكون في بنيتك التحتية بالكامل، وفي التركيب المُدار تُحفَظ باسمك وملكاً لك. وتصدير البيانات ممكن دائماً عبر API وأدوات التصدير الجماعي؛ فلا تبقى محبوساً في منصة.
لا. تُوصَل تكاملات الدفع والشحن والفوترة عبر واجهات مستقلة عن المزوّد؛ وينفّذ كل مزوّد العقد نفسه. وإضافةُ مزوّد جديد تعني كتابة تنفيذ يلبّي تلك الواجهة، وبقيةُ كود التطبيق لا تتغيّر. ويمكن أيضاً تعريف أكثر من مزوّد في آنٍ واحد والتوجيه بحسب المنطقة أو الشرط.
نعم. ولأن المنصة صُمّمت API-first فإن كل قدرة توجد أولاً كنقطة نهاية؛ والواجهة الجاهزة ليست إلا إحدى الطبقات التي تستهلك هذه API. ويمكنك كتابة واجهتك بأي تقنية تشاء واستخدام المنصة كطبقة بيانات ومنطق عمل. ولأن تطبيق الجوال يستهلك API نفسها، تبقى إدارة المحتوى في مكان واحد.
لا تُفسِدها إذا أُجريت التوسيعات دون تغيير الكود الأساسي. فالوحدات الإضافية وتطبيقات الأطراف الثالثة تُوصَل عبر طبقة API نفسها، وتُعرَّف قواعد العمل من محرّك سير العمل؛ وكلاهما لا يتأثر بتحديثات الإصدار. أما في السيناريوهات التي يجري فيها تغيير مباشر في النواة فتُدار خطة التحديث معاً على مستوى المشروع.
تُبنى صفحات الواجهة على الخادم؛ فيرى محرك البحث المحتوى دون تشغيل JavaScript. وتُنتَج بيانات منظّمة لصفحات المنتجات والتصنيفات والمحتوى، وتأتي إدارة canonical وبنية الروابط متعددة اللغات جاهزة. وهذا يبقي صفحات التصنيفات والمنتجات — التي تصبح المصدر الرئيسي للحركة العضوية كلما كبر الكتالوج — قابلةً للفهرسة.

لنقيّم معاً متطلباتك المعمارية

لنخطّط لاجتماع تقني حول الحجم المتوقع وقائمة التكاملات ونموذج تركيبك.

خيار on-premise · ملكية البيانات لك · دعم على مدار الساعة