استضافة منصات النقل والتوصيل: ما الذي تحتاجه من اليوم الأول

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

لذلك فإن السؤال عن الاستضافة هنا لا يبدأ من عدد الزوار، بل من عدد السائقين النشطين وعدد الرحلات المتزامنة. في هذا المقال نوضّح بأمثلة افتراضية ما تحتاجه منصة ناشئة من اليوم الأول، وما يمكن تأجيله، وكيف تتجنب إعادة البناء بعد أول موجة طلبات.

ما الذي يميّز حمل منصات النقل؟

أربعة أنواع من العمل تجري معاً، ولكل منها احتياج مختلف:

احسب من السائقين لا من الزوار

المعادلة الأساسية بسيطة، ويمكنك تطبيقها على أرقام مشروعك:

تحديثات الموقع في الثانية = عدد السائقين النشطين ÷ فترة الإرسال بالثواني

مثال افتراضي: لنفترض 500 سائق نشط يرسل كل منهم موقعه كل 10 ثوانٍ. الناتج 50 تحديثاً في الثانية بشكل مستمر. يبدو الرقم صغيراً، لكن لو كتبت كل تحديث صفاً في قاعدة البيانات الرئيسية، فأنت تضيف ملايين الصفوف يومياً إلى جدول يكبر بلا توقف، وتبطئ معه كل استعلام يخص الرحلات.

الحل المعتاد فصل الموقع الحالي عن سجل المواقع:

• الموقع الحالي: يُحفظ في Redis، ويُستبدل مع كل تحديث.
• سجل المسار: يُجمع ويُكتب دفعات إلى قاعدة البيانات، أو يُكتفى بنقاط متباعدة لكل رحلة.
• البحث عن أقرب سائق: يجري على الموقع الحالي بفهرس جغرافي، لا على جدول السجل الكامل.

وللاتصالات المفتوحة معادلة أخرى: كل زبون يتابع رحلته اتصال يبقى مفتوحاً ويحجز ذاكرة، ولذلك قِس ما يستهلكه الاتصال الواحد في تطبيقك واضربه في عدد الرحلات المتزامنة المتوقعة في الذروة، لا في عدد المستخدمين المسجلين.

ماذا تحتاج من اليوم الأول، وماذا تؤجّل؟

التعقيد المبكر يقتل المشاريع الناشئة كما يقتلها البطء. لا تحتاج في البداية إلى عشرة سيرفرات، لكنك تحتاج إلى فصل منطقي يسمح بالتوسع لاحقاً.

من اليوم الأول:

• سيرفر بمعالج حديث وقرص NVMe يشغّل الـAPI وRedis وقاعدة البيانات، بتشغيل منفصل لكل خدمة في حاويات.
• نسخ احتياطي يومي لقاعدة البيانات خارج السيرفر نفسه، مع تجربة استعادة فعلية.
• مراقبة بسيطة لاستهلاك المعالج والذاكرة وزمن استجابة الـAPI.
• مفاتيح خرائط وإشعارات مخزّنة في متغيرات بيئة، ومقيّدة من لوحة كل مزوّد.

عند النمو:

• نقل قاعدة البيانات إلى سيرفر مستقل. راجع سيرفرات قواعد البيانات عندما تبدأ بمزاحمة بقية الخدمات.
• فصل خدمة الاتصالات المفتوحة ليسهل توسيعها وحدها.
• نسخة قراءة لقواعد التقارير، حتى لا تبطئ لوحة الإدارة حركة الطلبات.

الموثوقية: صمّم للشبكة المتقطعة

هاتف السائق يتنقل بين الأبراج، وتغطيته تضعف وتعود. لو افترض التطبيق شبكة مثالية لظهرت رحلات مكررة وحالات عالقة. ثلاث قواعد تحميك:

1. طلبات آمنة التكرار: أعطِ كل عملية مهمة معرّفاً فريداً، فإن أعاد التطبيق إرسالها بعد انقطاع لا تُنفَّذ مرتين.
2. تخزين محلي مؤقت: يحتفظ تطبيق السائق بالتحديثات أثناء الانقطاع ويرسلها عند العودة.
3. إعادة الاتصال بتدرّج: بعد أي عطل، لا تجعل كل التطبيقات تعيد الاتصال في الثانية نفسها، بل أضف تأخيراً متزايداً وعشوائياً.

ومن المفيد أيضاً أن تُعرَّف حالات الرحلة تعريفاً صارماً: طلب، وقبول، ووصول، وبدء، وانتهاء، وإلغاء. اجعل السيرفر هو المرجع الوحيد لهذه الحالات، وارفض أي انتقال غير منطقي مثل إنهاء رحلة لم تبدأ. عندها إن عاد تطبيق السائق من انقطاع طويل برسائل قديمة، لن تفسد حالة الرحلة، ولن يدخل موظف الدعم في جدال حول ما جرى فعلاً، لأن السجل واضح ومرتب زمنياً.

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

لمن تناسب هذه الخدمة؟

• شركات توصيل الطعام والطرود التي تبني تطبيقها الخاص.
• منصات نقل الركاب أو حجز الحافلات والمركبات.
• الشركات التي تدير أسطول مركبات داخلياً وتتابعه بنظام خاص.
• مطوّرو التطبيقات الذين ينفّذون هذه الأنظمة لعملائهم.

في مرحلة التجربة المحدودة قد يكفي VPS بقرص NVMe. وعند تشغيل منصة فعلية بخدمات متعددة، اطّلع على سيرفرات تطبيقات SaaS.

أخطاء شائعة

• كتابة كل نقطة موقع في الجدول الرئيسي: يكبر الجدول بسرعة ويبطئ كل شيء.
• الحساب على المستخدمين المسجلين: الحمل يأتي من النشطين في الذروة، لا من إجمالي الحسابات.
• مفاتيح الخرائط داخل التطبيق بلا قيود: قد تُستخرج وتُستهلك على حسابك.
• لوحة الإدارة على قاعدة الطلبات مباشرة: تقرير ثقيل واحد قد يبطئ الطلبات الحية.
• نسخ احتياطي لم يُجرَّب: النسخة التي لم تُستعد قط هي افتراض لا ضمان.

أسئلة شائعة

هل أحتاج Kubernetes من البداية؟

في الغالب لا. الحاويات على سيرفر واحد أو اثنين تكفي لمرحلة طويلة، وتبقي الانتقال لاحقاً ممكناً. أضف التعقيد حين تفرضه أرقامك.

كم مرة يرسل السائق موقعه؟

هو توازن بين دقة التتبع واستهلاك البطارية والبيانات والسيرفر. اجعل الفترة قابلة للضبط من السيرفر، وأطول حين يكون السائق بلا رحلة.

أين أخزّن صور الإيصالات والوثائق؟

خارج قاعدة البيانات، في تخزين ملفات منفصل، مع حفظ المسار فقط في القاعدة. هذا يبقي النسخ الاحتياطي للقاعدة صغيراً وسريعاً.

الخطوة التالية

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