تحديد المعدل العام مقابل الخاص بكل خدمة
افهم الاختلافات والتفاعل بين حدود المعدل العامة المطبّقة عند الحافة والحدود المحددة لكل خدمة مصغّرة
تحديد المعدل العام مقابل الخاص بكل خدمة درس مجاني في API Rate Limiting & Scalability Patterns على CoddyKit. هذا هو الدرس 2 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في API Rate Limiting & Scalability Patterns، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة API Rate Limiting & Scalability Patterns 4 دروس في المجموع.
بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.
Global vs. Per-Service Limits
APIs often handle diverse traffic, from general users to specific internal systems. To manage this, we need different rate limiting strategies.
Today, we'll explore two key approaches: global rate limiting and per-service rate limiting. Understanding their differences helps build robust and fair APIs.
Guarding the Gates Globally
Global rate limiting is applied at the very edge of your system, before requests even reach individual services. Think of it as a bouncer at the club entrance.
- It protects your entire infrastructure.
- Often implemented in API Gateways, load balancers, or edge proxies.
- Focuses on overall request volume to prevent system overload or DDoS attacks.
Global Limit Configuration
Here's a simplified example of how a global rate limit might be configured in an API Gateway like Nginx. It limits requests across all endpoints.
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
location / {
limit_req zone=mylimit burst=20 nodelay;
proxy_pass http://backend_services;
}
}
}Why Global Limits Matter
Implementing global rate limits offers several advantages:
- DDoS Protection: Blocks malicious traffic before it impacts your services.
- Overall Stability: Ensures your entire system isn't overwhelmed by sudden traffic spikes.
- Centralized Control: Easy to manage and modify limits for the whole API landscape.
- Resource Efficiency: Less work for individual services to do for basic filtering.
Fine-Grained Service Control
Per-service rate limiting happens inside a specific microservice. It's like individual rules for different rooms within the club.
- It applies to particular endpoints or operations within that service.
- Implemented directly in the service's code or via a sidecar proxy.
- Focuses on protecting specific service resources and enforcing business logic.
Per-Service Limit Code
Here's a tiny Java example illustrating a basic per-service rate limit for a specific endpoint. This uses a simple in-memory counter for demonstration.
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;
import java.time.Instant;
public class Main {
private static final int MAX_REQUESTS_PER_MINUTE = 3;
private static final long WINDOW_MILLIS = 60 * 1000; // 1 minute
private static ConcurrentHashMap<String, Long> lastResetTime =
new ConcurrentHashMap<>();
private static ConcurrentHashMap<String, AtomicInteger> requestCounts =
new ConcurrentHashMap<>();
public static boolean allowRequest(String userId) {
long currentTime = Instant.now().toEpochMilli();
lastResetTime.computeIfAbsent(userId, k -> currentTime);
requestCounts.computeIfAbsent(userId, k -> new AtomicInteger(0));
// Reset if window passed
if (currentTime - lastResetTime.get(userId) > WINDOW_MILLIS) {
lastResetTime.put(userId, currentTime);
requestCounts.get(userId).set(0);
}
if (requestCounts.get(userId).get() < MAX_REQUESTS_PER_MINUTE) {
requestCounts.get(userId).incrementAndGet();
return true;
}
return false;
}
public static void main(String[] args) {
String userA = "user123";
System.out.println("User A requests:");
for (int i = 0; i < 5; i++) {
System.out.println("Request " + (i + 1) + ": " +
(allowRequest(userA) ? "Allowed" : "Denied"));
}
System.out.println("\nUser B requests:");
String userB = "user456";
for (int i = 0; i < 2; i++) {
System.out.println("Request " + (i + 1) + ": " +
(allowRequest(userB) ? "Allowed" : "Denied"));
}
}
}Why Per-Service Limits are Key
Per-service rate limits provide more granular control:
- Resource Protection: Prevents one endpoint from exhausting a service's specific resources (e.g., database connections).
- Business Logic: Enforces limits based on specific user tiers or API functionality (e.g., "premium users get 1000 calls/min to this endpoint").
- Isolation: A limit breach in one service doesn't necessarily bring down others.
Working Together: Layered Defense
The most robust systems use both global and per-service rate limits. They act as a layered defense:
- Global limits: Act as a first line of defense, filtering out bulk traffic and protecting the entire system's entry point.
- Per-service limits: Provide fine-tuned control within individual services, protecting specific resources and enforcing business rules.
Think of it as multiple checkpoints, each with a different purpose.
When to Use Which?
When designing your rate limiting strategy, consider:
- Global: Best for broad protection, anonymous traffic, and preventing DDoS. Easy to implement at the infrastructure level.
- Per-service: Ideal for protecting specific backend resources, enforcing user-specific quotas, or handling authenticated traffic with distinct access levels. Requires more application-level logic.
Often, a combination is the best approach.
Test Your Knowledge
Consider an API with a global rate limit of 1000 requests/second and a specific microservice endpoint that has a per-user limit of 10 requests/minute. A user makes 50 requests in 30 seconds to this specific endpoint.
Global vs. Per-Service Recap
We've explored the critical differences and synergy between global and per-service rate limiting:
- Global limits: Act at the system's edge, protecting overall infrastructure from high-volume attacks.
- Per-service limits: Provide fine-grained control within microservices, protecting specific resources and enforcing business rules.
Combining both strategies creates a robust, multi-layered defense for your APIs. Next, we'll dive into handling rate limit exceedance gracefully.
تعلم API Rate Limiting & Scalability Patterns مع معلم ذكاء اصطناعي — مجانًا
اكتب وقم بتشغيل أكوادك الفعلية في المتصفح، واحصل على مساعدة فورية من معلم ذكاء اصطناعي متاح 24/7، واستمر من حيث توقفت على الويب أو في التطبيق.
- الدورات
- 12
- الدروس
- 48
الأسئلة الشائعة
هل درس «تحديد المعدل العام مقابل الخاص بكل خدمة» مجاني؟
نعم — نص درس «تحديد المعدل العام مقابل الخاص بكل خدمة» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة API Rate Limiting & Scalability Patterns، انتقل إلى CoddyKit PRO. تتضمن دورة API Rate Limiting & Scalability Patterns 4 دروس في المجموع.
ماذا ستتعلم في «تحديد المعدل العام مقابل الخاص بكل خدمة»؟
افهم الاختلافات والتفاعل بين حدود المعدل العامة المطبّقة عند الحافة والحدود المحددة لكل خدمة مصغّرة تتمرن على API Rate Limiting & Scalability Patterns مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ API Rate Limiting & Scalability Patterns؟
لا تُشترط خبرة سابقة. API Rate Limiting & Scalability Patterns على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 2 من أصل 4.
كم من الوقت يستغرق درس «تحديد المعدل العام مقابل الخاص بكل خدمة»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس API Rate Limiting & Scalability Patterns هذا؟
نعم. كل درس في API Rate Limiting & Scalability Patterns يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- أنماط التكامل مع بوابات API
- تحديد المعدل العام مقابل الخاص بكل خدمة
- الضبط الديناميكي لمعدل الطلبات
- تحديد المعدل الموزع باستخدام Redis