微服务故障或无响应时，如何保障应用整体可用性？

Great question—resilience is the backbone of any reliable microservices architecture, and handling these failure scenarios is non-negotiable. Let’s break down actionable strategies for each case you’ve outlined:

• Health Checks + Automated Recovery: Use your deployment platform’s built-in probe mechanisms (like Kubernetes’ liveness and readiness probes) to detect unresponsive instances. If a service crashes, the platform will automatically restart it, and readiness probes ensure traffic doesn’t get routed to instances that aren’t fully initialized. Here’s a quick Kubernetes probe example:

  livenessProbe:
    httpGet:
      path: /health/live
      port: 8080
    initialDelaySeconds: 10
    periodSeconds: 5
  readinessProbe:
    httpGet:
      path: /health/ready
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 3
  

• Redundant Deployments: Always run multiple instances of each microservice. A single instance crashing won’t take down the entire service—your load balancer will just route traffic to the remaining healthy instances.
• Graceful Degradation: Define fallback behaviors for critical dependencies. If a core service is down, return cached static data, a simplified response, or a user-friendly message instead of letting the entire request fail.

• Circuit Breaker Pattern: This is your first line of defense against cascading failures. Tools like Resilience4j or Hystrix monitor failure rates for service calls; once a threshold is hit (say, 50% failures in 10 seconds), the "circuit" opens, and all subsequent calls are redirected to a fallback. Here’s a simplified Resilience4j example in Java:

  CircuitBreakerConfig circuitConfig = CircuitBreakerConfig.custom()
    .failureRateThreshold(50)
    .waitDurationInOpenState(Duration.ofSeconds(15))
    .build();
  CircuitBreaker circuitBreaker = CircuitBreaker.of("payment-service", circuitConfig);
  
  // Fallback logic if the service is down
  Supplier<String> fallback = () -> "Payment processing temporarily unavailable. Please try again later.";
  String paymentResult = circuitBreaker.executeSupplier(() -> callPaymentService(), fallback);
  

• Idempotent Retries: For transient errors (like network blips or timeouts), implement retry logic—but only if your service calls are idempotent (repeat calls don’t cause unintended side effects, like double-charging a user). Use exponential backoff to avoid overwhelming the service. Example with Spring Retry:

  @Retryable(
    value = {ConnectException.class, SocketTimeoutException.class},
    maxAttempts = 3,
    backoff = @Backoff(delay = 1000, multiplier = 2) // 1s, 2s, 4s delays
  )
  public String callInventoryService() {
    // Logic to call inventory microservice
  }
  

• Strict Timeouts: Never let service calls hang indefinitely. Set tight timeout values for every outbound call to prevent your service’s thread pool from getting blocked by unresponsive dependencies.

• Rate Limiting: Use algorithms like token bucket or leaky bucket to cap the number of requests a service can handle per second. Tools like Resilience4j’s RateLimiter or Envoy’s rate limiting filters will reject or queue excess requests before they overwhelm the service.
• Auto-Scaling + Load Balancing: Pair a load balancer (like Nginx or Kubernetes Services) with auto-scaling rules. Configure your platform to spin up additional instances when CPU/memory usage hits a threshold, or when request counts spike. This spreads traffic across more resources to prevent overload.
• Queue-Based Load Leveling: Offload bursty traffic to a message queue (like RabbitMQ or Kafka). Instead of hitting the service directly, requests are buffered in the queue, and the service processes them at a steady pace. This prevents sudden traffic spikes from crashing the service.

• Distributed Tracing: Implement tools like Jaeger or OpenTelemetry to track request flows across services. This makes it easy to pinpoint exactly where a failure is happening when things go wrong.
• Strategic Caching: Cache frequently accessed data (like product catalogs or user profiles) at the edge or in a dedicated cache layer. This reduces the load on downstream services and provides a fallback if those services go down.
• Chaos Engineering: Proactively test your resilience by intentionally injecting failures (like killing a service or blocking network traffic). Tools like Chaos Monkey help you validate that your safeguards work as expected before a real outage happens.

内容的提问来源于stack exchange，提问作者Anuj Kumar Singh