הגדרת שער API (APISIX) עבור יישום אינטרנט

תארו לעצמכם שיישום האינטרנט שלכם ב-React 18 רץ ב-Kubernetes, אבל כל מיקרוסרוויס חדש דורש הגדרה ידנית של CORS, JWT והגבלת קצב. ללא שער מרכזי, אתם מבזבזים ימים על שכפול הגדרות ומאבדים שליטה על התעבורה. עברנו את זה בפרויקט עם 12 מיקרוסרוויסים—ובחרנו ב-Apache APISIX. שער ה-API הזה המבוסס על OpenResty אפשר לנו לקצר את זמן הפריסה של נקודות קצה חדשות מ-4 שעות ל-15 דקות ולהפחית את עומס התשתית ב-30% באמצעות הגבלת קצב יעילה. APISIX לא רק מנתב בקשות אלא גם מספק מנגנוני אימות, הגבלת קצב וניטור גמישים החיוניים לארכיטקטורת מיקרוסרוויסים. לפי התיעוד הרשמי של הפרויקט, מדובר בשער API דינמי ובעל ביצועים גבוהים הפותר בעיות אבטחה ונראות ישירות מהקופסה. להלן ניסיון מעשי בהתקנה, כולל פלאגינים, ניטור ופריסות קנריות.

אילו בעיות APISIX פותר

• ניהול נתיבים דינמי ללא הפעלות מחדש: APISIX מאחסן את התצורה ב-etcd ומיישם שינויים באופן מיידי באמצעות watch. אין צורך ב-reload של nginx—התעבורה אינה מופרעת.
• אבטחה מובנית: פלאגינים JWT, OIDC, אימות בסיסי, רשימה שחורה של IP—מוגדרים דרך Admin API. אנו משתמשים ב-RS256 עבור לקוחות ניידים.
• הגבלת קצב עם Redis: 100 בקשות לדקה לכל IP עובדת גם תחת עומס של 10k RPS.
• פריסות קנריות: באמצעות פיצול תעבורה, ניתן לשלוח 10% מהבקשות לגרסת שירות חדשה, לנתח מדדים ולהגדיל בהדרגה את המשקל.

כיצד APISIX פותר ניתוב דינמי

APISIX משתמש ב-etcd כמאגר מצב יחיד. כל שינוי בנתיב דרך Admin API או Dashboard גורם ל-etcd להפיץ את העדכון אוטומטית לכל צמתי האשכול. זה מאפשר הוספה ושינוי של נתיבים ללא זמן השבתה. בניגוד לתצורת nginx סטטית, APISIX תומך בתנאי ניתוב גמישים: לפי URI, מתודות, כותרות, פרמטרי שאילתה ואפילו טווחי IP.

ארכיטקטורה והתקנה

Client → APISIX Gateway (nginx/OpenResty) → Upstream Services ↕ ETCD (config store) ↕ APISIX Dashboard 

ETCD הוא חובה—כל התצורה (נתיבים, upstreams, פלאגינים) מאוחסנת שם. שינויים מיושמים בזמן אמת באמצעות watch.

Docker Compose

---
version: '3.8'
services:
  etcd:
    image: bitnami/etcd:3.5
    environment:
      ALLOW_NONE_AUTHENTICATION: "yes"
      ETCD_ADVERTISE_CLIENT_URLS: http://etcd:2379
      ETCD_LISTEN_CLIENT_URLS: http://0.0.0.0:2379
  apisix:
    image: apache/apisix:3.9.1-debian
    volumes:
      - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml
    ports:
      - "9080:9080" # HTTP
      - "9443:9443" # HTTPS
      - "9180:9180" # Admin API
      - "9091:9091" # Prometheus metrics
    depends_on: [etcd]
  apisix-dashboard:
    image: apache/apisix-dashboard:3.0.1-alpine
    volumes:
      - ./dashboard_conf/conf.yaml:/usr/local/apisix-dashboard/conf/conf.yaml
    ports:
      - "9000:9000"
    depends_on: [etcd]

יצירת נתיב דרך Admin API

BASE_URL="http://localhost:9180/apisix/admin"
KEY="supersecret-admin-key"

# Создать upstream
curl -X PUT $BASE_URL/upstreams/1 \
  -H "X-API-KEY: $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "roundrobin",
    "nodes": {
      "users-service:3000": 1,
      "users-service-2:3000": 1
    },
    "checks": {
      "active": {
        "http_path": "/health",
        "interval": 5,
        "healthy": {
          "successes": 2
        },
        "unhealthy": {
          "http_failures": 3
        }
      }
    }
  }'

# Создать route с JWT и rate limiting
curl -X PUT $BASE_URL/routes/1 \
  -H "X-API-KEY: $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "uri": "/api/v1/users/*",
    "methods": ["GET", "POST", "PUT", "DELETE"],
    "upstream_id": "1",
    "plugins": {
      "jwt-auth": {},
      "rate-limiting": {
        "count": 100,
        "time_window": 60,
        "key": "remote_addr",
        "policy": "redis",
        "redis_host": "redis",
        "redis_port": 6379
      },
      "cors": {
        "allow_origins": "https://app.company.com",
        "allow_methods": "GET,POST,PUT,DELETE",
        "allow_headers": "Authorization,Content-Type",
        "allow_credential": true
      }
    }
  }'

פלאגינים לאבטחה וניתוב

JWT ו-OIDC

לאימות אנו משתמשים בפלאגין Client → APISIX Gateway (nginx/OpenResty) → Upstream Services ↕ ETCD (config store) ↕ APISIX Dashboard עם RS256. צרכן נוצר דרך Admin API:

curl -X PUT $BASE_URL/consumers/mobile-app \
  -H "X-API-KEY: $KEY" \
  -d '{ "username": "mobile-app", "plugins": { "jwt-auth": { "key": "mobile-app-key", "algorithm": "RS256", "public_key": "-----BEGIN PUBLIC KEY-----\n..." } } }'

עבור OpenID Connect (OIDC) ההתקנה מעט מורכבת יותר: יש לציין את נקודת הקצה version: '3.8' services: etcd: image: bitnami/etcd:3.5 environment: ALLOW_NONE_AUTHENTICATION: "yes" ETCD_ADVERTISE_CLIENT_URLS: http://etcd:2379 ETCD_LISTEN_CLIENT_URLS: http://0.0.0.0:2379 apisix: image: apache/apisix:3.9.1-debian volumes: - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml ports: - "9080:9080" # HTTP - "9443:9443" # HTTPS - "9180:9180" # Admin API - "9091:9091" # Prometheus metrics depends_on: [etcd] apisix-dashboard: image: apache/apisix-dashboard:3.0.1-alpine volumes: - ./dashboard_conf/conf.yaml:/usr/local/apisix-dashboard/conf/conf.yaml ports: - "9000:9000" depends_on: [etcd] , BASE_URL="http://localhost:9180/apisix/admin" KEY="supersecret-admin-key" # Создать upstream curl -X PUT $BASE_URL/upstreams/1 \ -H "X-API-KEY: $KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "roundrobin", "nodes": { "users-service:3000": 1, "users-service-2:3000": 1 }, "checks": { "active": { "http_path": "/health", "interval": 5, "healthy": { "successes": 2 }, "unhealthy": { "http_failures": 3 } } } }' # Создать route с JWT и rate limiting curl -X PUT $BASE_URL/routes/1 \ -H "X-API-KEY: $KEY" \ -H "Content-Type: application/json" \ -d '{ "uri": "/api/v1/users/*", "methods": ["GET", "POST", "PUT", "DELETE"], "upstream_id": "1", "plugins": { "jwt-auth": {}, "rate-limiting": { "count": 100, "time_window": 60, "key": "remote_addr", "policy": "redis", "redis_host": "redis", "redis_port": 6379 }, "cors": { "allow_origins": "https://app.company.com", "allow_methods": "GET,POST,PUT,DELETE", "allow_headers": "Authorization,Content-Type", "allow_credential": true } } }' ו-jwt-auth. הפלאגין תומך ב-RS256 ומעביר אוטומטית את ה-access token בכותרת.

Serverless וקנרי

פלאגין ה-serverless מאפשר להריץ לוגיקת Lua מותאמת אישית בשלבי ה-rewrite או ה-access. לדוגמה, הוספת כותרת מזהה דייר:

curl -X PUT $BASE_URL/routes/2 \
 -H "X-API-KEY: $KEY" \
 -d '{ "uri": "/api/v1/transformed", "upstream_id": "1", "plugins": { "serverless-pre-function": { "phase": "rewrite", "functions": [ "return function(conf, ctx)\n local headers = ngx.req.get_headers()\n ngx.req.set_header(\"X-Tenant-ID\", headers[\"X-User-Tenant\"])\n ngx.req.set_header(\"X-Internal-Key\", \"secret\")\nend" ] } } }'

פריסות קנריות מיושמות באמצעות curl -X PUT $BASE_URL/consumers/mobile-app \ -H "X-API-KEY: $KEY" \ -d '{ "username": "mobile-app", "plugins": { "jwt-auth": { "key": "mobile-app-key", "algorithm": "RS256", "public_key": "-----BEGIN PUBLIC KEY-----\n..." } } }' : לדוגמה, 10% לגרסה החדשה, וכאשר קיימת הכותרת discovery, 100% הולכים לגרסה הישנה. זה מאפשר בדיקת שחרור בטוחה.

כיצד להגדיר פריסה קנרית ב-APISIX?

לפריסה קנרית אנו משתמשים בפלאגין client_id. דוגמת תצורה: 10% מהבקשות נשלחות לגרסה החדשה (upstream עם תג client_secret). כאשר מתקבלת הכותרת curl -X PUT $BASE_URL/routes/2 \ -H "X-API-KEY: $KEY" \ -d '{ "uri": "/api/v1/transformed", "upstream_id": "1", "plugins": { "serverless-pre-function": { "phase": "rewrite", "functions": [ "return function(conf, ctx)\n local headers = ngx.req.get_headers()\n ngx.req.set_header(\"X-Tenant-ID\", headers[\"X-User-Tenant\"])\n ngx.req.set_header(\"X-Internal-Key\", \"secret\")\nend" ] } } }' , התעבורה עוברת כולה לגרסה הישנה. הפלאגין traffic-split אוסף מדדים—כאשר יציב, חלקה של הגרסה החדשה גדל. להלן קטע תצורת נתיב:

curl -X PUT $BASE_URL/routes/3 \
  -H "X-API-KEY: $KEY" \
  -d '{
    "uri": "/api/v2/users/*",
    "plugins": {
      "traffic-split": {
        "rules": [
          {
            "weighted_upstreams": [
              {
                "upstream_id": 1,
                "weight": 90
              },
              {
                "upstream": {
                  "type": "roundrobin",
                  "nodes": {
                    "users-v2:3000": 1
                  }
                },
                "weight": 10
              }
            ]
          }
        ]
      }
    }
  }'

ניטור והשוואה עם Kong

מדדי ה-Prometheus של APISIX מיוצאים בפורט 9091. התיעוד הרשמי כולל דוגמת תצורה. עבור Grafana, השתמשו במזהה לוח המחוונים 11719.

APISIX עולה על Kong בכפי 2 בערך בעומסים טיפוסיים. בנוסף, etcd מספק תצורה דינמית מהירה יותר בהשוואה ל-PostgreSQL. עבור פרויקטים בעלי עומס גבוה עם עשרות נתיבים, APISIX הוא בחירה יעילה יותר.

טבלת תהליך

מה כלול וזמנים

• ביקורת על התשתית הקיימת ובחירת תוכנית ניתוב.
• פריסת APISIX עם ETCD ו-Dashboard.
• הגדרת פלאגינים: JWT, rate-limit, CORS, OIDC, serverless.
• אינטגרציה עם Prometheus ו-Grafana.
• תיעוד לנתיבים ופלאגינים.
• הדרכת צוות: סדנה של שעתיים.
• שבועיים של תמיכה לאחר ההשקה.

זמנים משוערים

הגדרת APISIX עם Dashboard, פלאגינים בסיסיים (JWT, rate-limit, CORS) ובדיקות בריאות—בין 2 ל-3 ימים. תצורה מלאה עם OIDC, פיצול תעבורה ו-Kubernetes Ingress—בין 5 ל-7 ימים.

אנו מבטיחים SLA של 99.9% על זמינות השער. הניסיון שלנו: מעל 50 פרויקטים עם API Gateway. קבלו ייעוץ לביקורת על התשתית שלכם—נעריך את הפרויקט שלכם ביום אחד ללא עלות. צרו קשר—נעזור לכם לבחור באסטרטגיה האופטימלית.