Apache APISIX כשער API למיקרוסרוויסים

הקמת Apache APISIX כשער API עבור מיקרוסרוויסים

אנו נתקלים כל הזמן במצבים שבהם ארכיטקטורת מיקרוסרוויסים גדלה, ו-Nginx או HAProxy פשוטים כבר לא יכולים להתמודד עם ניתוב דינמי. שנים של ניסיון עם שערי API הראו: Apache APISIX הוא הפתרון הטוב ביותר לניהול תעבורה גמיש ללא זמן השבתה. אנו מבטיחים שאחרי ההקמה תשכחו מעריכות קונפיגורציה ידניות ומזמן השבתה בכל פריסה.

APISIX הוא שער API בעל ביצועים גבוהים הבנוי על OpenResty (Nginx + LuaJIT) עם etcd כמאגר התצורה. ההבדל העיקרי שלו מ-Kong ופתרונות אחרים הוא ששינויי תצורה מיושמים ללא טעינה מחדש, וזמן העדכון של הניתוב נמדד במילישניות. עבור סביבות מיקרוסרוויסים דינמיות שבהן פריסות מתרחשות עשרות פעמים ביום, זה משמעותי. המהנדסים שלנו מוסמכים והקימו APISIX בפרויקטים עם עומס של 50,000 RPS.

למה Apache APISIX מהיר יותר משערי API אחרים?

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

ארכיטקטורה ורכיבים

APISIX מורכב משלושה חלקים מרכזיים: מישור נתונים (עיבוד תעבורה), מישור בקרה (Admin API + Dashboard), ו-etcd (אחסון תצורה). בסביבת ייצור, מישור הנתונים נפרס עם לפחות שתי מופעים מאחורי מאזן עומסים; מישור הבקרה מבודד מגישה חיצונית. אשכול ה-etcd צריך לכלול לפחות שלושה עותקים לסובלנות תקלות ועקביות מהירה.

פריסה ב-Kubernetes באמצעות Helm:

helm repo add apisix https://charts.apiseven.com
helm repo update
helm install apisix apisix/apisix \
  --namespace ingress-apisix \
  --create-namespace \
  --set gateway.type=LoadBalancer \
  --set ingress-controller.enabled=true \
  --set etcd.replicaCount=3 \
  --set apisix.replicaCount=2

לאחר ההתקנה, ה-Admin API זמין ב-helm repo add apisix https://charts.apiseven.com helm repo update helm install apisix apisix/apisix \ --namespace ingress-apisix \ --create-namespace \ --set gateway.type=LoadBalancer \ --set ingress-controller.enabled=true \ --set etcd.replicaCount=3 \ --set apisix.replicaCount=2 — רק בתוך האשכול. אנו אף פעם לא חושפים אותו חיצונית.

ניתוב ותצורת Upstream

יצירת upstream וניתוב דרך Admin API:

# Upstream — пул бэкендов
curl -X PUT http://apisix:9180/apisix/admin/upstreams/1 \
  -H "X-API-KEY: $ADMIN_KEY" \
  -d '{
    "type": "roundrobin",
    "nodes": {
      "orders-svc.default.svc.cluster.local:8080": 1,
      "orders-svc-v2.default.svc.cluster.local:8080": 1
    },
    "checks": {
      "active": {
        "http_path": "/health",
        "interval": 5,
        "successes": 2,
        "http_failures": 3
      }
    }
  }'

# Route — правило матчинга трафика
curl -X PUT http://apisix:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $ADMIN_KEY" \
  -d '{
    "uri": "/api/v1/orders/*",
    "host": "api.example.com",
    "upstream_id": 1,
    "plugins": {
      "rate-limiting": {
        "count": 1000,
        "time_window": 60,
        "key": "consumer_name"
      },
      "jwt-auth": {},
      "prometheus": {}
    }
  }'

בדיקות בריאות מובנות בתוך upstreams — APISIX מסיר אוטומטית צמתים לא בריאים מאיזון העומסים. זה קריטי במהלך פריסות מתגלגלות: בזמן ש-pod חדש לא עבר בדיקות מוכנות, צמתים ישנים ממשיכים לטפל בתעבורה.

ארכיטקטורת תוספים

החוזק של APISIX הוא בתוספים שלו. מובנים כברירת מחדל: אימות (JWT, OAuth 2.0, API key, LDAP), הגבלת קצב עם אסטרטגיות מרובות (צרכן, IP, שירות), טרנספורמציה של בקשה/תגובה, מפסק מעגל, מעקב דרך OpenTelemetry ו-Zipkin, מדדים עבור Prometheus.

דוגמה לתצורת מפסק מעגל להגנה מפני כשלים מדורגים:

"api-breaker": {
  "break_response_code": 503,
  "max_breaker_sec": 30,
  "unhealthy": {
    "http_statuses": [500, 502, 503],
    "failures": 5
  },
  "healthy": {
    "http_statuses": [200],
    "successes": 3
  }
}

חמש שגיאות רצופות פותחות את המעגל; בקשות מקבלות 503 ללא גישה לשרת האחורי. שלוש תגובות מוצלחות לאחר פסק הזמן סוגרות את המעגל. שירות הקצה האחורי מקבל זמן להתאושש.

ניתן לכתוב תוספים מותאמים אישית ב-Lua או דרך הרצת תוספים ב-Go/Python/Java. זה מבדיל את APISIX מפתרונות שבהם הרחבה דורשת פיצול הקוד.

איך להקים פריסה קנרית עם APISIX?

ב-Kubernetes, תצורה דרך CRDs טבעית יותר מקריאות API ישירות:

---
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: orders-route
spec:
  http:
    - name: orders
      match:
        hosts:
          - api.example.com
        paths:
          - /api/v1/orders/*
      backends:
        - serviceName: orders-svc
          servicePort: 8080
          weight: 90
        - serviceName: orders-svc-v2
          servicePort: 8080
          weight: 10
      plugins:
        - name: jwt-auth
          enable: true
        - name: prometheus
          enable: true

קנרית של 10%/90% בין גרסאות שירות מנוהלת דרך 9180/tcp — ללא שינויים ידניים כשמגלגלים גרסה חדשה בהדרגה.

איך APISIX מתקנה תחת עומס?

מישור הנתונים של APISIX מתקנה אופקית על ידי הוספת מופעים מאחורי מאזן עומסים. לקנה מידה דינמי ב-Kubernetes, אנו משתמשים ב-HPA המבוסס על מדדי CPU או RPS. אשכול ה-etcd גם מתקנה — אנו ממליצים על 3, 5 או 7 צמתים בהתאם לעומס. ככל שמספר הניתובים גדל (עד 5000+), etcd שומר על ביצועים יציבים.

מה כלול בעבודה

נעריך את הפרויקט שלכם. כחלק מההקמה סוהר:

• עיצוב טופולוגיה: מספר מופעי מישור נתונים, בידוד מישור בקרה, תכנית אחסון תצורה ב-etcd.
• התקנה ב-Kubernetes או על שרתים פיזיים.
• המרת כללי nginx/HAProxy קיימים לתצורת APISIX.
• הקמת אימות, הגבלת קצב וניטור (Prometheus + לוח מחוונים של Grafana).
• בדיקות עומס עם סימולציית כשלים.
• תיעוד נהלים אדמיניסטרטיביים.

העלות מחושבת באופן אישי לאחר ביקורת. צרו קשר לייעוץ על הפרויקט שלכם. בקשו ביקורת על התשתית שלכם — נזהה צווארי בקבוק ונבחר את התצורה האופטימלית. 5+ שנות ניסיון עם APISIX ו-30+ הטמעות מבטיחות תוצאות.