كيف يعمل إعادة تحميل NGINX؟ ولماذا لا يتم إعادة تحميل NGINX تلقائيًا؟

لاحظت مؤخرًا منشورًا على Reddit يقول "لماذا لا يدعم NGINX إعادة التحميل الساخن؟". بشكل غريب، NGINX، أكبر خادم ويب في العالم، لا يدعم إعادة التحميل الساخن؟ هل هذا يعني أننا نستخدم nginx -s reload بشكل خاطئ؟ مع هذا السؤال، دعونا نتحقق من كيفية عمل إعادة تحميل NGINX.

ما هو NGINX

NGINX هو خادم ويب مفتوح المصدر يعمل على منصات متعددة تم تطويره بلغة C. وفقًا للإحصاءات، من بين أفضل 1000 موقع ويب من حيث حركة المرور، يستخدم أكثر من 40٪ منها NGINX للتعامل مع الطلبات الهائلة.

لماذا NGINX مشهور جدًا

ما هي المزايا التي يتمتع بها NGINX لتتفوق على خوادم الويب الأخرى وتحافظ دائمًا على معدل استخدام مرتفع؟

السبب الرئيسي هو أن NGINX مصمم للتعامل مع مشاكل التزامن العالي. لذلك، يمكن لـ NGINX تقديم خدمة مستقرة وفعالة أثناء التعامل مع عدد كبير من الطلبات المتزامنة. علاوة على ذلك، مقارنة بالمنافسين من نفس العمر، مثل Apache وTomcat، يتمتع NGINX بالعديد من التصميمات الاستثنائية مثل بنية الأحداث المتقدمة، وآلية غير متزامنة بالكامل للتعامل مع مدخلات ومخرجات الشبكة، ونظام إدارة ذاكرة فعال للغاية. هذه التصميمات الرائعة تساعد NGINX على استخدام موارد الأجهزة بالكامل وتجعل NGINX مرادفًا لخادم الويب.

بالإضافة إلى ما سبق، هناك أسباب أخرى مثل:

1. التصميم المعياري للغاية يجعل NGINX يمتلك عددًا كبيرًا من الوحدات الرسمية والوحدات الخارجية الغنية بالميزات.
2. ترخيص BSD الحر يجعل المطورين يرغبون في المساهمة في NGINX.
3. دعم إعادة التحميل الساخن يتيح لـ NGINX تقديم خدمات على مدار الساعة طوال أيام الأسبوع.

من بين هذه الأسباب، إعادة التحميل الساخن هو موضوعنا الرئيسي اليوم.

ما الذي يفعله إعادة التحميل الساخن

ما هو إعادة التحميل الساخن الذي نتوقعه؟ أولاً، أعتقد أن مستخدمي العميل لا ينبغي أن يلاحظوا إعادة تحميل الخادم. ثانيًا، يجب أن تحقق الخوادم أو الخدمات العلوية التحميل الديناميكي والتعامل مع جميع طلبات المستخدمين بنجاح دون توقف.

في أي ظروف نحتاج إلى إعادة التحميل الساخن؟ في عصر Cloud Native، أصبحت الخدمات المصغرة شائعة جدًا لدرجة أن المزيد من سيناريوهات التطبيق تتطلب تعديلات متكررة على جانب الخادم. هذه التعديلات، مثل تشغيل/إيقاف تشغيل الوكيل العكسي للنطاق، تغيير عنوان الخدمة العلوية، وتغيير قائمة السماح/الحظر للعنوان IP، مرتبطة بإعادة التحميل الساخن.

إذن كيف يحقق NGINX إعادة التحميل الساخن؟

مبدأ إعادة التحميل الساخن في NGINX

عندما ننفذ أمر إعادة التحميل الساخن nginx -s reload، فإنه يرسل إشارة HUP إلى عملية NGINX الرئيسية. عندما تتلقى العملية الرئيسية إشارة HUP، فإنها ستفتح منافذ الاستماع بالتسلسل وتبدأ عملية عامل جديدة. لذلك، ستوجد عمليتا عامل (قديمة وجديدة) في نفس الوقت. بعد دخول عملية العامل الجديدة، ستقوم العملية الرئيسية بإرسال إشارة QUIT إلى عملية العامل القديمة لإغلاقها بشكل لائق. عندما تتلقى عملية العامل القديمة إشارة QUIT، ستقوم أولاً بإغلاق معالج الاستماع. الآن، ستصل جميع الاتصالات الجديدة فقط إلى عملية العامل الجديدة، وسيتم إغلاق العملية القديمة بمجرد معالجة جميع الاتصالات المتبقية.

من الناحية النظرية، هل يمكن لإعادة التحميل الساخن في NGINX أن تلبي متطلباتنا بشكل مثالي؟ لسوء الحظ، الإجابة هي لا. إذن، ما هي العيوب التي تعاني منها إعادة التحميل الساخن في NGINX؟

إعادة تحميل NGINX تسبب توقفًا

1. إعادة التحميل الساخن المتكررة جدًا تجعل الاتصالات غير مستقرة وتفقد بيانات الأعمال.

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

2. في بعض الظروف، يستغرق وقت إعادة تدوير عملية العامل القديم وقتًا طويلاً لدرجة أنه يؤثر على الأعمال العادية.

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

   هنا مثال آخر، عندما يعمل NGINX كوكيل عكسي لـ TCP وUDP، لا يمكنه معرفة عدد المرات التي يتم فيها طلب الطلب قبل أن يتم إغلاقه أخيرًا.

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

# always exist in old worker process:
nobody 6246 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6247 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6247 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6248 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6249 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 7995 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down  <= here
nobody 7995 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down
nobody 7996 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down

باختصار، يمكننا تحقيق إعادة التحميل الساخن عن طريق تنفيذ nginx -s reload، وهو ما كان كافيًا في الماضي. ومع ذلك، فإن التطور السريع للخدمات المصغرة وCloud Native يجعل هذا الحل لم يعد يلبي متطلبات المستخدمين.

إذا كان تردد تحديث أعمالك أسبوعيًا أو يوميًا، فإن إعادة تحميل NGINX هذه لا تزال تلبي احتياجاتك. ولكن ماذا لو أصبح تردد التحديث كل ساعة أو كل دقيقة؟ على سبيل المثال، إذا كان لديك 100 خادم NGINX، ويتم إعادة تحميله مرة كل ساعة، فسيحتاج إلى إعادة التحميل 2400 مرة في اليوم؛ إذا كان الخادم يعيد التحميل كل دقيقة، فسيحتاج إلى إعادة التحميل 8,640,000 مرة في اليوم، وهو أمر غير مقبول.

نحتاج إلى حل دون تبديل العمليات، ويمكنه أيضًا تحقيق تحديثات المحتوى الفورية.

إعادة التحميل الساخن التي تأخذ تأثيرًا فوريًا في الذاكرة

عندما ولد Apache APISIX، تم تصميمه لحل مشكلة إعادة التحميل الساخن في NGINX. تم تطوير APISIX بناءً على تقنيات NGINX وLua، وهو بوابة API للخدمات المصغرة عالية الأداء وديناميكية بالكامل تعتمد على etcd كمركز تكوين أساسي. لا حاجة لإعادة تشغيل الخادم لإعادة تحميل تكوين الخادم الجديد، مما يعني أن أي تغييرات في الخدمات العلوية، المسارات، أو الإضافات لن تتطلب إعادة تشغيل الخادم. ولكن كيف يمكن لـ APISIX التخلص من قيود NGINX لتحقيق إعادة التحميل الساخن المثالية بناءً على حقيقة أن APISIX تم تطويره على تقنية NGINX؟

أولاً، دعونا نرى بنية برنامج Apache APISIX:

يمكن لـ APISIX تحقيق إعادة التحميل الساخن المثالية لأنه يضع جميع التكوينات في APISIX Core وPlugin Runtime بحيث يمكن استخدام التخصيصات الديناميكية. على سبيل المثال، عندما يحتاج NGINX إلى تكوين المعلمات داخل ملفات التكوين، فإن كل تعديل لن يتم تفعيله إلا بعد إعادة التحميل. لتكوين المسارات بشكل ديناميكي، يقوم Apache APISIX بتكوين خادم واحد محدد مع موقع واحد فقط. يجب علينا استخدام هذا الموقع كمدخل رئيسي بحيث تمر جميع الطلبات من خلاله أولاً، ثم يقوم APISIX Core بتخصيص الخدمات العلوية المحددة لها. يمكن لوحدة المسار في Apache APISIX دعم إضافة/إزالة، تعديل، وحذف المسارات أثناء تشغيل الخادم. بمعنى آخر، يمكنها تحقيق إعادة التحميل الديناميكي. لن تجلب أي من هذه التغييرات انتباه المستخدمين أو تؤثر على الأعمال العادية.

الآن، دعونا نقدم سيناريو كلاسيكي؛ على سبيل المثال، إذا أردنا إضافة وكيل عكسي لنطاق جديد، نحتاج فقط إلى إنشاء خدمة علوية في APISIX وإضافة مسار جديد. لا يحتاج NGINX إلى إعادة التشغيل خلال هذه العملية. هنا مثال آخر لنظام الإضافات: يمكن لـ APISIX استخدام إضافة تقييد IP لتحقيق ميزة قائمة السماح/الحظر للعنوان IP. جميع تحديثات هذه الميزة ديناميكية ولا تحتاج إلى إعادة تشغيل الخادم. بفضل etcd، يمكن أن تحقق استراتيجية التكوين تحديثات فورية باستخدام الإضافات، ويمكن أن تأخذ جميع التكوينات تأثيرًا فوريًا وتوفر أفضل تجربة مستخدم.

الخلاصة

إعادة التحميل الساخن في NGINX ستؤدي إلى وجود عملية عامل قديمة وواحدة جديدة في بعض الظروف، مما يسبب إهدارًا إضافيًا للموارد. أيضًا، إعادة التحميل الساخن المتكررة جدًا يمكن أن تسبب فرصة ضئيلة لفقدان بيانات الأعمال بالكامل. في ظل خلفية Cloud Native والخدمات المصغرة، أصبحت تحديثات الخدمات أكثر تواترًا، واستراتيجية إدارة API تختلف أيضًا، مما يؤدي إلى متطلبات جديدة لإعادة التحميل الساخن.

لم تعد إعادة التحميل الساخن في NGINX تلبي متطلبات الأعمال. حان الوقت للتحول إلى Apache APISIX، بوابة API ذات استراتيجية إعادة تحميل ساخن أكثر تقدمًا في عصر Cloud Native. بالإضافة إلى ذلك، بعد التحول إلى APISIX، يمكن للمستخدمين إدارة خدمات API بشكل ديناميكي وموحد، ويمكن أن يحسن بشكل كبير من كفاءة الإدارة.