كيف تهمس "أوبر" في أذن تطبيقك؟

1. مأساة الاستعلام الدوري (Polling): عهد الأسئلة المتكررة

• نزيف الطاقة (Battery Drain): يضطر الهاتف لتشغيل شريحة الاتصال باستمرار لإرسال الطلبات، مما يمنع المعالج من الدخول في وضع السكون ويؤدي لنفاذ البطارية سريعاً.
• هدر البيانات (Network Waste): يتم تبادل آلاف الرسائل التي غالباً ما تكون إجابتها "لا يوجد جديد". هذه الطلبات الفارغة تستهلك باقة إنترنت المستخدم وتزيد من زحام الشبكة بلا فائدة حقيقية.
• فجوة التأخير (Latency Gap): لا تقدم هذه الطريقة بيانات لحظية حقاً؛ فإذا حدث التغيير فور انتهاء السؤال، سيتعين على المستخدم الانتظار حتى موعد السؤال التالي (الذي قد يفصله ثوانٍ طويلة) ليشعر بالتحديث.
• إنهاك الخوادم (Server Strain): تخيل ملايين الهواتف وهي تطرق باب الخادم في نفس اللحظة؛ هذا الضغط الهائل يتطلب بنية تحتية جبارة ومكلفة فقط للرد على طلبات أغلبها لا يحمل أي معلومة جديدة.
• 2. ولادة RAMEN: الجهاز العصبي الذي لا ينام

  قررت أوبر إنهاء عهد "التساؤل" وبدء عهد "الإخبار" عبر منصة RAMEN (Real-time Asynchronous MEssaging Network).

  المبادئ الأربعة التي بنيت عليها RAMEN:

1. سلاسة الانتقال (Easier Migration): لم يكن من المنطقي إعادة كتابة مئات الخدمات من الصفر. لذا، صُممت RAMEN لتكون قادرة على استغلال "منطق العمل" (Business Logic) الموجود فعلياً في واجهات الاستعلام القديمة، مما سمح للمهندسين بنقل الخدمات إلى النظام الجديد دون الحاجة لإعادة اختراع العجلة.
2. بساطة التطوير (Ease of Development): يجب ألا تكون عملية إرسال البيانات "دفعاً" أصعب على المطور من بناء واجهة استعلام عادية. كان الهدف أن يتمكن أي مبرمج في أوبر من دمج ميزات اللحظة الحقيقية في تطبيقه بنفس السهولة والسرعة التي كان يعتمدها سابقاً، دون تعقيدات برمجية إضافية.
3. الموثوقية المطلقة (Reliability): في عالم النقل، ضياع رسالة قد يعني ضياع رحلة. لذلك، بُنيت RAMEN لتضمن وصول كل رسالة عبر الشبكة بأمان؛ حيث يتضمن النظام آليات ذكية لإعادة المحاولة (Retry Logic) في حال فشل التسليم نتيجة ضعف التغطية أو انقطاع الاتصال المفاجئ.
4. كفاءة نقل البيانات (Wire Efficiency): مع توسع أوبر في الدول النامية، أصبح توفير البيانات أمراً مصيرياً. السائقون يقضون ساعات طويلة متصلين بالمنصة، وأي هدر في البيانات يعني تكلفة إضافية عليهم. لذا، تم تحسين البروتوكول ليرسل أقل قدر ممكن من "البايتات" عبر الشبكة، مما جعل التطبيق يعمل بكفاءة حتى في أضعف ظروف الاتصال.

   3. دورة حياة الرسالة: من الفكرة إلى الشاشة

   لا تخرج الرسالة من أوبر عبثاً، بل تمر برحلة ذكية:

   أ- متى نرسل؟ (Fireball)

   خدمة Fireball هي "المخ" الذي يراقب أحداث النظام. بمجرد أن يقبل سائق رحلة، يطلق Fireball "زناد" الإرسال، جامعاً سياق جهازك (اللغة، الإصدار) لضمان وصول رسالة مخصصة لك تماماً.

   ب- ماذا نرسل؟ (API Gateway)

   هنا يتم "طبخ" المحتوى. الجميل هو أن أوبر تستخدم نفس المنطق البرمجي الذي جربته في واجهات الاستعلام القديمة، مما وفر وقتاً وجهداً هائلاً في الصيانة.

   ج- كيف نضمن الجودة؟ (Metadata)

   تحمل كل رسالة بطاقة تعريفية:

الأولوية:

الصلاحية (TTL):

4. بروتوكول التسليم: هندسة الاستمرارية

آلية الـ Sequence Numbers والـ Heartbeat:

• يبدأ التطبيق بطلب seq=0. يرسل الخادم الرسائل المعلقة بأرقام تسلسلية.
• إذا انقطع الاتصال عند الرسالة رقم 2، يعود التطبيق ليطلب الاتصال من seq=2.
• للتأكد من أن القناة "حية"، يرسل الخادم "نبضة" (Heartbeat) كل 4 ثوانٍ.

5. التوسع العالمي: Netty و Helix و Zookeeper (المحركات الجبارة)

أ- التخلي عن "الدردشة" (Gossip Protocol):

ب- الحل في الثلاثي الكبير:

1. Netty (السرعة القصوى): تم استبدال خوادم Node.js بـ Netty (مبني على Java). ميزته الكبرى هي Zero-copy؛ حيث ينقل البيانات من بطاقة الشبكة إلى الذاكرة مباشرة دون معالجتها من قبل المعالج (CPU)، مما قلل من استهلاك الموارد بشكل مذهل.
2. Apache Zookeeper (سجل الثقة): بدلاً من ترك الخوادم تدردش مع بعضها، استُخدم Zookeeper كمركز معلومات مركزي (Source of Truth). هو من يعرف أي مستخدم متصل بأي خادم في أي لحظة.
3. Apache Helix (منظم المرور): يعمل فوق Zookeeper وهو المسؤول عن "تقسيم الكعكة". إذا تعطل خادم ما، يقوم Helix في أجزاء من الثانية بنقل المستخدمين الذين كانوا عليه إلى خادم آخر وتوزيع "البارتيشنز" (Partitions) بذكاء.

ج- الهيكل الجديد (Streamgate):

• StreamgateFE (الواجهة): يعمل كوكيل عكسي (Reverse Proxy)؛ يعرف التضاريس التقنية ويوجه الطلب القادم من هاتفك إلى الخادم الصحيح الذي يحمل "الجلسة" الخاصة بك.
• Storage (Redis & Cassandra): لضمان عدم ضياع الرسائل عند التنقل بين مراكز البيانات (Multi-region)، تُخزن الرسائل في Cassandra (للمتانة عبر القارات) و Redis (كخزنة سريعة لمنع الضغط الهائل على قواعد البيانات عند إعادة التشغيل).

6. المستقبل: عهد gRPC ووداعاً للقيود (ثورة الاتصال)

أ- عيوب SSE التي قتلتها gRPC:

• التأكيد المتأخر (Delayed ACKs): في SSE، كان التطبيق يخبر الخادم "وصلتني الرسالة" كل 30 ثانية فقط لتوفير البيانات. هذا جعل الخادم يجهل حالة الرسالة الحقيقية لنصف دقيقة كاملة!
• النصوص مقابل الباينري: SSE بروتوكول نصي (Text-based). إذا أردت إرسال بيانات معقدة، عليك تحويلها إلى Base64، مما يزيد حجم الملف بنسبة 33%.
• أحادية الاتجاه: لا يمكن للتطبيق إرسال بيانات تقنية للخادم عبر نفس القناة.

ب- القفزة النوعية مع gRPC:

1. تأكيد فوري (Instant ACKs): بمجرد أن تصل الرسالة لهاتفك، يرسل التطبيق إشارة تأكيد "فورية" عبر المسار العكسي لنفس القناة. هذا جعل موثوقية وصول الرسائل تقترب من 100%.
   قياس نبض الشبكة (RTT): بفضل gRPC، أصبح الخادم يعرف "زمن الرحلة" (Round Trip Time) لكل مستخدم. إذا كان إنترنت المستخدم ضعيفاً، يقوم الخادم تلقائياً بتقليل حجم البيانات أو تأجيل الرسائل غير الهامة (Flow Control).
2. تعدد المسارات (Stream Multiplexing): يمكنك إرسال تحديث الموقع، والدردشة مع السائق، وتحديث السعر، كلها في نفس "الأنبوب" التقني دون أن تتعطل رسالة خلف الأخرى (تجنب مشكلة Head-of-line blocking).
3. تجريد البيانات (Abstraction): gRPC يدعم أنواعاً مختلفة من التشفير. اليوم تستخدم أوبر Protobuf، ولكن مستقبلاً يمكنها تغيير طريقة التشفير دون لمس البنية التحتية للنقل.

كلمة أخيرة: فلسفة النجاح