كيف تبني نظام تتبع شحنات لحظي؟ المعمارية والتقنيات خطوة بخطوة

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

كيف يعمل نظام التتبع؟

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

الخطوة الأولى: جمع بيانات الموقع

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

الخطوة الثانية: استقبال البيانات

الخطأ الشائع أن يقوم الخادم بكل العمل لحظة وصول الموقع: الحفظ، والحسابات، والتنبيهات، والإرسال للعملاء. الأفضل أن تكون نقطة الاستقبال خفيفة جدًا، تتحقق من صحة البيانات ثم تضعها في طابور (Queue) مثل Redis أو RabbitMQ. بعد ذلك تتولى عمليات خلفية (Workers) المعالجة بهدوء. هكذا يبقى النظام سريعًا حتى في أوقات الذروة.

الخطوة الثالثة: التخزين

حجم البيانات يكبر بسرعة لا يتوقعها كثيرون. 100 شاحنة ترسل موقعها كل 15 ثانية تنتج 576 ألف نقطة يوميًا. لذلك يُفضل الفصل بين شيئين. الموقع الحالي لكل مركبة يُحفظ في مخزن سريع مثل Redis لعرضه فورًا. وسجل المسارات الكامل يُحفظ في قاعدة البيانات مع تقسيم الجداول حسب التاريخ (Partitioning). وإذا احتجت استعلامات جغرافية، مثل معرفة المركبات القريبة من نقطة معينة، فإضافة مثل PostGIS لقاعدة PostgreSQL توفر عليك الكثير.

الخطوة الرابعة: البث اللحظي

لعرض الحركة على الخريطة دون أن تعيد الصفحة الطلب كل بضع ثوانٍ، نستخدم WebSockets التي تبقي اتصالًا مفتوحًا بين الخادم والمتصفح. هذا الجزء تحديدًا هو المكان الذي يتألق فيه Node.js مع مكتبة مثل Socket.IO، كما شرحت في مقالي السابق عن المقارنة بين Laravel وNode.js. ويمكن أيضًا استخدام Laravel Reverb إذا كان النظام كله مبنيًا على Laravel. والمهم ألا تبث كل نقطة لكل المستخدمين، بل قسّم البث إلى قنوات: قناة لكل شركة، وقناة لكل شحنة يتابعها عميل.

أخطاء شائعة يجب تجنبها

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

الخلاصة

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