---
title: "معرفة NGINX المستخدم في OpenResty - API7.ai"
description: "يوفر Nginx نموذج Master-Worker ومراحل تنفيذ الطلبات. من خلال قراءة هذا المنشور، يمكنك فهم أساسيات Nginx بشكل أفضل."
url: "https://api7.ai/ar/learning-center/openresty/knowledge-of-nginx-used-in-openresty"
---

# معرفة NGINX المستخدم في OpenResty

API7.ai

September 17, 2022

[OpenResty (NGINX + Lua)](https://api7.ai/learning-center/openresty)

من خلال [المقال السابق](https://api7.ai/learning-center/openresty/how-to-manage-openresty-packages/)، لديك معرفة عامة عن OpenResty. في المقالات القليلة القادمة، سأأخذك عبر الركيزتين الأساسيتين لـ OpenResty: NGINX وLuaJIT، ويمكنك تعلم OpenResty بشكل أفضل من خلال إتقان هذه الأساسيات.

اليوم سأبدأ مع NGINX، وهنا سأقدم فقط بعض الأساسيات التي قد تُستخدم في OpenResty، وهي مجرد جزء صغير من NGINX.

بالنسبة للتكوين، في تطوير OpenResty، نحتاج إلى الانتباه إلى النقاط التالية.

- تقليل تكوين `nginx.conf` قدر الإمكان.
- تجنب استخدام مجموعة من الأوامر مثل `if`، `set`، `rewrite`، إلخ.
- عدم استخدام تكوين NGINX، المتغيرات، والوحدات عندما يمكن حلها باستخدام كود Lua.

هذه الطرق ستزيد من قابلية القراءة، الصيانة، والتوسع. التكوين التالي لـ NGINX هو مثال سيء لاستخدام التكوين ككود.

```
location ~ ^/mobile/(web/app.htm) {
    set $type $1;
    set $orig_args $args;
    if ( $http_user_Agent ~ "(iPhone|iPad|Android)" ) {
        rewrite  ^/mobile/(.*) http://touch.foo.com/mobile/$1 last;
    }
    proxy_pass http://foo.com/$type?$orig_args;
}
```

هذا ما نحتاج إلى تجنبه عند التطوير باستخدام OpenResty.

## تكوين NGINX

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

لنبدأ بالتكوين التالي، وهو بسيط جدًا.

```
worker_processes auto;

pid logs/nginx.pid;
error_log logs/error.log notice;

worker_rlimit_nofile 65535;

events {
    worker_connections 16384;
}

http {
    server {
        listen 80;
        listen 443 ssl;

        location / {
            proxy_pass https://foo.com;
        }
    }
}

stream {
    server {
        listen 53 udp;
    }
}
```

ومع ذلك، حتى هذه التكوينات البسيطة تتضمن بعض المفاهيم الأساسية.

أولاً، كل توجيه له **سياقه**، وهو نطاقه في ملف تكوين NGINX.

المستوى الأعلى هو `main`، والذي يحتوي على بعض التعليمات التي لا علاقة لها بالأعمال المحددة، مثل `worker_processes`، `pid`، و`error_log`، وكلها جزء من سياق `main`. بالإضافة إلى ذلك، هناك علاقة هرمية بين السياقات. على سبيل المثال، سياق `location` هو `server`، سياق `server` هو `http`، وسياق `http` هو `main`.

لا يمكن تشغيل التوجيهات في السياق الخاطئ. سيتحقق NGINX من شرعية `nginx.conf` عند بدء التشغيل. على سبيل المثال، إذا قمنا بتغيير `listen 80`; من سياق `server` إلى سياق `main` وبدأنا خدمة NGINX، سنرى خطأ مثل هذا:

```
"listen" directive is not allowed here ......
```

ثانيًا، يمكن لـ NGINX التعامل ليس فقط مع طلبات HTTP وحركة HTTPS ولكن أيضًا مع حركة UDP وTCP. الطبقة السابعة (L7) هي في HTTP والطبقة الرابعة (L4) هي في Stream. في OpenResty، `lua-nginx-module` و`stream-lua-nginx-module` يتوافقان مع هذين السياقين على التوالي.

شيء واحد يجب ملاحظته هنا هو أن OpenResty لا يدعم جميع الميزات في NGINX، وعليك النظر إلى إصدار OpenResty. إصدار OpenResty يتوافق مع NGINX، مما يسهل التعرف عليه.

التوجيهات التكوينية المشار إليها في `nginx.conf` أعلاه موجودة في الوحدات الأساسية لـ NGINX [ngx\_core\_module](https://nginx.org/en/docs/ngx_core_module.html,), [ngx\_http\_core\_module](https://nginx.org/en/docs/http/ngx_http_core_module.html), و[ngx\_stream\_core\_module](https://nginx.org/en/docs/stream/ngx_stream_core_module.html)، والتي يمكنك النقر عليها لرؤية الوثائق المحددة.

## نمط MASTER-WORKER

بعد فهم ملف التكوين، دعونا نلقي نظرة على نمط العمليات المتعددة لـ NGINX (كما هو موضح في الشكل أدناه). كما ترى، عند بدء NGINX، سيكون هناك عملية `Master` واحدة وعدة عمليات `Worker` (أو عملية Worker واحدة فقط، اعتمادًا على كيفية التكوين).

![نمط Worker في NGINX](https://static.api7.ai/2022/09/17/63257daada6b2.png?imageMogr2/format/webp)

أولاً، عملية `Master`، كما يوحي اسمها، تلعب دور "المدير" ولا تتعامل مع طلبات العملاء. إنها تدير عمليات `Worker`، بما في ذلك استقبال الإشارات من المسؤول ومراقبة حالة `Worker`s. عندما تخرج عملية `Worker` بشكل غير طبيعي، ستقوم عملية `Master` بإعادة تشغيل عملية `Worker` جديدة.

عمليات `Worker` هي "الموظفون العاملون الحقيقيون" الذين يتعاملون مع طلبات العملاء. يتم إنشاؤها من عملية `Master` وهي مستقلة عن بعضها البعض. هذا النموذج متعدد العمليات أكثر تقدمًا بكثير من النموذج متعدد الخيوط في Apache، حيث لا يوجد قفل عبر الخيوط وسهل التصحيح. حتى إذا تعطلت عملية وخرجت، فإنها عادة لا تؤثر على عمل العمليات الأخرى.

يضيف OpenResty وكيلًا مميزًا فريدًا إلى نموذج Master-Worker في NGINX. هذه العملية لا تستمع إلى أي منافذ ولديها نفس الصلاحيات مثل عملية `Master` في NGINX، لذا يمكنها القيام ببعض المهام التي تتطلب صلاحيات عالية، مثل بعض عمليات الكتابة على ملفات القرص المحلي.

إذا عملت العملية المميزة مع آلية الترقية الساخنة الثنائية لـ NGINX، يمكن لـ OpenResty تنفيذ الترقية الثنائية الكاملة على الفور دون الاعتماد على البرامج الخارجية.

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

## مراحل التنفيذ

مراحل التنفيذ هي أيضًا ميزة أساسية لـ NGINX وترتبط ارتباطًا وثيقًا بالتنفيذ المحدد لـ OpenResty. لدى NGINX 11 مرحلة تنفيذ، والتي يمكننا رؤيتها في الكود المصدري لـ `ngx_http_core_module.h`:

```
typedef enum {
    NGX_HTTP_POST_READ_PHASE = 0,

    NGX_HTTP_SERVER_REWRITE_PHASE,

    NGX_HTTP_FIND_CONFIG_PHASE,
    NGX_HTTP_REWRITE_PHASE,
    NGX_HTTP_POST_REWRITE_PHASE,

    NGX_HTTP_PREACCESS_PHASE,

    NGX_HTTP_ACCESS_PHASE,
    NGX_HTTP_POST_ACCESS_PHASE,

    NGX_HTTP_PRECONTENT_PHASE,

    NGX_HTTP_CONTENT_PHASE,

    NGX_HTTP_LOG_PHASE
} ngx_http_phases;
```

إذا كنت تريد معرفة المزيد عن دور هذه المراحل الـ 11، يمكنك قراءة وثائق NGINX حتى لا أتطرق إليها هنا.

بالصدفة، لدى OpenResty أيضًا 11 توجيهًا `*_by_lua` مرتبطًا بمرحلة NGINX، كما هو موضح في الشكل أدناه (من وثائق `lua-nginx-module`).

![ترتيب توجيهات وحدة Lua NGINX](https://static.api7.ai/2022/09/17/63257f1a69d8f.png?imageMogr2/format/webp)

`init_by_lua` يتم تنفيذه فقط عند إنشاء عملية `Master`، و`init_worker_by_lua` يتم تنفيذه فقط عند إنشاء كل عملية `Worker`. التوجيهات الأخرى `*_by_lua` يتم تشغيلها بواسطة طلبات العملاء ويتم تنفيذها بشكل متكرر.

لذلك خلال مرحلة `init_by_lua`، يمكننا تحميل وحدات Lua والبيانات العامة للقراءة فقط مسبقًا للاستفادة من ميزة COW (نسخ عند الكتابة) في نظام التشغيل لتوفير الذاكرة.

معظم العمليات يمكن القيام بها داخل `content_by_lua`، لكنني أوصي بتقسيمها وفقًا للوظائف المختلفة، مثل التالي.

- `set_by_lua`: تعيين المتغيرات.
- `rewrite_by_lua`: إعادة التوجيه، التحويل، إلخ.
- `access_by_lua`: الوصول، الأذونات، إلخ.
- `content_by_lua`: إنشاء المحتوى المراد إرجاعه.
- `header_filter_by_lua`: معالجة تصفية رأس الاستجابة.
- `body_filter_by_lua`: معالجة تصفية جسم الاستجابة.
- `log_by_lua`: تسجيل الأحداث.

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

```
location /mixed {
    content_by_lua '...';
}
```

بالطبع لا. باستخدام ميزة المراحل، يمكننا فك التشفير في مرحلة `access` والتشفير في مرحلة `body filter` دون إجراء أي تغييرات على الكود في مرحلة `content` الأصلية.

```
location /mixed {
    access_by_lua '...';
    content_by_lua '...';
    body_filter_by_lua '...';
}
```

## ترقية NGINX الثنائية على الفور

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

يتم الترقية الساخنة عن طريق إرسال إشارات `USR2` و`WINCH` إلى عملية `Master` القديمة. بالنسبة لهاتين الخطوتين، تبدأ الأولى عملية `Master` الجديدة؛ بينما تغلق الثانية عملية `Worker` تدريجيًا.

بعد هاتين الخطوتين، يتم بدء عملية `Master` الجديدة وعملية `Worker` الجديدة. في هذه المرحلة، لا تخرج عملية `Master` القديمة. السبب في عدم الخروج بسيط: إذا كنت بحاجة إلى التراجع، يمكنك إرسال إشارة `HUP` إلى عملية `Master` القديمة. بالطبع، إذا كنت قد قررت أنك لا تحتاج إلى التراجع، يمكنك إرسال إشارة `KILL` إلى عملية `Master` القديمة للخروج.

هذا كل شيء، وتمت ترقية NGINX الثنائية على الفور.

إذا كنت تريد معرفة المزيد من المعلومات التفصيلية حول هذا، يمكنك التحقق من الوثائق الرسمية لمواصلة التعلم.

## الخلاصة

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

أخيرًا، تركت لك سؤالًا مفتوحًا: يدعم Nginx رسميًا NJS، مما يعني أنه يمكنك كتابة JS للتحكم في بعض منطق NGINX، مشابه لـ OpenResty. ما رأيك في هذا؟ مرحبًا بمشاركة هذه المقالة.

Share article link

Share

Related Posts

[![أسئلة وأجوبة حول OpenResty | كيفية استخدام OpenResty في الممارسة العملية](https://static.api7.ai/uploads/2023/02/12/jbv9M0zi_Hello%20World%20in%20OpenResty%20%283%29.png)](https://api7.ai/learning-center/openresty/faq-5)

## [أسئلة وأجوبة حول OpenResty | كيفية استخدام OpenResty في الممارسة العملية](https://api7.ai/learning-center/openresty/faq-5)

[![الجزء الثالث: كيفية بناء بوابة API للخدمات المصغرة باستخدام OpenResty](https://static.api7.ai/uploads/2023/02/07/3XJXY9Jy_45.png)](https://api7.ai/learning-center/openresty/how-to-build-a-microservices-api-gateway-part-3)

## [الجزء الثالث: كيفية بناء بوابة API للخدمات المصغرة باستخدام OpenResty](https://api7.ai/learning-center/openresty/how-to-build-a-microservices-api-gateway-part-3)

Table of Contents

- [تكوين NGINX](#%D8%AA%D9%83%D9%88%D9%8A%D9%86-nginx)
- [نمط MASTER-WORKER](#%D9%86%D9%85%D8%B7-master-worker)
- [مراحل التنفيذ](#%D9%85%D8%B1%D8%A7%D8%AD%D9%84-%D8%A7%D9%84%D8%AA%D9%86%D9%81%D9%8A%D8%B0)
- [ترقية NGINX الثنائية على الفور](#%D8%AA%D8%B1%D9%82%D9%8A%D8%A9-nginx-%D8%A7%D9%84%D8%AB%D9%86%D8%A7%D8%A6%D9%8A%D8%A9-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D9%81%D9%88%D8%B1)
- [الخلاصة](#%D8%A7%D9%84%D8%AE%D9%84%D8%A7%D8%B5%D8%A9)