REST API أو SMPP: من أي حجم شهري للتبديل إلى المغرب

ومع ذلك، عندما ينمو العمل التجاري، يزداد الحجم. تنتقل من بضعة آلاف من الإشعارات إلى عدة ملايين شهريًا. أثناء "الجمعة السوداء" أو إرسال اتصال وطني، تبدأ REST API في إظهار نقاط الضعف الهيكلية (زمن وصول الشبكة، التحميل الزائد على وحدة المعالجة المركزية، تجاوز حدود الطلب).

لقد حان الوقت للاهتمام ببروتوكول الاتصالات الصناعية: SMPP (Short message Peer-to-Peer). ولكن متى بالضبط يجب إجراء هذا التحول الذي يستغرق وقتًا طويلاً؟ هنا هي نقطة التحول.

تعتمد واجهة برمجة تطبيقات HTTP (REST) ​​على نموذج "الطلب/الاستجابة".
لإرسال رسالة نصية قصيرة واحدة، عليك فتح اتصال TCP (الذي يستغرق ميلي ثانية)، وإجراء مصافحة SSL (مصافحة تشفير كثيفة)، وإرسال رؤوس HTTP، والحمولة، وانتظر الاستجابة من البوابة.

حتى باستخدام اتصالات HTTP المستمرة (Keep-Alive)، تكون هذه العملية "ثقيلة".

• الحد الفني: غالبًا ما يتم تقييده بواسطة موفري خدمة الرسائل القصيرة بين 10 و50 طلبًا في الثانية (RPS) للحماية من الهجمات.
• السقف الزجاجي: بخلاف هذه الأرقام، ستواجه أخطاء أو مهلات 429 طلبات كثيرة جدًا، مما سيجبرك على إنشاء طوابير انتظار معقدة (Throttling).

(ملاحظة: تتغلب واجهة برمجة التطبيقات المجمعة على هذه المشكلة عن طريق إرسال 1000 رقم في طلب HTTP واحد، ولكنها لا تحل زمن الاستجابة إذا كنت ترسل الآلاف من كلمات المرور لمرة واحدة (OTP) المنفصلة في الثانية).

يحتفظ SMPP باتصال ثنائي مستمر (نفق TCP/IP) مفتوح على مدار الساعة طوال أيام الأسبوع بين الخادم الخاص بك وجدار الحماية الخاص بموفر خدمة الرسائل القصيرة. لم يعد هناك أي حمل مرتبط برؤوس SSL أو HTTP.

مزايا SMPP:

1. غير متزامن تمامًا: يمكنك إرسال 500 رسالة نصية قصيرة مرة واحدة دون انتظار الرد من البوابة. سوف تجيبك "لاحقًا" في نفس الأنبوب.
2. إنتاجية هائلة: بسهولة من 100 إلى أكثر من 1000 رسالة نصية قصيرة في الثانية (TPS).
3. تقارير التسليم الأصلية: لم تعد هناك حاجة لإدارة خطافات ويب HTTP المعقدة. تنتقل رسالة تأكيد شبكة اتصالات المغرب (IAM) مباشرةً إلى نفقك المفتوح.

العيب الرئيسي:
يستغرق تطوير عميل SMPP قوي أسابيع، مقارنة بساعات REST API. يجب عليك إدارة سلاسل الرسائل وقطع اتصال TCP الصامتة (الاستعلام عن الرابط) والتشفير منخفض المستوى (نظام ترميز البيانات) للأحرف العربية بالنظام الست عشري.

إليكم قاعدة صناعة الاتصالات الملائمة للسوق المغربي:

• أقل من 500000 رسالة نصية قصيرة شهريًا: ابق على REST API. ستغطي واجهة برمجة التطبيقات (API) احتياجاتك إلى حد كبير. استخدم قوائم انتظار Redis لتسهيل التحميل. لن يتم إطفاء تكلفة تطوير SMPP أبدًا.
• من 500000 إلى 1 مليون رسالة نصية قصيرة شهريًا (المنطقة الرمادية): لا تزال واجهة REST API قادرة على التعامل مع هذا الحمل إذا كنت تستخدم "نقاط النهاية المجمعة" للتسويق وحجز مكالمات الوحدة الصارمة لـ OTPs.
• أكثر من مليون رسالة قصيرة شهريًا (نقطة التحول): وهنا يأتي دور SMPP. عند هذا الحجم، ستصل الذروة في الساعة إلى مستويات يؤدي فيها زمن استجابة HTTP إلى إبطاء قواعد البيانات الخاصة بك. هذه هي البنية الأساسية للبنوك، ومشغلي الاتصالات أنفسهم، وعمالقة التجارة الإلكترونية (جوميا، مرجان).

إذا وصلت إلى نقطة التحول هذه، فلا تقطع REST API بين عشية وضحاها. يتم الترحيل في ثلاث مراحل "Shadow IT":

1. تنفيذ RX (جهاز الاستقبال): أولاً، قم بتكوين عميل SMPP الخاص بك فقط على "الاستماع" (وضع جهاز الاستقبال). اطلب من مزود الخدمة الخاص بك توجيه DLRs إلى هذا الاتصال الجديد بدلاً من خطافات الويب HTTP القديمة.
2. تنفيذ الإرسال الجزئي (المرسل): نقل 5% من حملاتك التسويقية عبر SMPP (دون التأثير في حالة تعطلها)، مع الاحتفاظ بواجهة برمجة تطبيقات REST لعمليات إرسال OTP الحيوية.
3. التحويل الكامل (TRX): بمجرد إثبات استقرار عميل TCP على مدار عدة أيام (الإدارة الصحيحة لعمليات إعادة الاتصال بالشبكة)، قم بالتبديل على جميع مسارات المعاملات والتسويق. ستصبح واجهة REST API القديمة خطتك الاحتياطية في حالة تعطل البنية التحتية ذات المستوى المنخفض.