ركن المهندسين: تبديل Xactly إلى الكروم بدون رأس

هذه مشاركة مدونة ضيف من Xactly Software Engineer ، Anvesh Checka. ترقبوا المدونات المستقبلية من فريق هندسة Xactly!

وثيقة الخطة هي وثيقة قانونية بين الشركة وممثلي المبيعات ، تستخدم لتتبع التقدم. تعمل مستندات التخطيط في Xactly eDocs & Approvals على تبسيط العمليات وزيادة المرونة حيث تنتقل المستندات بسلاسة عبر قنوات مختلفة في مؤسستك.

عندما يطلب مندوب مبيعات مستند خطة ، يتم تنسيق المستند بواسطة PDF Generator Service باستخدام علامة HTML التي يتلقاها من خدمة المستعرض بدون رأس.

تحول Xactly مؤخرًا من PhantomJS إلى Chromeless Chrome لإنشاء محتوى لمستندات الخطة في مهام سير عمل Xactly DocuSign. ساعدنا المفتاح على الاستمرار في بناء نظام موثوق به مكاسب كبيرة في الأداء والاستقرار.

ستغطي هذه المقالة:

• ما الذي ألهم هذا التحول
• التحديات التي تمت مواجهتها خلال العملية
• كيف حقق فريق الهندسة Xactly هذا الهدف

قليلا من الخلفية

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

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

أصبح PhantomJS عنصرًا أساسيًا في سير العمل لدينا ، ومع ذلك ، لم يتم تطوير PhantomJS والمتصفحات الأخرى بدون رأس بنفس وتيرة الأنظمة البيئية الأمامية على مر السنين. باستخدام ES6 / 7/8 ، أضاف العاملون في الويب والخدمة وواجهات برمجة التطبيقات الأصلية والمتخصصة بالمتصفح و shadow DOM والميزات الأخرى مجموعة التحديات الخاصة بهم. الاستقرار هو أيضا مصدر قلق كبير.

عندما تم الإعلان عن نهاية عمر PhantomJS بالتزامن مع وصول Chromeless Chrome ، كان ذلك بمثابة نعمة مقنعة لفريق Xactly الهندسي. بدأنا تشغيل العديد من PoCs (إثبات المفاهيم) لتقييم ميزاتها ، ومراقبة استقرارها وأدائها ، والتحقق من توافقها مع مجموعة ميزات منتجاتنا.

لقد لاحظنا أن Chromeless Chrome سريع للغاية (مع وجود أجهزة كافية) ومستقر ، وعلى نفس القدر من الأهمية ، صديق للمطورين. كانت تلك الأسباب كافية لنا لقلب التبديل.

كيف سحبنا هذا؟

كجزء من مبادرة هندسة الموثوقية الخاصة بنا ، بدأنا التنفيذ الجديد في حوالي شهرين (بما في ذلك الاختبار الشامل).

في هذه العملية ، قمنا بتطوير قائمة مراجعة بأهم الأشياء التي يجب مراعاتها فيما يتعلق بالبنية التحتية. تشمل هذه الاعتبارات:

• المعدات
• توافق البرنامج مع نظام التشغيل
• اعداد الآلة
• إنشاء مهام سير العمل والبرامج النصية ونشرها
• كرونز
• اكتشاف الخدمة
• فحوصات طبية
• المراقبة الأمنية
• مراقبة الخادم
• وضع الحماية (عند الضرورة)

تم تحويل PhantomJS monolith الخاص بنا إلى خدمة مستقلة تعمل بنظام Chromeless Chrome ، مع العديد من مثيلات الخدمة التي تم توسيعها أفقيًا على العديد من الأجهزة متعددة النواة باستخدام HAProxy.

على كل جهاز ، يتم تحجيم تطبيق NodeJS عموديًا عن طريق تجميع مثيلات العقد وموازنة التحميل باستخدام PM2. استخدمنا أيضًا برنامج Puppeteer كعميل فعلي لواجهة برمجة التطبيقات للتحدث إلى Chromium. حاليًا ، نجمع جميع السجلات إلى ملف محلي على الجهاز ولكننا نخطط للانتقال إلى ELK (Elastic ، Logstash ، Kibana) في المستقبل.

مع كل طلب ، تصل خدمة العقدة إلى نقطة نهاية داخلية وتقوم بإنشاء HTML المطلوب للمعلمات المطلوبة. في وقت لاحق ، يتم تمرير هذا إلى خدمة إنشاء ملفات PDF التي تقوم بإنشاء مستندات PDF مخصصة.

ذاكرة التخزين المؤقت الباردة وجلسات البكر

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

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

حقائق سريعة

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

• يتراوح وقت إنشاء محتوى لمستند واحد بين 4 و 10 ثوانٍ ، اعتمادًا على حجم المستند.
• على الرغم من إنشاء مثيل متصفح جديد لكل طلب ، فإن الجهاز ثماني النواة قادر عادةً على إنشاء أكثر من 8000 مستند في أقل من ساعة. لم يكن هذا ممكنًا أبدًا باستخدام PhantomJS.
• أثناء اختبارات الحمل لدينا ، لاحظنا ما يلي:
  • يعد تشغيل ما يقرب من 35 مثيلاً للمتصفح النشط أمرًا مثاليًا. أي شيء أعلى من هذا الرقم بشكل كبير يقلل من الأداء بسبب حمل العملية. لإبقاء الأمور تحت السيطرة ، قمنا بتطبيق آليات قائمة الانتظار.
• بدون قائمة الانتظار ، واجهنا مشكلات متعلقة بالذاكرة والحد الأقصى للخيوط. في هذه الحالات ، لاحظنا ارتفاعًا في عدد عمليات Chrome الشبحية ، والتي كان لا بد من إزالتها باستخدام cronjob على فترات منتظمة.
• في حالة استغراق الطلب الوارد وقتًا طويلاً لإكماله أو إخفاقه بسبب خطأ داخلي ، فإننا نحاول إعادة المحاولة عدة مرات بناءً على إعداد تم تكوينه مسبقًا.
• لقد نقلنا إعدادات مثل مهلات واجهة برمجة التطبيقات وعمليات إعادة المحاولة والعتبة والمزيد إلى ملفات التكوين الخارجية.
• يتم دفع جميع بيانات تحليل المقاييس إلى نظام داخلي داخلي. في حال لم يكن لديك تطبيق داخلي ، يمكنك استخدام تطبيق Keymetrics.

ماذا بعد

يستمر نظامنا في التطور مع التحسينات المخطط لها والتحسينات الأخرى ، بما في ذلك ما يلي:

• تحليل السجل المنظم من خلال ELK
• تحسين المراقبة
• موثوقية وأداء محسنان

عن المؤلف

اسمي Anvesh Checka وأعمل كمهندس برمجيات مع فريق المنتج في Xactly. أحب بناء واجهات المستخدم وتطبيقات الويب بأنظمة مختلفة. إذا كان لديك أي أسئلة أو تعليقات ، فلا تتردد في التغريد أو إرسال رسالة إلي.