لماذا يعيش الكثير من الأمور في الحافة

طبقة الحافة تكسب قوتها

يحمل الوكيل العكسي ثلاثة مهام في الوقت نفسه. أيٌّ منها بمفرده يبرر وجود هذه الطبقة؛ لكن حمل جميعها الثلاثة على نفس العنوان يفسر لماذا تبدو معمارية الويب الإنتاجية (Production) تقريبًا بنفس الشكل في المقدمة.

المهمة 1: إخفاء المصدر (Origin). يرد الوكيل على عنوان IP عام. بينما تجلس الخوادم الخلفية على عناوين IP خاصة لا يمكن للإنترنت الوصول إليها. أي مهاجم يريد استهداف المصدر يجب أن يخترق الوكيل أولًا.

المهمة 2: إنهاء TLS. يحتفظ الوكيل (Proxy) بشهادة example.com ويشفّر طلبات HTTPS الواردة. تتحدث الخوادم الخلفية (Backends) عبر بروتوكول HTTP عادي (أو TLS داخلي أبسط) مع الوكيل عبر مقطع شبكة موثوق. يتم إدارة تدوير الشهادات وتجديدها وسياسة التشفير كلها في مكان واحد.

المهمة 3: توزيع الحمل. يختار الوكيل الخادم الخلفي الذي سيتعامل مع كل طلب. تشكل الخوادم الخلفية خلف وكيل واحد مجموعة (Pool)؛ يختار الوكيل واحداً منها لكل طلب باستخدام استراتيجية (دوريات، أقل عدد من الاتصالات، تجزئة بناءً على ترويسة). إضافة السعة تعني إضافة خادم خلفي إلى المجموعة، وليس إعلام كل عميل بعنوان جديد.

كل مهمة هي برنامج صغير. معاً، تفسر هذه المهام لماذا يحمل طبقة بسيطة مثل "Caddy أمام تطبيق Python" وزناً تصميمياً أكبر من تطبيق Python نفسه.

التصميم لجميع المهام الثلاث

تشغّل فريقك واجهة برمجة تطبيقات (API) صغيرة على عملية Python واحدة تستمع على المنفذ 8000 على جهاز افتراضي واحد. نما حجم الحركة بما يكفي بحيث لا يستطيع جهاز افتراضي واحد مواكبته، كما أشارت مراجعة أمنية إلى أن الجهاز الافتراضي يمتلك عنوان IP عاماً ويشغّل شهادة TLS الخاصة به.

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

استبدال مكوّن دون أن يلاحظ أحد

الوسيطية تمنح حرية

تقول مقولة قديمة في علوم الحاسوب: يمكن حل كل مشكلة بإضافة طبقة من عدم المباشرة (باستثناء مشكلة وجود طبقات كثيرة من عدم المباشرة). يُعدّ الوكيل العكسي (Reverse Proxy) من أكثر أدوات عدم المباشرة فائدةً في الأنظمة الموزعة.

ما الذي يمنحك إياه:

- خوادم خلفية قابلة للاستبدال. هل تنقل التطبيق من بايثون إلى Go؟ أو تهاجر من مركز بيانات إلى آخر؟ أو تُطلق إصدارًا جديدًا دون أي توقف في الخدمة؟ كل ذلك يحدث خلف عنوان عام ثابت. لا يتغير شيء للمستخدمين.

- توسع مستقل. تتوسع طبقة الوكيل بناءً على عرض النطاق الترددي ومعالج CPU على مستوى طبقة TLS. بينما تتوسع طبقة الخلفية بناءً على عمل التطبيق. ينمو كل منهما على محوره الخاص لأنهما يعملان على أجهزة مختلفة.

- احتواء الأعطال. لا يؤدي نشر خاطئ في الخلفية إلى إسقاط العنوان العام. يبقى الوكيل يعمل؛ تقوم بإصلاح الخلل أو التراجع عن الإصدار؛ ويعيد العالم الاتصال عندما تتعافى الخلفية.

- المواضيع الشاملة في مكان واحد. تحديد معدل الطلبات، الحظر الجغرافي، تسجيل طلبات HTTP، إعادة كتابة الترويسات، التخزين المؤقت، ضغط الاستجابات: كل ذلك موجود على الوكيل. يبقى كود الخلفية مركّزًا على التطبيق فقط.

بدون الوكيل يجب أن تعيش كل واحدة من هذه المشاكل داخل عملية التطبيق. مع الوكيل، تعيش هذه المشاكل في طبقة واحدة يديرها فريق واحد.

التكلفة: طبقة إضافية يجب تشغيلها. تقبل الفرق الناضجة هذه التكلفة لأن طبقة الوكيل نفسها تعمل دون حالة (Stateless) وتتوسع أفقيًا؛ فاستبدال وكيل واحد باثنين لا يتطلب أي تنسيق.

نشر أزرق/أخضر عبر الوسيط (Proxy)

تقوم فريقك بتشغيل الإصدار 1 من واجهة برمجة التطبيقات (API) على ثلاث خوادم افتراضية خلفية (مجموعة زرقاء) خلف وسيط عكسي (Reverse Proxy). تريد نشر الإصدار 2 مع إمكانية التراجع في أقل من ثلاثين ثانية إذا حدث خطأ ما.

تطلق ثلاثة خوادم افتراضية خلفية جديدة (مجموعة خضراء) تعمل بالإصدار 2، جنبًا إلى جنب مع المجموعة الزرقاء، لكنك لا تقود أي حركة مرور إليها بعد.

من المتصفح إلى الخادم الخلفي والعكس

تتبع طلب واحد من البداية إلى النهاية

تتبع طلب HTTPS GET واحدًا للموقع https://api.example.com/users/42 عبر وكيل عكسي (Reverse Proxy) يقع أمام مجموعة من الخوادم الخلفية.

القفزة 1: حل اسم النطاق (DNS). يسأل المتصفح محلل DNS عن api.example.com. يعيد المحلل عنوان IP العام للوكيل (على سبيل المثال، 203.0.113.10). يفتح المتصفح اتصال TCP إلى 203.0.113.10:443.

القفزة 2: مصافحة TLS. يقدم الوكيل شهادته (Certificate) الخاصة بـ api.example.com. يتحقق المتصفح من الشهادة، ويتفق الطرفان على مفتاح جلسة، وفتتح القناة المشفرة.

القفزة 3: طلب HTTP داخل TLS. يرسل المتصفح GET /users/42 HTTP/1.1\nHost: api.example.com\n.... يفك الوكيل تشفير بايتات الطلب.

القفزة 4: اختيار الخلفية. يستشير الوسيط (Proxy) مجموعة الخوادم العلوية (Upstream) الخاصة بـ api.example.com ويختار خادمًا خلفيًا واحدًا (مثل 10.0.0.21:8000) باستخدام استراتيجية توزيع الأحمال لديه.

القفزة 5: الطلب العلوي. يفتح الوسيط (أو يعيد استخدام) اتصال HTTP عادي مع 10.0.0.21:8000 ويحوّل الطلب. قد يعيد الوسيط كتابة الترويسات (Headers) أثناء العملية: إضافة X-Forwarded-For: <client-ip>، ضبط Host: بشكل صحيح، وإزالة الترويسات القافزة (hop-by-hop) مثل Connection.

القفزة 6: المعالجة الخلفية. تقرأ تطبيق الخلفية (Backend) الطلب، وتستعلم عن قاعدة البيانات، وتبني استجابة بصيغة JSON.

القفزة 7: الاستجابة العلوية. يرسل الخلفية الاستجابة مرة أخرى إلى الوسيط عبر HTTP عادي.

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

القفزة 9: دورة حياة الاتصال. عادةً ما تبقى جلسة TLS مفتوحة للطلب التالي (فبروتوكول HTTP/2 يدمج العديد من الطلبات على اتصال واحد). وغالبًا ما تُجمع اتصالات الوسيط مع الخلفية في مجمعات (Pools) لإعادة استخدامها.

تتبع كل خدمة ويب عامة بعض التغيرات من هذا الشكل. معرفة القفزات تتيح لك الاستدلال حول مكان تراكم الكمون (Latency)، وأين يجب أن تكون السجلات (Logging)، وأين يمكن أن تختبئ العطلات.

إلى أين ذهبت المدة الزمنية؟

يشكو مستخدم من أن واجهة برمجة التطبيقات (API) تبدو بطيئة. قمت بالقياس واكتشفت أن الطلب يستغرق 850 مللي ثانية من البداية إلى النهاية. تُظهر سجلات الخادم على الخلفية (Backend) أن التطبيق قدّم الطلب في 40 مللي ثانية. تُظهر سجلات الوسيط (Proxy) أن الوسيط قضى 50 مللي ثانية في جانب عمله (مصافحة TLS + التوجيه + كتابة الاستجابة).

صمّم حافةً (Edge) بسيطة لخدمة جديدة

التوليف

لقد تعلمت الفرق بين الوكيل الأمامي (Forward Proxy) والوكيل العكسي (Reverse Proxy)، والمهام الثلاث التي يتكفل بها الوكيل العكسي في آنٍ واحد، ولماذا يُعدّ إخفاء المصدر (Origin) استثماراً مجدياً كل مرة تحتاج فيها إلى إجراء تغيير، وكيفية تدفق الطلبات من قفزة إلى أخرى عبر الحافة.

الآن، طبّق ما تعلمته.

تخطط مجموعة صغيرة لإطلاق خدمة جديدة تُدعى notes.example.com. سيقوم المستخدمون بقراءة الملاحظات الشخصية وكتابتها. ستشغّل المجموعة خادمين افتراضيين (VMs) في الخلفية عند الإطلاق، وتتوقع التوسع إلى عشرة خوادم خلال العام المقبل. هم يريدون استخدام HTTPS للمستخدمين، والإطلاق التدريجي للإصدارات الجديدة، وعدم تعرض عناوين IP للخوادم الخلفية للعرض العام.

إلى أين تتجه هذه الدورة بعد ذلك

إلى أين تتجه هذه الدورة بعد ذلك

أرسى هذا الدرس الشكل لطبقة الحافة. أربع دروس أخرى في هذه الدورة تُبنى عليه:

- التوسع الأفقي غير الحافظ للحالة: لماذا تضاعف طبقة الوكيل (والمخدمات الخلفية خلفها) بتكلفة رخيصة، والمعادلات لحساب عدد النسخ تحت الذروة.

- فصل الدخول / الخروج: لماذا تفشل صناديق الوكيل الواحدة التي تتعامل مع كلا من الحركة الواردة والصادرة في النهاية بطرق مفاجئة، وكيفية فصل الطبقات.

- أوضاع الفشل ونطاق التأثير: كيف يمكن لتغيير واحد في الإعدادات أن يتسبب في انقطاع واسع النطاق، وكيف تكتب بنود إجراء خالية من اللوم تمنع تكرار المشكلة.

- قابلية المراقبة والسعة: ما الذي يجب قياسه على الحافة (Edge) حتى تكتشف أن شيئاً ما معطل قبل أن يلاحظه المستخدمون.

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

درس مرافق: يعيد geometry_of_proxies_and_origins صياغة كل ما في هذا الدرس كرسوم موجّهة (Directed Graph) ويستكشف ما تخبرك به نظرية الرسوم عن مسار الطلب.

أحسنت. إلى الأمام.