การตรวจสอบสถานะและรูปแบบความทนทาน

In production, applications need to be robust. Health checks are automated ways to verify if an application or service is running correctly and ready to receive traffic.

• They tell orchestrators (like Kubernetes) if your app is alive.
• They prevent traffic from being sent to unhealthy instances.
• They help in automatic recovery and scaling decisions.

Spring Boot Actuator provides a built-in /actuator/health endpoint. By default, it aggregates health information from various components like databases, disk space, and more.

When accessed, it returns a status, typically UP or DOWN, along with details about included components.

To see the health status, you just need to enable Actuator and access the endpoint. Here's how you might configure it in application.properties:

Sometimes, the default health checks aren't enough. You might have an external API, a custom cache, or a specific business logic that needs monitoring.

You can create custom health indicators by implementing the HealthIndicator interface to add your own checks to the /actuator/health endpoint.

Let's create a simple custom health indicator for a hypothetical external service. If the service is 'available', it reports UP; otherwise, DOWN.

When deploying to container orchestrators like Kubernetes, two types of probes are crucial:

• Liveness Probe: Determines if an application instance is running. If it fails, Kubernetes restarts the container.
• Readiness Probe: Determines if an application instance is ready to serve traffic. If it fails, Kubernetes stops sending traffic to it.

Spring Boot 2.3+ introduced distinct health groups for these, often mapped to /actuator/health/liveness and /actuator/health/readiness.

Even with health checks, external dependencies can fail, causing your application to crash or slow down. Resilience patterns help your application gracefully handle failures and continue operating under adverse conditions.

• They improve fault tolerance and stability.
• They prevent cascading failures across services.
• They ensure a better user experience even when parts of the system are struggling.

The Circuit Breaker pattern prevents an application from repeatedly trying to execute an operation that is likely to fail. It's like an electrical circuit breaker: if too much current flows, it trips to prevent damage.

• CLOSED: Requests pass through. If failures exceed a threshold, it trips to OPEN.
• OPEN: Requests immediately fail (fast-fail). After a timeout, it transitions to HALF_OPEN.
• HALF_OPEN: A limited number of test requests are allowed. If they succeed, it closes; otherwise, it opens again.

Resilience4j is a popular library for implementing resilience patterns. Here's a simplified example of a circuit breaker protecting a slow method call.

When a circuit breaker is open or a service call fails, you don't always want to just throw an error. A fallback method provides an alternative response or action when the primary operation fails.

This allows your application to degrade gracefully, perhaps by returning cached data, a default response, or an empty list, instead of crashing or showing a full error page.

We've explored how health checks, particularly with Spring Boot Actuator and custom indicators, help monitor application status and readiness for traffic.

We also learned about resilience patterns, focusing on the Circuit Breaker, to prevent cascading failures and ensure graceful degradation when external services or components fail. Implementing these patterns is key for building robust, production-ready microservices.