Pengendalian Ralat Lanjutan dalam Spring Boot Microservices

Dalam perkhidmatan mikro yang kompleks, pengendalian ralat lanjutan melangkaui pengelogan pengecualian mudah. Pengendalian ralat yang berkesan adalah penting untuk kebolehpercayaan, skalabiliti dan mengekalkan pengalaman pengguna yang baik. Artikel ini akan merangkumi teknik lanjutan untuk pengendalian ralat dalam perkhidmatan mikro Spring Boot, memfokuskan pada strategi untuk mengurus ralat dalam sistem yang diedarkan, mengendalikan percubaan semula, mencipta respons ralat tersuai dan ralat pengelogan dengan cara yang memudahkan penyahpepijatan.

1. Pengendalian Ralat Asas dalam But Spring

Mari mulakan dengan pendekatan pengendalian ralat asas dalam Spring Boot untuk menyediakan garis dasar.

1.1 Menggunakan @ControllerAdvice dan @ExceptionHandler

Spring Boot menyediakan pengendali pengecualian global dengan @ControllerAdvice dan @ExceptionHandler. Persediaan ini membolehkan kami mengendalikan pengecualian merentas semua pengawal di satu tempat.

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleResourceNotFound(ResourceNotFoundException ex) {
        ErrorResponse error = new ErrorResponse("NOT_FOUND", ex.getMessage());
        return new ResponseEntity<>(error, HttpStatus.NOT_FOUND);
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleGeneralException(Exception ex) {
        ErrorResponse error = new ErrorResponse("INTERNAL_SERVER_ERROR", "An unexpected error occurred.");
        return new ResponseEntity<>(error, HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

Di sini, ErrorResponse ialah model ralat tersuai:

public class ErrorResponse {
    private String code;
    private String message;

    // Constructors, Getters, and Setters
}

1.2 Mengembalikan Respons Ralat Konsisten

Memastikan semua pengecualian mengembalikan format respons ralat yang konsisten (cth., ErrorResponse) membantu pelanggan mentafsir ralat dengan betul.

2. Teknik Lanjutan untuk Pengendalian Ralat

2.1 Pengelogan dan Penjejakan Berpusat dengan ID Ralat

Menetapkan ID ralat unik kepada setiap pengecualian membantu menjejaki ralat tertentu merentas perkhidmatan. ID ini juga boleh dilog bersama butiran pengecualian untuk penyahpepijatan yang lebih mudah.

@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleGeneralException(Exception ex) {
    String errorId = UUID.randomUUID().toString();
    log.error("Error ID: {}, Message: {}", errorId, ex.getMessage(), ex);

    ErrorResponse error = new ErrorResponse("INTERNAL_SERVER_ERROR", 
                                             "An unexpected error occurred. Reference ID: " + errorId);
    return new ResponseEntity<>(error, HttpStatus.INTERNAL_SERVER_ERROR);
}

Pelanggan menerima respons ralat yang mengandungi errorId, yang boleh mereka laporkan kembali kepada sokongan, memautkan mereka terus ke log terperinci.

2.2 Menambah Logik Cuba Semula untuk Ralat Sementara

Dalam sistem teragih, isu sementara (seperti tamat masa rangkaian) boleh diselesaikan dengan percubaan semula. Gunakan @Retryable Spring untuk mencuba semula logik pada kaedah perkhidmatan.

Persediaan

Mula-mula, tambahkan kebergantungan Spring Retry dalam pom.xml anda:

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>

Kemudian, dayakan Spring Retry dengan @EnableRetry dan anotasi kaedah yang memerlukan percubaan semula.

@EnableRetry
@Service
public class ExternalService {

    @Retryable(
        value = { ResourceAccessException.class },
        maxAttempts = 3,
        backoff = @Backoff(delay = 2000))
    public String callExternalService() throws ResourceAccessException {
        // Code that calls an external service
    }

    @Recover
    public String recover(ResourceAccessException e) {
        log.error("External service call failed after retries.", e);
        return "Fallback response due to error.";
    }
}

Konfigurasi ini mencuba semula kaedah sehingga 3 kali, dengan kelewatan selama 2 saat antara percubaan. Jika semua percubaan gagal, kaedah pulihkan dilaksanakan sebagai sandaran.

2.3 Menggunakan Feign Client dengan Fallback dalam Microservices

Untuk pengendalian ralat dalam panggilan perkhidmatan-ke-perkhidmatan, Feign menyediakan cara deklaratif untuk menyediakan percubaan semula dan sandaran.

Konfigurasi Berpura-pura

Tentukan klien Feign dengan sokongan sandaran:

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleResourceNotFound(ResourceNotFoundException ex) {
        ErrorResponse error = new ErrorResponse("NOT_FOUND", ex.getMessage());
        return new ResponseEntity<>(error, HttpStatus.NOT_FOUND);
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleGeneralException(Exception ex) {
        ErrorResponse error = new ErrorResponse("INTERNAL_SERVER_ERROR", "An unexpected error occurred.");
        return new ResponseEntity<>(error, HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

Pendekatan ini memastikan bahawa jika perkhidmatan inventori tidak tersedia, InventoryServiceFallback bermula dengan respons yang telah ditetapkan.

3. Ralat Pembalakan dan Kebolehlihatan

3.1 Pembalakan Berpusat dengan Tindanan ELK

Konfigurasikan tindanan ELK (Elasticsearch, Logstash, Kibana) untuk menyatukan log daripada berbilang perkhidmatan mikro. Dengan sistem pengelogan berpusat, anda boleh mengesan isu merentas perkhidmatan dan melihat log dengan ID ralat yang berkaitan dengan mudah.

Contohnya, konfigurasikan corak log dalam application.yml:

public class ErrorResponse {
    private String code;
    private String message;

    // Constructors, Getters, and Setters
}

3.2 Menambah ID Surih dengan Spring Cloud Sleuth

Dalam sistem yang diedarkan, mengesan satu transaksi merentasi pelbagai perkhidmatan adalah penting. Spring Cloud Sleuth menyediakan pengesanan teragih dengan jejak unik dan ID span.

Tambah Spring Cloud Sleuth dalam kebergantungan anda:

@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleGeneralException(Exception ex) {
    String errorId = UUID.randomUUID().toString();
    log.error("Error ID: {}, Message: {}", errorId, ex.getMessage(), ex);

    ErrorResponse error = new ErrorResponse("INTERNAL_SERVER_ERROR", 
                                             "An unexpected error occurred. Reference ID: " + errorId);
    return new ResponseEntity<>(error, HttpStatus.INTERNAL_SERVER_ERROR);
}

4. Pengendalian Ralat Tersuai untuk REST API

4.1 Mencipta Kelas Pengecualian Tersuai

Tentukan pengecualian tersuai untuk menyediakan pengendalian ralat yang lebih khusus.

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>

4.2 Struktur Respons Ralat Tersuai

Sesuaikan respons ralat dengan melaksanakan ErrorAttributes untuk mesej ralat berstruktur dan diperkaya.

@EnableRetry
@Service
public class ExternalService {

    @Retryable(
        value = { ResourceAccessException.class },
        maxAttempts = 3,
        backoff = @Backoff(delay = 2000))
    public String callExternalService() throws ResourceAccessException {
        // Code that calls an external service
    }

    @Recover
    public String recover(ResourceAccessException e) {
        log.error("External service call failed after retries.", e);
        return "Fallback response due to error.";
    }
}

Daftar CustomErrorAttributes dalam konfigurasi anda untuk menyesuaikan semua respons ralat secara automatik.

Piawaian Respons Ralat API 4.3 dengan Butiran Masalah (RFC 7807)

Gunakan format Butiran Masalah untuk struktur ralat API piawai. Tentukan model tindak balas ralat berdasarkan RFC 7807:

@FeignClient(name = "inventory-service", fallback = InventoryServiceFallback.class)
public interface InventoryServiceClient {
    @GetMapping("/api/inventory/{id}")
    InventoryResponse getInventory(@PathVariable("id") Long id);
}

@Component
public class InventoryServiceFallback implements InventoryServiceClient {

    @Override
    public InventoryResponse getInventory(Long id) {
        // Fallback logic, like returning cached data or an error response
        return new InventoryResponse(id, "N/A", "Fallback inventory");
    }
}

Kemudian, kembalikan respons berstruktur ini daripada kaedah @ControllerAdvice untuk mengekalkan struktur ralat yang konsisten merentas semua API.

logging:
  pattern:
    console: "%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n"

5. Pemutus Litar untuk Ketahanan

Menyepadukan corak pemutus litar melindungi perkhidmatan mikro anda daripada memanggil perkhidmatan yang gagal berulang kali.

Menggunakan Pemutus Litar Resilience4j
Tambahkan Resilience4j pada kebergantungan anda:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

Kemudian, balut kaedah dengan pemutus litar:

public class InvalidRequestException extends RuntimeException {
    public InvalidRequestException(String message) {
        super(message);
    }
}

Persediaan ini berhenti memanggil getInventory jika gagal beberapa kali dan sebaliknya inventoryFallback mengembalikan respons yang selamat.

Kesimpulan

Pengendalian ralat lanjutan dalam perkhidmatan mikro Spring Boot termasuk:

Pengendalian ralat terpusat untuk respons yang konsisten dan penyahpepijatan yang dipermudahkan.
Cuba semula dan pemutus litar untuk panggilan perkhidmatan ke perkhidmatan yang berdaya tahan.
Pengelogan berpusat dan kebolehkesanan dengan alatan seperti ELK dan Sleuth.
Format ralat tersuai dengan Butiran Masalah dan respons ralat berstruktur.
Teknik ini membantu memastikan perkhidmatan mikro anda teguh, memberikan respons ralat yang konsisten dan boleh dikesan sambil menghalang kegagalan melata merentas perkhidmatan.

Atas ialah kandungan terperinci Pengendalian Ralat Lanjutan dalam Spring Boot Microservices. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!