דפוס החזרה: עיצוב השפלה חיננית בשירותי מיקרו

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

החזרת “שגיאת שרת פנימית 500” כללית או דף ריק למשתמשים ברגע שבו תלות בודדת נכשלת היא חווית משתמש גרועה. במקום זאת, מערכות גמישות בנויות להתקלקל בחן כאשר דברים משתבשים.

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

במדריך זה, נחקור את דפוס ה-fallback, אסטרטגיות נפוצות ליישומו, כיצד הוא מקיים אינטראקציה עם דפוסי חוסן אחרים, וכיצד לכתוב לוגיקה סתירה ב-Java (Resilience4j) ו-Go.

האנלוגיה של העולם האמיתי: תוכנית הגיבוי של בית הקפה

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

האם בית הקפה מכבה מיד את האורות, נועל את הדלתות ושולח את כל הלקוחות הביתה?

כמובן שלא. הם מיישמים אסטרטגיית סתירה:

• אם יש להם מזומן בהישג יד, הם שואלים אם אפשר לשלם במזומן.
• אם אתה לקוח קבוע, הבריסטה עשוי לרשום את שמך ואת ההזמנה שלך בספר החשבונות ולבקש ממך לשלם בביקור הבא שלך.
• הם עשויים להשתמש בקורא כרטיסים לא מקוון שמאחסן את אסימון הכרטיס באופן מקומי ומעבד את התשלום מאוחר יותר כשהאינטרנט יתאושש.

בעיצוב תוכנה:

• הזמנת הקפה היא בקשת הלקוח.
• מסוף הכרטיסים הוא השירות הראשי במורד הזרם (למשל, API של שער תשלום).
• הפסקת האינטרנט היא פסק זמן של רשת או קריסת שירות.
• The Ledger / Offline Reader הוא נתיב ביצוע החזרה.

אסטרטגיות נפילות נפוצות

בהתאם להיגיון העסקי ולקריטיות של השירות הכושל, אתה יכול לבחור מבין כמה אסטרטגיות ניצול:

1. ערכי ברירת מחדל סטטיים

האסטרטגיה הפשוטה ביותר היא להחזיר ערך סטטי בטוח ומוגדר מראש. זה יעיל מאוד עבור תכונות לא קריטיות שבהן הצגת נתונים ריקים או ברירת מחדל מקובלת.

• דוגמה: אם שירות התאמה אישית של פרופיל נכשל, החזר תמונת אווטאר ברירת מחדל וברכה כללית.
• דוגמה: אם שירות המלצות נכשל, החזר רשימה ריקה או רשימה מקודדת של רבי מכר אוניברסליים במקום לזרוק שגיאה.

2. תגובות מאוחסנות במטמון (Stale-While-Revalidate)

אם נתונים חיים אינם זמינים, אתה יכול לחזור לקריאה בלבד, נתונים מיושנים ממטמון מקומי או מחנות זיכרון מבוזרת מהירה כמו Redis.

• דוגמה: אם שירות מלאי מוצרים יורד, הצג את הכמות במלאי שנשמרה במטמון מלפני 5 דקות, יחד עם הודעת ממשק משתמש עדינה המציינת כי ייתכן שהנתונים אינם מעודכנים במלואם.
• דוגמה: אם שירות הגדרות משתמש נכשל, טען את פרופיל המשתמש המאוחסן במטמון במקום לחסום את זרימת הכניסה שלו.

3. שירות חלופי (רב ספקים)

בעת ביצוע פעולה קריטית שחייבת להצליח, ניתן להגדיר ספק שירות משני כגיבוי.

• דוגמה: אם שער התשלום הראשי שלך (למשל, Stripe) מחזיר שגיאה 5xx או פסק זמן, מנגנון החזרה מפנה מיד את בקשת העסקה לשער משני (לדוגמה, PayPal או Adyen).
• דוגמה: אם ממשק API של קידוד גיאוגרפי נכשל, חזור לספק מיפוי משני.

4. תור למועד מאוחר יותר (מאגר אסינכרוני)

עבור פעולות כתיבה שאינן דורשות עיבוד סינכרוני מיידי, ה-fallback יכול לאחסן את הבקשה בתור מקומי או במסד נתונים כדי לנסות שוב מאוחר יותר.

• דוגמה: אם שירות הודעות דוא"ל מושבת, כתוב את מטען ההודעות לתור של אותיות מתות או לטבלת מסד נתונים מקומית. עובד רקע יקרא מהתור הזה וישלח את האימיילים ברגע ששירות ההתראות יחזור להיות בריא.

שלישיית החוסן: ניסיון חוזר מול מפסק מעגלים מול נפילה

כדי לבנות ארכיטקטורה עמידה במיוחד, עליך לשלב את דפוס ה-Fallback עם דפוסי נסה שוב ומפסק מעגלים. הם יוצרים קו הגנה תלת-שכבתי:

איך הם עובדים ביחד

1. בקשה נכנסת פוגעת בשער השירות.
2. הבקשה עוברת דרך מפסק המעגלים.
3. אם מפסק המעגל סגור, הבקשה עוברת למעטפת נסה שוב, שמבצעת את השיחה בפועל.
4. אם מתרחשת שגיאה חולפת, מנגנון ניסיון חוזר מנסה שוב את השיחה.
5. אם כל הניסיונות החוזרים נכשלים, או אם מפסק המעגלים כבר היה פתוח (נכשל במהירות בחסכון במשאבים), מטפל החזרה מיירט את הכשל ומחזיר את התגובה השגויה/השמורה במטמון.

יישומי קוד

בואו נסתכל כיצד נוכל ליישם לוגיקה סתירה גם ב-Java וגם ב-Go.

1. Java (Resilience4j)

ב-Java, Resilience4j הוא תקן התעשייה לסובלנות תקלות. אנו יכולים להגדיר שיטת סתירה באופן הצהרתי באמצעות הערות או באופן פרוגרמטי.

import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import org.springframework.stereotype.Service;
import java.util.Collections;
import java.util.List;

@Service
public class ProductService {

    private final InventoryClient inventoryClient;
    private final CacheManager cacheManager;

    public ProductService(InventoryClient inventoryClient, CacheManager cacheManager) {
        this.inventoryClient = inventoryClient;
        this.cacheManager = cacheManager;
    }

    // Bind this method to a circuit breaker. If it fails or is open, route to fallback
    @CircuitBreaker(name = "inventoryService", fallbackMethod = "getInventoryFallback")
    public List<String> getProductInventory(String category) {
        return inventoryClient.fetchStockByCategory(category);
    }

    // Fallback method must have the same return type and accept the same parameters,
    // plus a Throwable parameter containing the error that triggered it
    public List<String> getInventoryFallback(String category, Throwable throwable) {
        System.err.println("Primary inventory service failed: " + throwable.getMessage());
        
        // Attempt to fetch from local cache (Strategy 2)
        List<String> cachedStock = cacheManager.get("inventory:" + category, List.class);
        if (cachedStock != null) {
            return cachedStock;
        }

        // Return static empty list if cache is empty (Strategy 1)
        return Collections.emptyList();
    }
}

2. עבור (גולאנג)

ב-Go, אנו יכולים לכתוב מעצבי סתירה נקיים באמצעות דפוסי תכנות פונקציונליים, המאפשרים לנו לעטוף כל מטפל ביצוע במטפל משני.

package main

import (
	"context"
	"errors"
	"fmt"
	"time"
)

// Request represents a simple payload
type Request struct {
	UserID string
}

// Response represents the returned data
type Response struct {
	Data   string
	Status string
}

// ServiceFunc represents our primary function signature
type ServiceFunc func(ctx context.Context, req Request) (Response, error)

// WithFallback wraps a service function with fallback logic
func WithFallback(primary ServiceFunc, fallback ServiceFunc) ServiceFunc {
	return func(ctx context.Context, req Request) (Response, error) {
		res, err := primary(ctx, req)
		if err != nil {
			fmt.Printf("[Warning] Primary call failed: %v. Running fallback...\n", err)
			return fallback(ctx, req)
		}
		return res, nil
	}
}

func main() {
	// 1. Define primary service that occasionally fails
	primaryService := func(ctx context.Context, req Request) (Response, error) {
		return Response{}, errors.New("database connection timeout (504)")
	}

	// 2. Define fallback service that retrieves cached data
	fallbackService := func(ctx context.Context, req Request) (Response, error) {
		// Simulating cached read
		return Response{
			Data:   fmt.Sprintf("Stale cached profile data for user %s", req.UserID),
			Status: "DEGRADED (CACHED)",
		}, nil
	}

	// 3. Wrap them together
	resilientService := WithFallback(primaryService, fallbackService)

	// 4. Execute
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancel()

	req := Request{UserID: "user_992"}
	response, err := resilientService(ctx, req)
	if err != nil {
		fmt.Printf("Operation completely failed: %v\n", err)
	} else {
		fmt.Printf("Response Received:\n - Status: %s\n - Data: %s\n", response.Status, response.Data)
	}
}

שיטות עבודה מומלצות עבור תבנית החזרה

1. שמור על תלות בנתיב ה-fallback-free: היגיון ה-fallback אינו יכול להסתמך על אותן מערכות או תשתית במורד הזרם שזה עתה נכשלו. אם מסד הנתונים שלך מושבת, נפילה חזרה לשאילתת מסד נתונים אחרת באותו שרת תיכשל גם כן.
2. הפעל מהר: היגיון נפילה צריך לפעול במהירות. הימנע מחישובים מורכבים או שיחות מקוננות איטיות בנתיבי החזרה שלך. המטרה היא להחזיר תגובה למשתמש במהירות האפשרית.
3. התראה וניטור: רשום תמיד ביצועים חוזרים והגדלת מוני טלמטריה. אם המערכת שלך מבצעת נתיבים חוזרים, זה אומר שהמערכת פועלת במצב פגום. אתה צריך התראות כדי לדעת מתי שיעורי החזרה חורגים מהסף הרגיל.
4. הפוך את ממשק המשתמש לחוסן: עבוד בשיתוף פעולה הדוק עם מהנדסי קצה כדי להבטיח שה-UI מתוכנן לקבל עומסים חוזרים (כמו אוספים ריקים או מצבים חלקיים) מבלי לשבור את הפריסה בצד הלקוח.

מסקנה

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