API دروازه و مسیریابی

1) نقش دروازه API در معماری

• ترافیک ورودی را می پذیرد (HTTP/HTTP2/HTTP3، WebSocket، gRPC)
• مسیرها با توجه به قوانین (میزبان/مسیر/هدر/روش/پرس و جو/جغرافیایی/وزن/سلامت) ؛
• سیاست های پایان دادن به پایان را اعمال می کند: احراز هویت/مجوز، محدود کردن نرخ، WAF، CORS، ذخیره سازی ؛
• انجام تحولات (عادی سازی هدر/بدن، gRPC↔JSON، دوخت GraphQL) ؛
• فراهم می کند ثبات (timeouts، rerits، قطع کننده مدار، تشخیص outlier) ؛
• می دهد مشاهده و صدور صورت حساب (سیاهههای مربوط، معیارها، آثار، سهمیه) ؛
• توپولوژی داخلی (مش سرویس، خدمات خصوصی) را جدا می کند.

اغلب در جفت استفاده می شود: Edge/API-Gateway + Ingress/Mesh (Envoy/Istio/Linkerd) - اولین سیاست خارجی را تصمیم می گیرد، دوم - شرق و غرب.

2) توپولوژی های معمولی

تنها دروازه جهانی (CDN/POP لبه → دروازه L7 → خدمات) - ساده، سیاست های متمرکز.
دروازه های منطقه ای (در هر منطقه) + مسیریابی جغرافیایی/تأخیر هوشمند.
چند مستاجر: مسیرهای اختصاصی/زیر دامنه ها/کلید ها، سهمیه ها و محدودیت های هر مستاجر.
ترکیبی: در prem + ابر، لینک خصوصی/peering، خصوصی پشت دروازه API.

3) قوانین مسیریابی L7

• میزبان/مسیر: 'api. به عنوان مثال. com →/v1/سفارشات/'.
• سرصفحه ها: «X-Client»، «X-Region»، «User-Agent»، «Accept».
• روش/محتوا نوع: تشخیص JSON/Proto/GraphQL.
• پرس و جو/قطعه: دقیق - تحت تاثیر قرار کش/انواع.
• Geo/Latency: نزدیکترین POP/منطقه، شکست خورده تحت تخریب.
• وزن/قناری: توزیع ترافیک 90/10، 50/50، چسبنده با کوکی.
• وابستگی جلسه: هش مبتنی بر کلید/نشانه (مراقب باشید در هنگام پوسته پوسته شدن).

yaml nginx. ingress. kubernetes. io/canary: "true"
nginx. ingress. kubernetes. io/canary-weight: "10" # 10% traffic to new backend

yaml match: { prefix: "/orders", headers: [{name: "X-Experiment", exact_match: "new"}] }
route: { cluster: orders-v2 }

4) پروتکل ها و سازگاری

REST/JSON - به طور پیش فرض، OpenAPI را برای اعتبار سنجی/تولید مشتری توصیف کنید.
gRPC - باینری پروتو بیش از HTTP/2 ؛ برای مشتریان خارجی، از رمزگذاری gRPC-JSON استفاده کنید.
GraphQL - جمع آوری خدمات ؛ در محیط، نظارت بر پیچیدگی/عمق نمایش داده شد.
WebSocket/SSE - دو طرفه/فشار ؛ در نظر بگیرید چسبنده و timeouts.
HTTP/2/3 (QUIC) - شروع چندگانه/سریع ؛ بررسی سازگاری WAF/پروکسی.

5) امنیت: احراز هویت و مجوز

5. 1 حمل و نقل

TLS 1. 2 + در محیط، HSTS، مهر و موم OCSP، PFS.
mTLS برای API B2B/internal و ماشین به ماشین.
IP allowlist/denylist، محدودیت های جغرافیایی.

5. 2 لایه کاربرد

OAuth2/OIDC: نشانه های حامل JWT، تایید امضا/انقضا/مخاطب.
NMAS/امضا: تاریخ + canonized خط + امضا (AWS مانند) - حفاظت در برابر جایگزینی، تکرار (پنجره nonce/زمان).
کلیدهای API: فقط به عنوان شناسه ؛ حقوق - از طریق RBAC/ABAC/حوزه.
CORS: صریح اجازه منشاء، کش قبل از پرواز.
WAF: signatures (OWASP API Top 10), anomaly, bot protection, recursive JSON fields.
DDoS/Abuse: محدود کردن اتصال، سطل token-bucket/Leaky، سرعت متوسط birst +، ممنوعیت پویا.

yaml plugins:
- name: oidc config: { issuer: "...", client_id: "...", client_secret: "...", scopes: ["orders. read"] }
- name: rate-limiting config: { minute: 600, policy: local }

6) اعتبار، تحول و سازگاری

طرح ها: اعتبار سنجی بدن/هدر/پارامترها با توجه به OpenAPI/JSON-Schema/Protobuf.
تبدیل: نرمال سازی میدان، پوشش PII، اضافه کردن هدر های همبستگی ('traceparent'، 'x-request-id').
نسخه بندی: 'Header: X-API-Version', prefixes '/v1 ', resource-versioning; سیاست تخفیف и غروب آفتاب.
کامپکت عقب: فقط اضافه کردن زمینه ؛ اجتناب از «شکستن» تغییرات بدون نسخه جدید.
Idempotency: «Idempotency-Key» для POST ؛ کلید فروشگاه های دروازه در Redis با TTL.

7) انعطاف پذیری: سیاست های اتصال

وقفه ها: اتصال/خواندن/نوشتن ؛ پیش فرض های معقول (به عنوان مثال،. 1s/5s/5s).
تکرار: فقط برای ایمن و بی نظیر ؛ jitter، عقب نشینی نمایشی، حداکثر تلاش.
قطع کننده مدار: باز در خطاها/تاخیر ؛ نیمه باز برای نمونه.
تشخیص پرت - موارد بد را از استخر حذف کنید.
Bulkhead/competition: محدودیت در درخواست های همزمان در هر مسیر.
شکست: فعال/منفعل، تخریب منطقه ای.
ترافیک سایه: V2 «خاکستری» به موازات V1 (بدون تاثیر بر پاسخ) برای مقایسه اجرا می شود.

yaml circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 1024 max_pending_requests: 2048 max_retries: 3

8) ذخیره سازی و عملکرد

HTTP- кеш: «Cache-Control»، «ETag/If-None-Match»، «Vary»، «stale-while-revalidate».
ذخیره سازی لبه/POP: CDN ها برای API های استاتیک و ذخیره شده (GET های idempotent).
فشرده سازی: 'gzip/br' (فشرده سازی در حال حاضر فشرده نیست).
درخواست فروپاشی («coalescing»): ترکیب درخواست های موازی مشابه.
شکل دادن به پاسخ: فیلدها/فیلترها، محدودیت های اندازه مبتنی بر مکان نما.

9) قابلیت مشاهده و عملکرد

Метрики: 'l7 _ req _ total {route, method, code}', 'latency _ ms {p50, p95, p99}', 'upstream _ errors', 'retry _ count', 'cb _ state', '429 _ rate', 'quota _ usage {tenant}'.
سیاهههای مربوط: ساختاری، با 'trace _ id/span _ id'، 'user _ id/tenant _ id'، 'client _ ip'.
ردیابی: زمینه ردیابی W3C ('traceparent'، 'tracestate')، به بالادست گسترش می یابد.
حسابرسی: چه کسی باعث چه چیزی، با چه حقوقی ؛ فروشگاه های غیر قابل تغییر برای API های حساس.
SLO/SLA: هدف P99، بودجه خطا ؛ سطح ریشه بهتر از سطح جهانی است.

10) مدیریت ظرفیت برنامه

سهمیه در هر مستاجر/کلید/استخر مشتری، در دقیقه/ساعت/روز.
پشت سر هم + محدودیت های پایدار ؛ سطل نشتی برای صاف کردن.
عدالت: هنگامی که بیش از حد بارگذاری می شود - صف بندی عادلانه به جای «اولین برخورد».
اولویت ها: مسیرهای سیستم/بحرانی با اولویت و استخرهای اختصاصی.

11) تغییر مدیریت و انتشار

قناری/آبی سبز: مسیریابی وزن ؛ پیشرفت خودکار در SLO (خطاها/تاخیر).
دروازه ویژگی/پرچم باطن: فعال کردن توسط هدر/نشانه.
اعتبار سنج سایه/تفاوت: مقایسه بدن/وضعیت، تحمل دلتا.
Staging: دامنه ها/مسیرهای اختصاص داده شده ('staging. API... ')، کلید های فردی و سهمیه.

12) نمونه های پیکربندی

12. 1 NGINX - محدودیت پایه و دروازه کش

nginx map $http_x_request_id $reqid { default $request_id; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
listen 443 ssl http2;
server_name api. example. com;

security add_header Strict-Transport-Security "max-age = 31536000" always;

location /v1/ {
limit_req zone=perip burst=30 nodelay;
proxy_set_header X-Request-ID $reqid;
proxy_set_header Authorization $http_authorization;
proxy_connect_timeout 1s;
proxy_read_timeout 5s;

proxy_cache api_cache;
proxy_cache_valid 200 10s;
proxy_cache_use_stale error timeout updating;
proxy_pass http://orders-v1;
}
}

12. 2 نماینده - تعادل و مسیریابی مجدد

yaml routes:
- match: { prefix: "/orders" }
route:
weighted_clusters:
clusters:
- name: orders-v1 weight: 90
- name: orders-v2 weight: 10 retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 2 per_try_timeout: 2s

12. 3 Traefik - میان افزار و هدر

yaml http:
middlewares:
secHeaders:
headers:
stsSeconds: 31536000 contentTypeNosniff: true routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1`)"
service: svc-orders middlewares: ["secHeaders"]

13) ضد الگوهای

یک محدودیت جهانی برای همه - «همسایگان خوب» به دلیل «پر سر و صدا» رنج می برند.
Retrays without idempotency → اثرات تکراری (پرداخت, ایجاد اشخاص).
نادیده گرفتن «اتمام وقت »/« حداکثر اندازه بدن» → آویزان/اگزوز کارگران.
مخلوط کردن سیاست های لبه و منطق کسب و کار در دروازه (وزن محیط).
عدم اعتبار طرح → شکنندگی مشتریان و «شکستن» منتشر شده است.
WebSocket برهنه به استثنای auth/limits/idle-time.

اسرار در سرفصل بدون چرخش ؛ عدم وجود mTLS در B2Bs داخلی

14) دفترچه های تست (روزهای بازی)

طوفان درخواست ها: محدود کننده/سهمیه بندی، رفتار 429، تخریب را بررسی کنید.

از دست دادن یک خوشه: توزیع مجدد شکست/وزن ؛ قناری های SLO

پاسخ های وزن: حداکثر بدن/زمان بندی ؛ قطع کردن مفاصل.
تزریق/ناهنجاری: قوانین WAF، مهار JSON بازگشتی، عمق GraphQL بزرگ.
ردیابی نتوانست انتشار و نمونه برداری «traceparent» را بررسی کند.
اسرار: چرخش کلید/JWKS، انقضای توکن، تحمل ساعت.

15) چک لیست پیاده سازی

• دامنه ها/مسیرها/نسخه های تعریف شده، OpenAPI/Proto منتشر شده است.
• TLS/mTLS، HSTS، مدیریت مخفی و چرخش پیکربندی شده اند.
• احراز هویت (OIDC/HMAC)، RBAC/حوزه، CORS را فعال کنید.
• محدودیت/سهمیه هر مستاجر، صف عادلانه، 429-UX.
• مسیریابی وزن/هدر، برنامه قناری و برگشت.
• سیاست های timeout/retry/circuit-breaker/outlier.
• اعتبار سنجی طرح، تحولات، ماسک PII.
• Edge- кеш/ETag، coalescing، gzip/br.
• قابلیت مشاهده: معیارها، گزارش ها، آهنگ ها، داشبورد ها و هشدارها.
• کتابهای اجرا: حوادث، چرخش کلیدی، لیست بلوک، جمعه سیاه.

16) سوالات متداول

س: دروازه API چگونه از مش سرویس متفاوت است ؟

A: دروازه - شمال-جنوب (محیط بیرونی، سیاست های پایان دادن به پایان). مش - شرق به غرب (اتصال داخل خوشه/MTLS/retrai). اغلب با هم استفاده می شود.

س: از کجا پیاده سازی auth: در دروازه یا خدمات ؟

A: هر دو سطح: دروازه - درشت دانه (احراز هویت، حقوق اساسی/سهمیه)، خدمات - ریز دانه (نقش دامنه/ویژگی).

س: چه زمانی رمزگذاری gRPC-JSON مورد نیاز است ؟

A: هنگامی که gRPC داخلی و خارج نیاز به REST/JSON و مشتریان/مرورگرهای ساده دارد.

س: چگونه یک استراتژی نسخه را انتخاب کنیم ؟

A: برای API های عمومی - مسیر '/vN '+ هدر محرومیت و همپوشانی طولانی. برای پرچم های داخلی/طرح سازگاری.

17) مجموع

دروازه API فقط یک پروکسی نیست، بلکه مرکز سیاست ها و انعطاف پذیری است. مسیریابی مناسب، امنیت، محدودیت ها، اعتبار سنجی و قابلیت مشاهده، قابلیت پیش بینی و سرعت انتشار را فراهم می کند. ترکیب دروازه لبه با مش سرویس، قناری خودکار و سهمیه بندی، شکست تست - و محیط تبدیل خواهد شد شتاب دهنده خود را، نه یک تنگنا.