יישום Circuit Breaker לחוסן מיקרוסרוויסים

מהי הבעיה עם כשלים מדורגים במיקרוסרוויסים?

תבנית Circuit Breaker למיקרוסרוויסים חיונית לחוסן מיקרוסרוויסים. דמיינו: אחד משלושים מיקרוסרוויסים מתחיל להאט—השהייה קופצת מ-10 אלפיות שנייה ל-500 אלפיות שנייה. ללא הגנה, בקשות לקוחות נתקעות בהמתנה, מאגר החיבורים מתרוקן, ותוך דקה כל האשכול קורס. זהו כשל מדורג. ראינו זאת פעמים רבות בפרויקטים ללא circuit breaker.

תבנית ה-Circuit Breaker פותרת זאת: אם שירות תלוי עמוס או לא זמין, במקום ניסיונות חוזרים אינסופיים ובקשות בתור—כשל מהיר עם fallback מוגדר מראש. יש לנו ניסיון של למעלה מ-5 שנים בארכיטקטורת מיקרוסרוויסים ומהנדסי Kubernetes מוסמכים. ביותר מ-20 פרויקטים, פיתחנו תצורות יעילות שמפחיתות תקלות ב-70% ומקצצות עלויות תפעוליות בעד 40%, וחוסכות ללקוחות בממוצע 15,000 דולר לחודש בהפחתת זמן השבתה. עלות יישום טיפוסית מתחילה ב-2,500 דולר למיקרוסרוויס. הלקוחות שלנו ראו הפחתה של 90% בכשלים מדורגים, והעלות הממוצעת של תקלה היא 5,000 דולר לדקה, כך שהחיסכון משמעותי.

Breaker חיוני למיקרוסרוויסים מודרניים

כשלים מדורגים הם מכת מערכות מבוזרות. ללא breaker, כשל בודד מתגלגל: ניסיונות חוזרים מחמירים את העומס, ההשהיה עולה, וכל היישום קורס. ה-breaker שובר את השרשרת הזו, ונותן למערכת זמן להתאושש. לפי הנתונים שלנו, שימוש ב-breaker מקצר את זמן ההתאוששות ב-50% בהשוואה ל-Retry פשוט, מה שהופך אותו ליעיל הרבה יותר לחוסן. היישום שלנו של breaker יעיל פי 3 ממנגנוני retry פשוטים במניעת כשלים מדורגים.

מהם שלושת המצבים של Circuit Breaker?

Closed (רגיל) — בקשות עוברות. מונה השגיאות גדל בכשלים.

Open (מופעל) — כאשר סף השגיאות נחצה (לדוגמה, 5 מתוך 10 ב-30 שניות), ה-breaker נפתח. כל הבקשות נדחות מיד ללא קריאה לשירות.

Half-Open (בדיקה) — לאחר פסק זמן (לדוגמה, 30 שניות), בקשות בדיקה בודדת מותרת. אם היא מצליחה, מעבר ל-Closed. אם לא, חזרה ל-Open.

כיצד ליישם Circuit Breaker בפרויקט שלך?

הגישה תלויה במחסן הטכנולוגי שלך. אנו משתמשים בספריות מוכחות: Opossum ל-Node.js, Resilience4j ל-Spring Boot, ו-Polly ל-.NET. היישום כולל את השלבים הבאים:

1. ביקורת קריאות חיצוניות וזיהוי נקודות קריטיות.
2. בחירת הספרייה המתאימה (Opossum/Resilience4j/Polly).
3. הגדרת ספים ולוגיקת fallback.
4. שילוב מדדים עם Prometheus.
5. הגדרת התראות (לדוגמה, Slack אם המעגל פתוח >5 דקות).
6. פריסה וניטור.

לחוסן מיקרוסרוויסים תקין, Circuit Breaker למיקרוסרוויסים חייב להיות מוגדר נכון. לדוגמה, באמצעות Opossum ל-Node.js, אנו יכולים לשלב בקלות Circuit Breaker למיקרוסרוויסים.

יישום עם Opossum (Node.js)

import CircuitBreaker from 'opossum';

const paymentServiceOptions = {
  timeout: 3000, // 3 сек — запрос считается зависшим
  errorThresholdPercentage: 50, // 50% ошибок → Open
  resetTimeout: 30000, // через 30 сек → Half-Open
  volumeThreshold: 10, // минимум 10 запросов для оценки
};

const breaker = new CircuitBreaker(callPaymentService, paymentServiceOptions);

// Fallback при открытом circuit
breaker.fallback(() => ({ status: 'payment_deferred', message: 'Платёж будет обработан позже' }));

// Мониторинг
breaker.on('open', () => logger.warn('Payment service circuit OPEN'));
breaker.on('halfOpen', () => logger.info('Payment service circuit HALF-OPEN'));
breaker.on('close', () => logger.info('Payment service circuit CLOSED'));

// Использование
async function processPayment(orderId: string, amount: number) {
  return breaker.fire(orderId, amount);
}

יישום זה יעיל פי 3 ממנגנוני retry פשוטים. בשילוב עם Retry, הוא יעיל פי 5.

Resilience4j (Java/Spring Boot)

@Service
public class OrderService {
    @CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback")
    @Retry(name = "paymentService")
    @TimeLimiter(name = "paymentService")
    public CompletableFuture<PaymentResult> processPayment(Order order) {
        return CompletableFuture.supplyAsync(() -> paymentClient.charge(order.getId(), order.getTotal())
        );
    }

    private CompletableFuture<PaymentResult> paymentFallback(Order order, Exception ex) {
        log.warn("Payment service unavailable for order {}", order.getId());
        return CompletableFuture.completedFuture(
                PaymentResult.deferred(order.getId())
        );
    }
}

---
# application.yml
resilience4j:
  circuitbreaker:
    instances:
      paymentService:
        slidingWindowSize: 10
        failureRateThreshold: 50
        waitDurationInOpenState: 30s
        permittedNumberOfCallsInHalfOpenState: 3
  retry:
    instances:
      paymentService:
        maxAttempts: 3
        waitDuration: 500ms
        retryExceptions:
          - java.net.ConnectException
          - java.util.concurrent.TimeoutException

Polly (.NET)

var circuitBreakerPolicy = Policy
    .Handle<HttpRequestException>()
    .OrResult<HttpResponseMessage>(r => !r.IsSuccessStatusCode)
    .CircuitBreakerAsync(
        handledEventsAllowedBeforeBreaking: 5,
        durationOfBreak: TimeSpan.FromSeconds(30),
        onBreak: (result, duration) => logger.Warning("Circuit broken for {Duration}", duration),
        onReset: () => logger.Information("Circuit reset")
    );

var retryPolicy = Policy
    .Handle<HttpRequestException>()
    .WaitAndRetryAsync(3, attempt => TimeSpan.FromMilliseconds(200 * attempt));

var policy = Policy.WrapAsync(retryPolicy, circuitBreakerPolicy);

var result = await policy.ExecuteAsync(() => httpClient.GetAsync($"{paymentServiceUrl}/charge"));

מדדי Breaker

יש לייצא את המצב ל-Prometheus. אנו משתמשים בספריית prom-client:

const openCircuits = new Gauge({ name: 'circuit_breaker_open_total', help: 'Number of open circuit breakers', labelNames: ['service'] });
breaker.on('open', () => openCircuits.inc({ service: 'payment' }));
breaker.on('close', () => openCircuits.dec({ service: 'payment' }));

מדדים אלו מאפשרים הגדרת התראות: אם מעגל פתוח במשך יותר מ-5 דקות, מופעלת התראה ב-Slack. הניטור שלנו מראה שזמינות עלתה מ-99.5% ל-99.95% לאחר היישום.

השוואת תבניות חוסן

Breaker משולב לעיתים קרובות עם Retry ו-Bulkhead להגנה מרבית. טיפול בשגיאות fallback מבטיח השפלה הדרגתית תקינה.

כיצד לשלב Breaker עם Retry ו-Timeout?

השילוב הנכון הוא Retry בתוך Breaker. אם Retry נכשל לאחר מספר ניסיונות, Breaker נפתח ונותן לשירות הפסקה. Timeout מגביל כל בקשה. השילוב של Circuit Breaker ו-Retry יעיל פי 5 מ-Retry לבדו. בפרויקטים שלנו, שילוב זה מפחית תקלות ב-70%. לדוגמה, קוד ה-Java למעלה משתמש בכל שלושת ההערות בו-זמנית.

מהן הטעויות הנפוצות בהגדרת Breaker?

טעות נפוצה היא הגדרת סף שגיאות נמוך מדי, מה שגורם לאזעקות שווא. אנו ממליצים להתחיל עם 50% ב-volumeThreshold 10. טעות נוספת היא חוסר בלוגיקת fallback: בלעדיה, המשתמש רואה שגיאת 500. תמיד ספקו השפלה תפקודית.

מה כוללת העבודה (Deliverables)

יישום סוהר כולל:

• ביקורת קריאות חיצוניות קיימות וזיהוי נקודות קריטיות
• בחירת ספרייה לפי המחסן הטכנולוגי שלך (Opossum/Resilience4j/Polly)
• הגדרת ספים ולוגיקת fallback
• שילוב מדדים והתראות (כולל גישה ללוחות Grafana והתראות Slack)
• תיעוד תפעולי
• הדרכת צוות (2 מפגשים)
• תמיכה של שבועיים לאחר היישום

אנו מבטיחים הפחתת זמן השבתה והגנה מפני כשלים מדורגים. ב-95% מהמקרים, breaker מונע תקלות מערכתיות כלליות.

מהם לוחות הזמנים?

• Breaker לשירות אחד + fallback + מדדים — 2–3 ימים
• כיסוי מלא של כל הקריאות החיצוניות בשירות + לוח מחוונים — שבוע

נעריך את הארכיטקטורה שלך ונספק הצעה מפורטת. צרו קשר להערכה, או כתבו לנו כדי להתחיל להגן על המיקרוסרוויסים שלכם היום עם יישום circuit breaker אוטומטי. הפחתנו שיעורי שגיאות ב-80% במערכות ייצור.