البوابة والوكيل العكسي (Gateway & Reverse Proxy)

🎯 السؤال الأساسي

في بنية الإنترنت عالية التزامن، كيف يمكن توجيه حركة المرور بأمان وكفاءة إلى الخدمة الصحيحة؟ الوكيل العكسي يحل مشكلة "كيفية توزيع حركة المرور"، وبوابة API تحل مشكلة "كيفية معالجة الطلبات". تقدم هذه المقالة فهمًا عميقًا لفلسفة تصميم البوابة وممارساتها الهندسية من خلال أمثلة واقعية (استقبال المكتب الأمامي، نظام الأمن، التوجيه الذكي).

1. لماذا نحتاج إلى "بوابة"؟

1.1 حالة واقعية: تطور معمارية متجر إلكتروني

واجه متجر إلكتروني مشاكل معمارية خطيرة أثناء نمو أعماله السريع:

استعراض السيناريو:

المرحلة الأولى: تعريض الخدمات مباشرة
العميل → استدعاء مباشر لخدمة المستخدم، خدمة الطلبات، خدمة الدفع...
         ↓
المشكلة 1: انكشاف عنوان IP للخدمات، مما يشكل خطرًا أمنيًا
المشكلة 2: لا يمكن توحيد المصادقة وتحديد المعدل
المشكلة 3: إضافة خدمة جديدة تتطلب تعديل إعدادات العميل

⚠️ المشاكل القاتلة للتعريض المباشر

ثغرات أمنية: انكشاف جميع عناوين IP للخدمات، مما يسهل الهجوم عليها
تكرار الوظائف: كل خدمة تحتاج إلى تنفيذ المصادقة وتحديد المعدل والسجلات
صعوبة التوسع: إضافة خدمة جديدة تتطلب تعديل جميع العملاء
فوضى البروتوكولات: بعضها يستخدم HTTP والبعض الآخر gRPC، مما يجبر العميل على التكيف

البنية المحسّنة (بإدخال البوابة):

العميل → بوابة API (Nginx/Kong) → الخدمات الداخلية
         ↓
      توحيد المصادقة، تحديد المعدل، التوجيه
         ↓
      العميل يعرف فقط عنوان البوابة

✨ النتائج بعد التحسين

الأمان: إخفاء عناوين IP الحقيقية للخدمات، فقط البوابة مرئية للخارج
تركيز الوظائف: المصادقة وتحديد المعدل والسجلات تُعالج بشكل موحد في البوابة
سهولة التوسع: إضافة خدمة جديدة تتطلب فقط تكوين التوجيه في البوابة
توحيد البروتوكولات: HTTP للخارج، ويمكن استخدام gRPC داخليًا

1.2 تشبيه حياتي للبوابة

موظف الاستقبال

تخيل أنك تزور شركة كبيرة:

بدون استقبال: الزوار يبحثون عن الأقسام مباشرة، لا يعرفون أين يذهبون، والشركة في حالة فوضى
مع استقبال: الزوار يذهبون أولاً إلى الاستقبال، يسألهم عن غرض الزيارة، ثم يوجههم إلى القسم المناسب

بوابة API هي "موظف الاستقبال" للنظام:

الوكيل العكسي: موظف الاستقبال، يوجه الزوار إلى القسم الصحيح
بوابة API: موظف استقبال ذكي، يمكنه أيضًا التحقق من هوية الزائر (المصادقة)، وتحديد عدد الزوار (تحديد المعدل)

👤

用户 (浏览器)

→

访问域名

🛡️

反向代理 (Nginx)

代理服务器

→

负载均衡

⚙️

后端服务器集群

Web1 | Web2 | Web3

🛡️ 反向代理特点

客户端无感知，只需要访问域名
隐藏真实服务器架构，统一对外接口
提供负载均衡、安全防护、SSL卸载等功能
典型代表：Nginx、HAProxy、AWS ELB

💡 典型使用场景

网站需要承载高并发流量（负载均衡）
统一HTTPS证书管理（SSL卸载）
防护DDoS攻击和SQL注入
灰度发布、A/B测试、蓝绿部署

🧠 记忆口诀

"反向代理 = 代理服务器" —— 客户端不知道真实服务器，只知道域名

2. ما هو الوكيل العكسي؟

2.1 الوكيل الأمامي مقابل الوكيل العكسي

🤔 شرح المصطلحات

الوكيل الأمامي (Forward Proxy):

يُنشر على جانب العميل
يعمل نيابة عن العميل للوصول إلى الموارد الخارجية
التطبيقات النموذجية: VPN، أدوات تجاوز الحظر
مثال: شبكة الشركة، حيث تصل إلى الإنترنت الخارجي من خلال وكيل

الوكيل العكسي (Reverse Proxy):

يُنشر على جانب الخادم
يستقبل طلبات العميل ويعيد توجيهها إلى الخدمات الداخلية
العميل يعرف فقط وجود الوكيل، ولا يعرف الخادم الحقيقي
أمثلة: Nginx، HAProxy

جدول المقارنة:

البعد	الوكيل الأمامي	الوكيل العكسي
موقع النشر	جانب العميل	جانب الخادم
خدمة لـ	العميل	الخادم
تطبيق نموذجي	VPN، تجاوز الحظر	موازنة الحمل، البوابة
الشفافية	الخادم يرى IP الوكيل	العميل يرى IP الوكيل
الغرض	إخفاء العميل الحقيقي، تسريع الوصول	إخفاء الخادم الحقيقي، موازنة الحمل

2.2 القيمة الأساسية للوكيل العكسي

القيمة الأولى: موازنة الحمل

توزيع حركة المرور على خوادم خلفية متعددة لتجنب التحميل الزائد على نقطة واحدة.

العميل
  ↓
Nginx (وكيل عكسي)
  ↓
┌─────────┬─────────┬─────────┐
│ خادم 1  │ خادم 2  │ خادم 3  │
└─────────┴─────────┴─────────┘

القيمة الثانية: الحماية الأمنية

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

العميل → يرى فقط عنوان IP الخاص بـ Nginx
الخادم الحقيقي → موجود فقط في الشبكة الداخلية، لا يمكن الوصول إليه من الخارج

القيمة الثالثة: إنهاء SSL

معالجة تشفير وفك تشفير HTTPS في طبقة الوكيل، واستخدام HTTP للخدمات الخلفية، مما يقلل من العبء الحسابي على الخلفية.

عميل HTTPS → Nginx (تشفير/فك تشفير) → خدمة خلفية HTTP
                   ↑
              نقطة إنهاء SSL

3. Nginx: لماذا يستطيع تحمل ملايين الطلبات المتزامنة؟

3.1 نموذج العمليات Master-Worker

يستخدم Nginx معمارية متعددة العمليات بدلاً من متعددة الخيوط:

عملية Master (المدير):

مسؤولة عن قراءة والتحقق من ملفات التكوين
إدارة عمليات Worker (بدء، إيقاف، إعادة تحميل)
لا تتعامل مع الطلبات المحددة

عمليات Worker (المنفذون):

تتعامل فعليًا مع طلبات HTTP
كل Worker هي عملية مستقلة ومعزولة عن بعضها البعض
العدد يُضبط عادةً على عدد أنوية CPU، لتجنب عبء تبديل السياق

💡 المزايا

عزل جيد: انهيار Worker واحدة لا يؤثر على Workers الأخرى
استفادة كاملة من تعدد الأنوية: كل Worker تعمل بشكل مستقل
تجنب تعقيد تعدد الخيوط: لا حاجة للتعامل مع مشاكل الأقفال والتسابق

3.2 النموذج المدفوع بالأحداث + غير المتزامن وغير المحظور

هذا هو السر الأساسي لأداء Nginx العالي:

Apache التقليدي (نموذج متعدد العمليات/الخيوط):

اتصال واحد = عملية/خيط واحد
عدد الاتصالات المتزامنة محدود بعدد عمليات/خيوط النظام
عند وجود اتصالات كثيرة، يكون عبء تبديل العمليات كبيرًا جدًا

Nginx (النموذج المدفوع بالأحداث):

يستخدم آليات I/O multiplexing عالية الكفاءة مثل epoll (Linux) / kqueue (macOS)
عملية Worker واحدة يمكنها التعامل مع عشرات الآلاف من الاتصالات في نفس الوقت
عندما لا يكون هناك بيانات على الاتصال، لا يشغل CPU، وعند وجود بيانات جديدة يتم التنبيه عبر إشعار الحدث

تشبيه حياتي

Apache: مثل مطعم فيه نادل مخصص لكل زبون (عملية)، وعند زيادة الزبائن تحتاج إلى عدد كبير من النادلين
Nginx: مثل نادل خارق يخدم جميع الزبائن في نفس الوقت، يذهب إلى من يحتاج الخدمة، بدلاً من الوقوف بجانب زبون واحد طوال الوقت

Nginx 进程架构图

👑

Master 进程

管理所有 Worker，负责配置加载、平滑升级

4 个 Worker

⚙️

Worker 1

处理 0 请求

⚙️

Worker 2

处理 0 请求

⚙️

Worker 3

处理 0 请求

⚙️

Worker 4

处理 0 请求

📡 epoll (Linux) / kqueue (macOS)

事件驱动：一个 Worker 同时处理数万个连接

传统 Apache

一个连接 = 一个进程/线程

❌ C10K 问题

Nginx

事件驱动 + 异步非阻塞

✅ 百万并发

🎮 模拟请求处理

💡 生产环境建议

Worker 数量 = CPU 核心数（通常设置为 auto，让 Nginx 自动检测）
太多了上下文切换开销大，太少了无法利用多核性能。

4. ما هي بوابة API؟

4.1 لماذا نحتاج إلى بوابة API؟

تخيل نظامًا بدون بوابة:

العميل يحتاج إلى معرفة عناوين خدمات متعددة (خدمة المستخدم، خدمة الطلبات، خدمة الدفع...)
كل خدمة يجب أن تنفذ المصادقة وتحديد المعدل والسجلات بنفسها
البروتوكولات غير موحدة، بعضها HTTP والبعض gRPC
عند ترقية الخدمات، يحتاج العميل أيضًا إلى التغيير

⚠️ مشاكل عدم وجود بوابة

تعقيد العميل: يحتاج إلى تكوين عناوين خدمات متعددة
تكرار الوظائف: كل خدمة تحتاج إلى تنفيذ المصادقة وتحديد المعدل
فوضى البروتوكولات: العميل يحتاج إلى التكيف مع بروتوكولات متعددة
صعوبة الترقية: ترقية الخدمات تتطلب تغيير العميل أيضًا

بعد وجود بوابة API:

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

客户端 (来访者)

📱 App

💻 Web

🔧 第三方

⬇️ 统一入口

🚪 API 网关 (前台)

🔐身份认证

⚡限流熔断

🧭路由转发

🔄协议转换

⬇️ 分发请求

⚙️ 后端服务 (各个部门)

👤

用户服务

/api/users

📦

订单服务

/api/orders

💳

支付服务

/api/pay

🔐身份认证

统一校验用户身份，无需每个后端服务都写登录逻辑。支持 JWT、OAuth2、API Key 等多种认证方式。

💡 实际场景

用户请求携带 JWT Token，网关校验签名和过期时间，通过后把用户ID添加到请求头转发给后端服务。

🤔 没有网关 vs 有网关的区别

功能需求	没有网关 (直接访问)	有 API 网关
身份认证	每个服务都要写一遍登录校验	✅ 统一在网关层校验 JWT
限流保护	每个服务自己实现限流	✅ 网关统一限流，保护后端
协议转换	HTTP、gRPC、WebSocket各自处理	✅ 网关统一对外暴露 HTTP
灰度发布	需要改负载均衡器配置	✅ 网关层按 Header 路由

4.2 الوظائف الأساسية لبوابة API

الوظيفة	الشرح	السيناريو النموذجي
توجيه الطلبات	إعادة توجيه الطلبات إلى خدمات مختلفة بناءً على URL وHeader وغيرها	`/api/users` → خدمة المستخدم، `/api/orders` → خدمة الطلبات
موازنة الحمل	توزيع حركة المرور عند وجود عدة نسخ لنفس الخدمة	خدمة المستخدم لديها 3 نسخ، توزيع الطلبات بالتناوب
المصادقة والتفويض	التحقق الموحد من JWT وOAuth Token	المستخدم غير المسجل لا يمكنه الوصول إلى `/api/admin`
تحديد المعدل والانصهار	التحكم في الحد الأقصى لحركة المرور، ومنع انهيار الخدمة	حد أقصى 1000 طلب في الثانية، وتجاوزه يُرجع 429
تحويل البروتوكولات	HTTP للخارج، ويمكن التحويل إلى gRPC داخليًا	العميل يستخدم HTTP، والبوابة تحول إلى gRPC لاستدعاء الخدمات الداخلية
النشر التدريجي	توجيه جزء من حركة المرور إلى الإصدار الجديد بناءً على Header أو النسبة	5% من المستخدمين يجربون الإصدار الجديد، و95% يستخدمون القديم
السجلات والمراقبة	تسجيل موحد لسجلات الطلبات، لتسهيل التحليل واستكشاف الأخطاء	تسجيل زمن الاستجابة ورمز الحالة وحجم الاستجابة لكل طلب

5. البوابة عمليًا: كيفية بناء معمارية بوابة كاملة؟

5.1 مخطط المعمارية الكاملة

┌───────────────────────────────────────────────────────────────────────┐
│                           العميل (متصفح/تطبيق)                           │
└───────────────────────────┬─────────────────────────────────────────┘
                                │ HTTPS
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                        الطبقة الخارجية: CDN + WAF                        │
│  ┌─────────────────────────────────────────────────────────────┐  │
│  │  CDN (شبكة توصيل المحتوى)                                   │  │
│  │  - تخزين مؤقت للموارد الثابتة (صور، CSS، JS)                 │  │
│  │  - وصول قريب جغرافيًا، تقليل زمن الانتقال                     │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  WAF (جدار حماية تطبيقات الويب)                               │  │
│  │  - الحماية من حقن SQL وهجمات XSS                              │  │
│  │  - حظر الروبوتات الخبيثة والزواحف                              │  │
│  │  - الحماية من هجمات CC                                         │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                    الطبقة الوسطى: بوابة API (Nginx/Kong)                 │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  الطبقة الأولى: إنهاء SSL + الحماية الأمنية                    │  │
│  │  - HTTPS / TLS 1.3                                              │  │
│  │  - HSTS، رؤوس الأمان                                            │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  الطبقة الثانية: المصادقة والتفويض                              │  │
│  │  - التحقق من JWT Token                                          │  │
│  │  - تكامل OAuth 2.0 / SSO                                        │  │
│  │  - إدارة API Key                                                 │  │
│  │  - التحقق من الصلاحيات (RBAC)                                     │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  الطبقة الثالثة: التحكم في حركة المرور                          │  │
│  │  - تحديد المعدل - خوارزمية دلو الرموز/الدلو المتسرب             │  │
│  │  - الانصهار - منع انتشار الأعطال                                 │  │
│  │  - التخفيض - خطة بديلة عند عدم توفر الخدمة                       │  │
│  │  - النشر التدريجي - توزيع حركة المرور حسب النسبة                 │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  الطبقة الرابعة: التوجيه وموازنة الحمل                           │  │
│  │  - توجيه المسار (Path-based Routing)                              │  │
│  │  - توجيه النطاق (Host-based Routing)                              │  │
│  │  - توجيه Header (Header-based Routing)                            │  │
│  │  - خوارزميات موازنة الحمل - التناوب/الموزون/الأقل اتصالات/تجزئة IP │  │
│  │  - تكامل اكتشاف الخدمة (Service Discovery)                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  الطبقة الخامسة: تحويل البروتوكولات ومعالجة البيانات             │  │
│  │  - إنهاء SSL (HTTPS ↔ HTTP)                                      │  │
│  │  - تحويل البروتوكولات (HTTP ↔ gRPC / WebSocket)                  │  │
│  │  - تحويل الطلب/الاستجابة (JSON ↔ XML)                            │  │
│  │  - ضغط البيانات (Gzip / Brotli)                                   │  │
│  │  - التخزين المؤقت (Cache) - الموارد الثابتة واستجابات API         │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                    الطبقة الداخلية: مجموعة الخدمات المصغرة                │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐      │
│  │  خدمة المستخدم │ │  خدمة الطلبات │ │  خدمة المنتجات │ │  خدمة الدفع   │      │
│  │  User Svc   │ │  Order Svc  │ │ Product Svc │ │ Payment Svc │      │
│  │             │ │             │ │             │ │             │      │
│  └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘      │
│         │                │                │                │               │
│         └────────────────┴────────────────┴────────────────┘               │
│                                       │                              │
│                    مركز اكتشاف الخدمة والتكوين (etcd)                    │
│                    - تسجيل واكتشاف الخدمات                                │
│                    - الفحص الصحي                                            │
│                    - تخزين تكوين KV                                         │
└───────────────────────────────────────────────────────────────────────┘

5.2 التوجيه وموازنة الحمل

إحدى المسؤوليات الأساسية للبوابة هي إيصال الطلب إلى المكان الصحيح. وهذا يتضمن قدرتين أساسيتين: التوجيه (إلى أي خادم) وموازنة الحمل (كيفية توزيع حركة المرور).

قواعد التوجيه: من URL إلى الخدمة

تخيل نظام تجارة إلكترونية، حيث تختلف عناوين URL باختلاف الخدمات:

/api/users/* → خدمة المستخدم
/api/orders/* → خدمة الطلبات
/api/products/* → خدمة المنتجات
/api/pay/* → خدمة الدفع

مثال على تكوين Nginx:

nginx

server {
    listen 80;
    server_name api.example.com;

    # خدمة المستخدم
    location /api/users/ {
        proxy_pass http://user-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # خدمة الطلبات
    location /api/orders/ {
        proxy_pass http://order-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # خدمة المنتجات
    location /api/products/ {
        proxy_pass http://product-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # خدمة الدفع (تحتاج مستوى أمان أعلى)
    location /api/pay/ {
        # تقييد الوصول بعناوين IP
        allow 10.0.0.0/8;
        deny all;

        proxy_pass http://payment-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

موازنة الحمل: مقارنة بين أربع استراتيجيات

عندما يكون لنفس الخدمة عدة نسخ، كيف نختار؟

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

مثال على تكوين Nginx:

nginx

# التناوب الموزون
upstream backend_weighted {
    server 10.0.1.10:8080 weight=3;  # أداء جيد، يتحمل المزيد من الحركة
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080 weight=1;  # أداء أقل، يتحمل حركة أقل
}

# الأقل اتصالات
upstream backend_least_conn {
    least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# تجزئة IP (استمرارية الجلسة)
upstream backend_ip_hash {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

选择负载均衡策略

🎮 负载均衡模拟器

💡

轮询 - 挨个分发，雨露均沾

按照服务器列表的顺序，依次将请求分配给每台服务器。就像银行叫号，1号窗口完事了到2号，2号完事了到3号，轮着来。

🏢 后端服务器集群

服务器数量:4 台

🖥️

Server-A

39%

请求数:0

权重:2

最近请求:

🖥️

Server-B

33%

请求数:0

权重:1

最近请求:

🖥️

Server-C

30%

请求数:0

权重:5

最近请求:

🖥️

Server-D

45%

请求数:0

权重:3

最近请求:

📨 请求队列

总请求: 0待处理: 0

📊 负载分布统计

37%

平均负载

45%

最高负载

5.8

负载标准差

Server-D

最忙服务器

6. أمان البوابة: كيفية حماية بوابة النظام؟

6.1 المصادقة والتفويض

الطريقة التقليدية (كل خدمة تقوم بالمصادقة بنفسها):

خدمة المستخدم، خدمة الطلبات، خدمة الدفع... كل منها تحتاج إلى التحقق من JWT
تكرار في الكود، صعوبة في الصيانة
توزيع secret على الخدمات المختلفة، مما يزيد من خطر التسريب

المصادقة الموحدة عبر البوابة:

العميل يحمل Token ويصل إلى البوابة
البوابة تتحقق من صحة Token (التوقيع، وقت الانتهاء)
بعد التحقق الناجح، تضاف معلومات المستخدم (مثل user_id) إلى رأس الطلب ويعاد توجيهه إلى الخدمة الخلفية
الخدمات الخلفية لا تحتاج إلى التحقق، تحصل على معلومات المستخدم مباشرة من Header

💡 الفكرة الأساسية

المصادقة في البوابة، والتفويض في الخدمة:

المصادقة: من أنت؟ (التحقق من Token، الحصول على هوية المستخدم)
التفويض: ماذا يمكنك أن تفعل؟ (تحديد الصلاحيات بناءً على دور المستخدم)

مثل استقبال الشركة: الاستقبال يتحقق من هويتك (بطاقة الهوية)، لكن الصلاحيات المحددة تحددها كل إدارة.

JWT (JSON Web Token) 认证流程

用户

输入用户名密码，点击登录

↓

网关/Nginx

转发登录请求到认证服务

↓

认证服务

验证密码，生成 JWT Token（包含 Header、Payload、Signature）

↓

用户/客户端

保存 Token（LocalStorage 或 Cookie）

↓

后续请求

在 HTTP Header 中携带: Authorization: Bearer <Token>

↓

网关/Nginx

校验 Token 签名和过期时间，通过后转发请求

↓

后端服务

从 Token 中解析用户信息，处理业务逻辑

🔑 JWT Token 结构（Base64编码）

PAYLOAD

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

SIGNATURE

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HMACSHA256(base64Url(header) + "." + base64Url(payload), secret)

🛠️ 三种方案实现对比

对比维度	Session + Cookie	JWT	OAuth2.0
存储位置	服务端存储 Session，客户端存 Cookie	客户端存储 Token，服务端无状态	授权服务器存储，客户端存 Access Token
扩展性	❌ 需要共享 Session，扩展复杂	✅ 无状态，易于水平扩展	✅ 分布式架构，支持大规模系统
安全性	⚠️ Cookie 可能被窃取，需要 CSRF 防护	⚠️ Token 泄露风险，需 HTTPS + 短期有效	✅ 行业最佳实践，支持多种安全机制
实现复杂度	🟢 简单，开箱即用	🟡 中等，需要 Token 管理	🔴 复杂，需要授权服务器
适用场景	传统 Web 应用、后台管理系统	SPA、移动端 API、微服务	第三方登录、开放平台、SSO

🔒 网关层认证最佳实践

统一在网关层验证

不要在每个微服务里重复写认证逻辑，统一在网关层校验 JWT 或 Session

HTTPS 强制

网关层强制 HTTPS，防止 Token 在传输过程中被窃取（中间人攻击）

Token 过期策略

Access Token 短期有效（15分钟），配合 Refresh Token 实现无感知续期

黑名单机制

用户登出或 Token 泄露时，将 Token 加入黑名单（Redis 存储）

6.2 HTTPS وإنهاء SSL

لماذا نحتاج إلى HTTPS؟

الأمان: منع سرقة البيانات أثناء النقل
الامتثال: المتصفحات الحديثة تعرض تحذير "غير آمن" لمواقع HTTP
SEO: محركات البحث تفضل مواقع HTTPS

حل إنهاء SSL:

تكوين HTTPS والشهادة فقط في طبقة البوابة
البوابة مسؤولة عن مصافحة TLS والتشفير/فك التشفير
استخدام HTTP بنص واضح بين البوابة والخدمات الخلفية (الشبكة الداخلية موثوقة)
الخدمات الخلفية تركز على منطق الأعمال، ولا تحتاج للتعامل مع TLS

💡 مزايا إنهاء SSL

تبسيط الإدارة: الشهادة تُكوّن فقط في البوابة، الخلفية لا تحتاج إلى تكوين
تقليل العبء: الخدمات الخلفية لا تحتاج إلى معالجة مصافحة TLS
تحديث موحد: تحديث الشهادة يتم فقط في البوابة

🔐 HTTPS 流量解密流程

👤

客户端 (浏览器)

发起 HTTPS 请求

🔒TLS 加密连接

证书: *.example.com

算法: TLS 1.3

加密: AES-256-GCM

🚪

Nginx (SSL 终结)

📜 校验证书

🔓 解密流量

📝 添加 X-Forwarded-*

🔓HTTP 明文

X-Forwarded-For: 203.0.113.42

X-Forwarded-Proto: https

X-Real-IP: 203.0.113.42

⚙️

后端服务集群

专注于业务逻辑，无需处理 TLS

📜 SSL 证书管理

生成私钥

使用 OpenSSL 生成 RSA 私钥，这是证书的基础

openssl genrsa -out private.key 2048

创建 CSR

生成证书签名请求，包含域名和组织信息

openssl req -new -key private.key -out csr.pem

域名验证

CA 机构验证域名所有权（DNS 记录或 HTTP 文件）

# 添加 DNS TXT 记录或上传验证文件到 /.well-known/

签发证书

验证通过后，CA 签发证书文件

# 下载 certificate.crt 和 chain.crt

部署配置

将证书配置到 Nginx 并测试

nginx -t && systemctl reload nginx

✨ SSL 终结的核心优势

🚀

性能提升

TLS 握手和加密解密是 CPU 密集型操作，集中在 Nginx 处理，后端服务专注业务逻辑，整体吞吐量提升 2-5 倍

🔧

简化运维

证书统一管理，只需在 Nginx 配置一次，无需在每个后端服务重复配置，证书续期、更换一键完成

🛡️

集中安全

SSL/TLS 配置统一管控，强制使用最新协议版本和密码套件，统一添加安全响应头（HSTS、CSP 等）

📊

统一监控

所有 HTTPS 流量经过 Nginx，可以统一记录访问日志、分析 SSL 握手性能、监控证书有效期，便于审计和排障

7. تحديد المعدل والانصهار: كيفية منع النظام من الانهيار بسبب "طوفان حركة المرور"؟

7.1 مقارنة خوارزميات تحديد المعدل

الخوارزمية	الفكرة الأساسية	حركة المرور المفاجئة	السيناريو المناسب	تعقيد التنفيذ
دلو الرموز	الدلو يحتوي على رموز، لا مرور بدون رموز	يسمح بدرجة معينة من الاندفاع	تحديد معدل API، التحكم في النطاق الترددي	متوسط
الدلو المتسرب	الطلبات تدخل الدلو، وتُعالج بتدفق منتظم	يفرض التسوية، الاندفاع يُخزن مؤقتًا أو يُرفض	السيناريوهات التي تحتاج معالجة منتظمة صارمة	متوسط
النافذة المنزلقة	إحصاء عدد الطلبات في نافذة زمنية	حساب صارم بالنافذة، أي تجاوز يُرفض	الإحصاء الدقيق (مثل "حد أقصى 100 مرة في الدقيقة")	مرتفع

7.2 تكوين تحديد المعدل في Nginx عمليًا

nginx

# تعريف مناطق تحديد المعدل (توضع في كتلة http)

# 1. تحديد المعدل بناءً على IP (خوارزمية الدلو المتسرب)
# zone=mylimit:10m - اسم المنطقة وحجم الذاكرة (10MB تكفي لتخزين حوالي 160 ألف IP)
# rate=10r/s - السماح بـ 10 طلبات في الثانية
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

# 2. تحديد عدد الاتصالات بناءً على IP (منع IP واحد من إنشاء اتصالات كثيرة)
limit_conn_zone $binary_remote_addr zone=addr:10m;

# 3. تحديد المعدل بناءً على نقطة نهاية الخادم (دون تمييز IP، لحماية الخلفية ككل)
limit_req_zone $server_name zone=server_limit:10m rate=100r/s;

server {
    listen 80;
    server_name api.example.com;

    # خدمة المستخدم - تحديد معدل عادي
    location /api/users/ {
        # تطبيق تحديد المعدل
        # burst=20 - سعة الدلو، يسمح بـ 20 طلبًا مفاجئًا
        # nodelay - عدم تأخير معالجة الطلبات المفاجئة (معالجة فورية أو رفض)
        limit_req zone=mylimit burst=20 nodelay;

        # تقييد اتصالات IP الواحد
        limit_conn addr 10;

        proxy_pass http://user-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # خدمة الطلبات - تحديد معدل أكثر صرامة
    location /api/orders/ {
        # تحديد معدل أكثر صرامة: 5 طلبات في الثانية
        limit_req_zone $binary_remote_addr zone=order_limit:10m rate=5r/s;
        limit_req zone=order_limit burst=10 nodelay;

        proxy_pass http://order-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # معالجة ما بعد تحديد المعدل
    # عند تجاوز الحد، إرجاع 429 Too Many Requests
    error_page 429 /429.html;
    location = /429.html {
        internal;
        return 429 '{"error": "Too Many Requests", "message": "Rate limit exceeded. Please try again later."}';
        add_header Content-Type application/json;
    }
}

💡 نصائح لاستراتيجية تحديد المعدل

الواجهات العادية: 10 طلبات في الثانية، مع السماح بـ 20 طلبًا مفاجئًا
الواجهات الهامة (الدفع، الطلبات): 5 طلبات في الثانية، مع السماح بـ 10 طلبات مفاجئة
الحماية الشاملة: مجموع كل الطلبات لا يتجاوز 100 طلب في الثانية

选择限流算法

🪙 令牌桶算法可视化

令牌桶

🪙

5 / 10 令牌

⏰ 令牌产生器 (2/秒)

🪙

📥 请求队列

📊 三种算法对比

维度	令牌桶 (Token Bucket)	漏桶 (Leaky Bucket)	滑动窗口 (Sliding Window)
核心思想	桶里装令牌，有令牌才能通过	请求进桶，匀速流出处理	统计时间窗口内的请求数
突发流量	✅ 允许一定程度的突发（桶里有令牌）	❌ 强制平滑，突发会被缓存或拒绝	❌ 严格按窗口计数，超出一律拒绝
适用场景	API 限流、带宽控制（允许突发）	需要严格匀速处理的场景（如消息队列）	精确统计（如"1分钟内最多100次"）
实现复杂度	中等	中等	较高（需要记录每个时间窗口的请求）
Nginx 配置	limit_req_zone (漏桶)	limit_req_zone (漏桶)	需第三方模块或 Lua

📝 Nginx 限流配置示例

# 定义限流区域
# $binary_remote_addr: 按 IP 限流
# zone=mylimit:10m: 区域名称和大小
# rate=10r/s: 每秒最多10个请求
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    listen 80;
    server_name api.example.com;

    location / {
        # 应用限流
        # burst=20: 桶容量，允许突发20个请求
        # nodelay: 不延迟处理突发请求
        limit_req zone=mylimit burst=20 nodelay;

        proxy_pass http://backend;
    }
}

💡 配置说明

limit_req_zone: 在 http 块中定义限流区域
$binary_remote_addr: 使用二进制 IP 地址作为限流键（省内存）
zone=mylimit:10m: 区域名称 mylimit，分配 10MB 内存
rate=10r/s: 每秒允许 10 个请求（漏桶算法）
burst=20: 桶的容量为 20，允许一定程度的突发流量
nodelay: 不延迟处理突发请求（立即处理或拒绝）

7.3 الانصهار: منع انتشار الأعطال

مبدأ عمل قاطع الدائرة (Circuit Breaker):

الحالة المغلقة: إعادة توجيه الطلبات بشكل طبيعي مع إحصاء معدل الأخطاء
الحالة المفتوحة: عندما يتجاوز معدل الأخطاء الحد، يفتح القاطع، ويعيد الخطأ مباشرة دون إعادة توجيه الطلبات
حالة نصف المفتوحة: بعد مرور فترة، يُسمح بمرور عدد قليل من الطلبات للاستكشاف، إذا نجحت يُغلق القاطع

💡 الفكرة الأساسية

الانصهار مثل فيوز الكهرباء: عندما يزيد التيار، ينصهر الفيوز تلقائيًا ليحمي الدائرة بأكملها من الاحتراق.

بالمثل، عندما تظهر أخطاء كثيرة في الخدمة الخلفية، "يتعطل" القاطع، ويفشل بسرعة، مما يمنع انتشار العطل إلى النظام بأكمله.

8. الخلاصة: التفكير الأساسي في تصميم البوابة

8.1 مراجعة المبادئ الأساسية

المبدأ	المعنى	نقاط التطبيق
التوجيه	إيصال الطلب إلى المكان الصحيح	توجيه المسار، توجيه النطاق، توجيه Header
موازنة الحمل	توزيع حركة المرور على خوادم متعددة	التناوب، الموزون، الأقل اتصالات، تجزئة IP
الأمان	حماية بوابة النظام	المصادقة والتفويض، HTTPS، WAF
تحديد المعدل	منع الانهيار بسبب حركة المرور	دلو الرموز، الدلو المتسرب، النافذة المنزلقة
الانصهار	منع انتشار الأعطال	الفشل السريع، خطط التخفيض
المراقبة	المراقبة واستكشاف الأخطاء	السجلات، المؤشرات، تتبع الروابط

8.2 نصائح لاختيار التقنية

💡 شجرة قرار الاختيار

اختيار البوابة:
│
├─ تحتاج فقط إلى وكيل عكسي وموازنة حمل؟
│  ├─ نعم → Nginx (الخيار الأول)
│  └─ لا → تابع
│
├─ تحتاج إلى نظام إضافات غني؟
│  ├─ نعم → Kong (مبني على Nginx)
│  └─ لا → تابع
│
├─ مجموعة Spring Cloud؟
│  ├─ نعم → Spring Cloud Gateway
│  └─ لا → Nginx

9. جدول المصطلحات المرجعي

المصطلح	English	الشرح
الوكيل العكسي	Reverse Proxy	خدمة وكيل تُنشر على جانب الخادم، تستقبل طلبات العميل وتعيد توجيهها إلى الخدمات الداخلية. العميل يعرف فقط وجود الوكيل العكسي، ولا يعرف عنوان الخادم الحقيقي.
الوكيل الأمامي	Forward Proxy	خدمة وكيل تُنشر على جانب العميل، تعمل نيابة عن العميل للوصول إلى الموارد الخارجية. الخادم يرى IP الوكيل، ولا يعرف العميل الحقيقي. تطبيقات نموذجية: VPN، أدوات تجاوز الحظر.
بوابة API	API Gateway	طبقة وسطى بين العميل والخدمات الخلفية، توفر التوجيه والمصادقة وتحديد المعدل والسجلات وغيرها، وهي "البوابة الموحدة" لمعمارية الخدمات المصغرة.
موازنة الحمل	Load Balancing	توزيع حركة الطلبات على خوادم متعددة، لتجنب التحميل الزائد على خادم واحد، وزيادة توفر النظام وأدائه.
إنهاء SSL	SSL Termination	معالجة تشفير وفك تشفير HTTPS في طبقة البوابة، واستخدام HTTP للخدمات الخلفية، مما يقلل العبء الحسابي على الخلفية ويبسط إدارة الشهادات.
تحديد المعدل	Rate Limiting	تقييد عدد الطلبات في وحدة الزمن، لمنع انهيار النظام بسبب حركة المرور المفاجئة. الخوارزميات الشائعة: دلو الرموز، الدلو المتسرب، النافذة المنزلقة.
الانصهار	Circuit Breaking	عند حدوث عطل في خدمة تابعة، يتم قطع الاستدعاء تلقائيًا لمنع انتشار العطل، مع توفير خطة تخفيض.
استمرارية الجلسة	Session Persistence	ضمان توجيه طلبات نفس العميل دائمًا إلى نفس الخادم الخلفي، للسيناريوهات التي تحتاج الحفاظ على حالة الجلسة.
الفحص الصحي	Health Check	فحص دوري لحالة الخدمات الخلفية، وإزالة العقد المعطلة تلقائيًا، لضمان توجيه حركة المرور فقط إلى نسخ الخدمة السليمة.
النشر التدريجي	Canary Release	توجيه كمية صغيرة من حركة المرور إلى الإصدار الجديد، والتحقق من الاستقرار ثم زيادة النسبة تدريجيًا، لتقليل مخاطر النشر.
WAF	Web Application Firewall	جدار حماية تطبيقات الويب، للحماية من حقن SQL وهجمات XSS وهجمات CC وغيرها من تهديدات أمان الويب.
CDN	Content Delivery Network	شبكة توصيل المحتوى، تنشر عقدًا طرفية حول العالم لتسريع الوصول إلى الموارد الثابتة.

البوابة والوكيل العكسي (Gateway & Reverse Proxy) ​

1. لماذا نحتاج إلى "بوابة"؟ ​

1.1 حالة واقعية: تطور معمارية متجر إلكتروني ​

1.2 تشبيه حياتي للبوابة ​

2. ما هو الوكيل العكسي؟ ​

2.1 الوكيل الأمامي مقابل الوكيل العكسي ​

2.2 القيمة الأساسية للوكيل العكسي ​

3. Nginx: لماذا يستطيع تحمل ملايين الطلبات المتزامنة؟ ​

3.1 نموذج العمليات Master-Worker ​

3.2 النموذج المدفوع بالأحداث + غير المتزامن وغير المحظور ​

4. ما هي بوابة API؟ ​

4.1 لماذا نحتاج إلى بوابة API؟ ​

4.2 الوظائف الأساسية لبوابة API ​

5. البوابة عمليًا: كيفية بناء معمارية بوابة كاملة؟ ​

5.1 مخطط المعمارية الكاملة ​

5.2 التوجيه وموازنة الحمل ​

6. أمان البوابة: كيفية حماية بوابة النظام؟ ​

6.1 المصادقة والتفويض ​

6.2 HTTPS وإنهاء SSL ​

7. تحديد المعدل والانصهار: كيفية منع النظام من الانهيار بسبب "طوفان حركة المرور"؟ ​

7.1 مقارنة خوارزميات تحديد المعدل ​

7.2 تكوين تحديد المعدل في Nginx عمليًا ​

7.3 الانصهار: منع انتشار الأعطال ​

8. الخلاصة: التفكير الأساسي في تصميم البوابة ​

8.1 مراجعة المبادئ الأساسية ​

8.2 نصائح لاختيار التقنية ​

9. جدول المصطلحات المرجعي ​

البوابة والوكيل العكسي (Gateway & Reverse Proxy)

1. لماذا نحتاج إلى "بوابة"؟

1.1 حالة واقعية: تطور معمارية متجر إلكتروني

1.2 تشبيه حياتي للبوابة

2. ما هو الوكيل العكسي؟

2.1 الوكيل الأمامي مقابل الوكيل العكسي

2.2 القيمة الأساسية للوكيل العكسي

3. Nginx: لماذا يستطيع تحمل ملايين الطلبات المتزامنة؟

3.1 نموذج العمليات Master-Worker

3.2 النموذج المدفوع بالأحداث + غير المتزامن وغير المحظور

4. ما هي بوابة API؟

4.1 لماذا نحتاج إلى بوابة API؟

4.2 الوظائف الأساسية لبوابة API

5. البوابة عمليًا: كيفية بناء معمارية بوابة كاملة؟

5.1 مخطط المعمارية الكاملة

5.2 التوجيه وموازنة الحمل

6. أمان البوابة: كيفية حماية بوابة النظام؟

6.1 المصادقة والتفويض

6.2 HTTPS وإنهاء SSL

7. تحديد المعدل والانصهار: كيفية منع النظام من الانهيار بسبب "طوفان حركة المرور"؟

7.1 مقارنة خوارزميات تحديد المعدل

7.2 تكوين تحديد المعدل في Nginx عمليًا

7.3 الانصهار: منع انتشار الأعطال

8. الخلاصة: التفكير الأساسي في تصميم البوابة

8.1 مراجعة المبادئ الأساسية

8.2 نصائح لاختيار التقنية

9. جدول المصطلحات المرجعي