لقد ساعدنا بناء بوابة واجهة برمجة التطبيقات (API) الخاصة بنا في توفير 38% من تكاليف الاستدعاءات إلى الجهات الخارجية، لكننا واجهنا مشاكل في التكيف بين المناطق المختلفة.
في الأسبوع الماضي ، قام فريق أدوات التجارة الإلكترونية في جنوب شرق آسيا بإعادة النظر في فاتورة التكلفة التقنية لـ Q1 ، وكاد الزملاء المسؤولون عن واجهة الدفع يقفزون: بعد استبدال بوابة الطرف الثالث المستخدمة سابقًا بالدراسة الذاتية ، انخفضت تكلفة استدعاء واجهة برمجة التطبيقات مباشرة بنسبة 38٪ في الشهر الواحد ، ولكن في اختبار التسجيل الرمادي قبل الترويج ، انخفض معدل نجاح الدفع للمستخدمين في عقدة سنغافورة فجأة بنسبة 6 في المائة ، واستغرق نصف يوم للتحقق لم يجد أن قواعد الانفصال عبر المناطق للبوابة لم تتكيف.
أولاً، دعونا نفهم ما هو البوابة (gateway) المبنية ذاتيًا (self-built gateway):
ببساطة ، يمكنك كتابة مجموعة من برامج مدخل حركة المرور الخاصة بك ، وتحمل جميع طلبات API الخارجية ، واستئناف طلبات الطرف الثالث ، ومكالمات الخدمات عبر هذه الطبقة ، لتحل محل خدمة بوابة الطرف الثالث التي تم شراؤها سابقًا.يتم تشغيل الإصدار الذي نستخدمه حاليًا على 4 خوادم عقد خارجية من 4G ذات النواة الثانية ، ويمكن للوحدة أن تحمل 1200 طلب في الثانية ، مما يغطي تمامًا متطلباتنا المتزامنة للدفع والسلع البالغة 1.8 مليون مرة يوميًا.
الفوائد الثلاثة الحقيقية التي يمكنك الحصول عليها
- أولاً، يمكننا بالفعل تخفيض التكاليف بشكل كبير. كنا نستخدم بوابات خارجية في السابق وكانت تفرض رسوماً بناءً على عدد المكالمات، مما كان يكلفنا 2100 دولار شهرياً، أما الآن فإن تكلفة الخادم الذي بنيناه بأنفسنا بالإضافة إلى تكاليف المراقبة أقل من 1300 دولار شهرياً، ولا نواجه أيضاً قيوداً تتعلق بزيادات التكاليف التدريجية.
- النقطة التالية هي أن القواعد تُحدد بالكامل من قبلنا أنفسنا. في السابق، كانت ضوابط التدفق من البوابات الخارجية موحدة، وخلال فترات التخفيضات الكبيرة كنا نحتاج إلى زيادة حصص ضوابط التدفق لواجهات الدفع بشكل مؤقت، وكان يتطلب ذلك إعداد طلبات عمل تستغرق ثلاثة أيام عمل لكل مرة. الآن، يمكننا تغيير الإعدادات في الخلفية في غضون 10 ثوانٍ فقط وتطبيق التغييرات على الفور.
- في النهاية، لا حاجة لاستخدام أطراف ثالثة لمعالجة البيانات. نحن نطور أدوات للتجارة الإلكترونية ونحتاج إلى التعامل مع استجابات الدفع من العديد من المستخدمين، وفي السابق كانت جميع الطلبات تمر عبر خدمات الأطراف الثالثة، لكن الآن جميع البيانات الحساسة تتم معالجتها على خوادمنا الخاصة، مما قلل تكاليف الامتثال بشكل كبير.
لا تتعجل في البدء بالبناء، دعونا أولاً نلقي نظرة على الأخطاء التي واجهناها سابقًا.
وتتمثل الثغرة الأولى في مسألة التكيف الشبكي عبر المناطق.في البداية وضعنا عقدة البوابة الرئيسية في سنغافورة، وفي وقت لاحق عندما فتح موقع ماليزيا مباشرة قطع حركة المرور، ونتيجة لذلك طلب المستخدمين المحليين أولا حول سنغافورة ثم العودة، تأخير الشبكة الضوئية أكثر من 200ms، والكثير من المستخدمين لا يمكن الانتظار لإغلاق صفحة الدفع، واستغرقنا أسبوعا لإكمال عقدة الحافة الماليزية.
المشكلة الثانية هي وجود ثغرات في قواعد الأمان. في السابق، كانت بوابات الطرف الثالث تحتوي بشكل افتراضي على ميزات للحماية من الهجمات الDDoS واعتراض الطلبات الخبيثة، ولكننا نسينا إضافة هذه الميزات عند إنشاء النظام الخاص بنا. وفي اليوم الثالث من تشغيله، تعرضنا لـ 200,000 طلب غير صالح من قبل الروبوتات، مما كاد يتسبب في تعطل واجهة إدارة المخزون.
المشكلة الثالثة هي أن تكاليف الصيانة والتشغيل أعلى مما كان متوقعًا. في السابق، عندما كان هناك مشكلة في البوابة الخارجية، كنا نتواصل مباشرة مع خدمة العملاء، ولكن الآن علينا نحن الثلاثة المطورين الخلفيين أن نتناوب على العمل ليلاً لمراقبة أنظمة المراقبة. في الشهر الماضي، استغرقت مهام تحديد أسباب أعطال البوابة وحدها 15% من وقت عمل الجميع.
أي نوع من الفرق يناسب العمل معًا، وأي نوع لا يجب إضاعة الوقت معه؟
إذا كان متوسط عدد طلبات واجهة برمجة التطبيقات (API) اليومية في فريقك يتجاوز مليون طلب، أو كنت بحاجة إلى معالجة كميات كبيرة من البيانات الحساسة، أو إذا سئمت من قيود السرعة وإجراءات التذاكر الخاصة بالبوابات الخارجية، فإن بناء بوابة خاصة بك يستحق بالتأكيد الاستثمار.
لكن إذا كان فريقك يتكون من اثنين أو أقل من المطورين المسؤولين عن الجزء الخلفي من التطبيق (الباك엔د)، أو كانت العملية التجارية لا تزال في مرحلة التجربة والخطأ السريع، وكانت قواعد الواجهات تتغير كل أسبوع، فلا داعي حقًا لقضاء الوقت على هذا الأمر. يمكنك استخدام بوابات خارجية (ثردبايرز) مؤقتًا لتلبية الاحتياجات، وعندما تستقر الأعمال، يمكنك استبدالها لاحقًا.
ثلاث نصائح عملية للأشخاص الذين يقومون بذلك لأول مرة
- نبدأ أولاً بتطبيق التغييرات على سيناريو واحد فقط، ولا نقوم بتغيير جميع الواجهات دفعة واحدة. في البداية، قمنا فقط بتحويل حركة المرور الخاصة بواجهات الدفع إلى البوابة الخاصة بنا، وعملت بشكل جيد لمدة أسبوعين قبل أن نبدأ تدريجياً في نقل واجهات أخرى. حتى لو حدثت مشكلة، فإنها ستؤثر فقط على سيناريو الدفع ولن تتسبب في توقف الخدمة في الموقع بأكمله.
- يجب بالتأكيد إجراء اختبارات الضغط عبر المناطق المختلفة. خاصةً بالنسبة للأعمال التي تعمل في الخارج، لا تقم فقط باختبار النظام محليًا قبل الإطلاق، بل قم بتشغيل اختبارات الضغط لمدة 24 ساعة على العقد الخاصة بالأسواق المستهدفة للتحقق من عدم وجود مشاكل في التأخير أو معدلات فقدان البيانات.
- لا توفر على لوحة المراقبة؛ يجب أن تراقب على الأقل ثلاثة مؤشرات أساسية وهي عدد الطلبات، معدل النجاح، والتأخير، وضبط عتبات التنبيه بشكل صحيح. لا تنتظر حتى يشتكي المستخدمون لتكتشف أن البوابة لم تعد تعمل.
المشاكل الصغيرة الشائعة
س: هل من الضروري استخدام لغة Go أو Rust للكتابة؟
لا داعي، لقد تم كتابة النسخة الأولى من المنتج باستخدام Node.js، وهي قادرة على التعامل مع الأحمال العالية بشكل جيد. يمكنك استخدام أي لغة تتقنها في فريقك، ويمكنك تغيير الأداة لاحقًا إذا ظهرت مشاكل في الأداء.
س: ما هو الأفضل مقارنةً ببوابات مزودي الخدمات السحابية؟
بوابات مزودي الخدمات السحابية أكثر مرونة من تلك الخاصة بالأطراف الثالثة، لكنها لا تزال لا توفر نفس درجة الحرية التي توفرها البنية التحتية المبنية يدويًا. إذا كنت لا تريد أن تكون مقيدًا بمزود خدمة سحابي معين، فإن بناء البنية التحتية الخاصة بك قد يكون الخيار الأكثر فائدة.
هل كان هذا مفيدًا؟