API 是現(xiàn)代應用程序的支柱。當我第一次開始使用 Spring Boot 構(gòu)建 API 時，我過于專注于提供功能，而忽略了一個關(guān)鍵方面：彈性。我經(jīng)歷了慘痛的教訓才明白，API 能夠優(yōu)雅地處理故障并適應不同條件的能力才是它真正可靠的原因。讓我向您介紹我一路上犯的一些錯誤以及我是如何糾正這些錯誤的。希望您能夠在自己的旅程中避免這些陷阱。

錯誤一：忽略超時配置

發(fā)生了什么：在我的一個早期項目中，我構(gòu)建了一個 API，可以對第三方服務進行外部調(diào)用。我認為這些服務總是會快速響應，并且不會費心設(shè)置超時。一切看起來都很好，直到流量增加，第三方服務開始變慢。我的 API 將無限期掛起，等待響應。

影響： API 的響應能力急劇下降。相關(guān)服務開始出現(xiàn)故障，用戶面臨長時間的延遲，有些甚至遇到了可怕的 500 內(nèi)部服務器錯誤。

我是如何修復它的：那時我意識到超時配置的重要性。以下是我使用 Spring Boot 修復該問題的方法：

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder
                .setConnectTimeout(Duration.ofSeconds(5))
                .setReadTimeout(Duration.ofSeconds(5))
                .additionalInterceptors(new RestTemplateLoggingInterceptor())
                .build();
    }

    // Custom interceptor to log request/response details
    @RequiredArgsConstructor
    public class RestTemplateLoggingInterceptor implements ClientHttpRequestInterceptor {
        private static final Logger log = LoggerFactory.getLogger(RestTemplateLoggingInterceptor.class);

        @Override
        public ClientHttpResponse intercept(HttpRequest request, byte[] body, 
                                          ClientHttpRequestExecution execution) throws IOException {
            long startTime = System.currentTimeMillis();
            log.info("Making request to: {}", request.getURI());

            ClientHttpResponse response = execution.execute(request, body);

            long duration = System.currentTimeMillis() - startTime;
            log.info("Request completed in {}ms with status: {}", 
                    duration, response.getStatusCode());

            return response;
        }
    }
}

此配置不僅設(shè)置適當?shù)某瑫r，還包括日志記錄以幫助監(jiān)控外部服務性能。

錯誤2：沒有實施斷路器

發(fā)生了什么：曾經(jīng)有一段時間，我們所依賴的內(nèi)部服務宕機了幾個小時。我的 API 沒有很好地處理這種情況。相反，它不斷重試那些失敗的請求，給已經(jīng)緊張的系統(tǒng)增加了更多的負載。

級聯(lián)故障是分布式系統(tǒng)中最具挑戰(zhàn)性的問題之一。當一項服務出現(xiàn)故障時，可能會產(chǎn)生多米諾骨牌效應，導致整個系統(tǒng)癱瘓。

影響：重復的重試使系統(tǒng)不堪重負，減慢了應用程序的其他部分并影響了所有用戶。

我是如何修復它的：就在那時我發(fā)現(xiàn)了斷路器模式。使用 Spring Cloud Resilience4j，我能夠打破這個循環(huán)。

@Configuration
public class Resilience4jConfig {

    @Bean
    public CircuitBreakerConfig circuitBreakerConfig() {
        return CircuitBreakerConfig.custom()
                .failureRateThreshold(50)
                .waitDurationInOpenState(Duration.ofSeconds(60))
                .permittedNumberOfCallsInHalfOpenState(2)
                .slidingWindowSize(2)
                .build();
    }

    @Bean
    public RetryConfig retryConfig() {
        return RetryConfig.custom()
                .maxAttempts(3)
                .waitDuration(Duration.ofSeconds(2))
                .build();
    }
}

@Service
@Slf4j
public class ResilientService {

    private final CircuitBreaker circuitBreaker;
    private final RestTemplate restTemplate;

    public ResilientService(CircuitBreakerRegistry registry, RestTemplate restTemplate) {
        this.circuitBreaker = registry.circuitBreaker("internalService");
        this.restTemplate = restTemplate;
    }

    @CircuitBreaker(name = "internalService", fallbackMethod = "fallbackResponse")
    @Retry(name = "internalService")
    public String callInternalService() {
        return restTemplate.getForObject("https://internal-service.com/data", String.class);
    }

    public String fallbackResponse(Exception ex) {
        log.warn("Circuit breaker activated, returning fallback response", ex);
        return new FallbackResponse("Service temporarily unavailable", 
                                  getBackupData()).toJson();
    }

    private Object getBackupData() {
        // Implement cache or default data strategy
        return new CachedDataService().getLatestValidData();
    }
}

這個簡單的添加可以防止我的 API 壓垮自身、內(nèi)部服務或第三方服務，確保系統(tǒng)穩(wěn)定性。

錯誤 3：錯誤處理能力弱

發(fā)生了什么： 早期，我沒有對錯誤處理投入太多考慮。我的 API 要么拋出一般錯誤（例如所有內(nèi)容的 HTTP 500），要么在堆棧跟蹤中暴露敏感的內(nèi)部詳細信息。

影響：用戶對出了什么問題感到困惑，內(nèi)部細節(jié)的暴露造成了潛在的安全風險。

我是如何修復它的：我決定使用 Spring 的 @ControllerAdvice 注釋來集中處理錯誤。這就是我所做的：

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder
                .setConnectTimeout(Duration.ofSeconds(5))
                .setReadTimeout(Duration.ofSeconds(5))
                .additionalInterceptors(new RestTemplateLoggingInterceptor())
                .build();
    }

    // Custom interceptor to log request/response details
    @RequiredArgsConstructor
    public class RestTemplateLoggingInterceptor implements ClientHttpRequestInterceptor {
        private static final Logger log = LoggerFactory.getLogger(RestTemplateLoggingInterceptor.class);

        @Override
        public ClientHttpResponse intercept(HttpRequest request, byte[] body, 
                                          ClientHttpRequestExecution execution) throws IOException {
            long startTime = System.currentTimeMillis();
            log.info("Making request to: {}", request.getURI());

            ClientHttpResponse response = execution.execute(request, body);

            long duration = System.currentTimeMillis() - startTime;
            log.info("Request completed in {}ms with status: {}", 
                    duration, response.getStatusCode());

            return response;
        }
    }
}

這使得錯誤消息清晰且安全，為用戶和開發(fā)人員提供幫助。

錯誤四：忽視速率限制

發(fā)生了什么：在一個晴朗的日子，我們發(fā)起了一項促銷活動，我們的 API 流量猛增。雖然這對企業(yè)來說是個好消息，但一些用戶開始向 API 發(fā)送垃圾郵件請求，導致其他人資源匱乏。

影響：每個人的性能都下降了，我們收到了大量投訴。

我如何修復它：為了解決這個問題，我使用 Bucket4j 和 Redis 實現(xiàn)了速率限制。這是一個例子：

@Configuration
public class Resilience4jConfig {

    @Bean
    public CircuitBreakerConfig circuitBreakerConfig() {
        return CircuitBreakerConfig.custom()
                .failureRateThreshold(50)
                .waitDurationInOpenState(Duration.ofSeconds(60))
                .permittedNumberOfCallsInHalfOpenState(2)
                .slidingWindowSize(2)
                .build();
    }

    @Bean
    public RetryConfig retryConfig() {
        return RetryConfig.custom()
                .maxAttempts(3)
                .waitDuration(Duration.ofSeconds(2))
                .build();
    }
}

@Service
@Slf4j
public class ResilientService {

    private final CircuitBreaker circuitBreaker;
    private final RestTemplate restTemplate;

    public ResilientService(CircuitBreakerRegistry registry, RestTemplate restTemplate) {
        this.circuitBreaker = registry.circuitBreaker("internalService");
        this.restTemplate = restTemplate;
    }

    @CircuitBreaker(name = "internalService", fallbackMethod = "fallbackResponse")
    @Retry(name = "internalService")
    public String callInternalService() {
        return restTemplate.getForObject("https://internal-service.com/data", String.class);
    }

    public String fallbackResponse(Exception ex) {
        log.warn("Circuit breaker activated, returning fallback response", ex);
        return new FallbackResponse("Service temporarily unavailable", 
                                  getBackupData()).toJson();
    }

    private Object getBackupData() {
        // Implement cache or default data strategy
        return new CachedDataService().getLatestValidData();
    }
}

這確保了公平使用并保護 API 免遭濫用。

錯誤5：忽視可觀察性

發(fā)生了什么：每當生產(chǎn)中出現(xiàn)問題時，就像大海撈針一樣。我沒有適當?shù)娜罩居涗浕蛑笜?，因此診斷問題花費的時間比應有的時間要長。

影響：故障排除變成了一場噩夢，延遲了問題解決并使用戶感到沮喪。

我是如何解決這個問題的：我添加了 Spring Boot Actuator 來進行健康檢查，并將 Prometheus 與 Grafana 集成起來以實現(xiàn)指標可視化：

@RestControllerAdvice
@Slf4j
public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {

    @ExceptionHandler(HttpClientErrorException.class)
    public ResponseEntity<ErrorResponse> handleHttpClientError(HttpClientErrorException ex, 
                                                             WebRequest request) {
        log.error("Client error occurred", ex);

        ErrorResponse error = ErrorResponse.builder()
                .timestamp(LocalDateTime.now())
                .status(ex.getStatusCode().value())
                .message(sanitizeErrorMessage(ex.getMessage()))
                .path(((ServletWebRequest) request).getRequest().getRequestURI())
                .build();

        return ResponseEntity.status(ex.getStatusCode()).body(error);
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleGeneralException(Exception ex, 
                                                              WebRequest request) {
        log.error("Unexpected error occurred", ex);

        ErrorResponse error = ErrorResponse.builder()
                .timestamp(LocalDateTime.now())
                .status(HttpStatus.INTERNAL_SERVER_ERROR.value())
                .message("An unexpected error occurred. Please try again later.")
                .path(((ServletWebRequest) request).getRequest().getRequestURI())
                .build();

        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(error);
    }

    private String sanitizeErrorMessage(String message) {
        // Remove sensitive information from error messages
        return message.replaceAll("(password|secret|key)=\[.*?\]", "=[REDACTED]");
    }
}

我還使用 ELK Stack（Elasticsearch、Logstash、Kibana）實現(xiàn)了結(jié)構(gòu)化日志記錄。這使得日志更具可操作性。

要點

構(gòu)建彈性 API 是一個旅程，錯誤是這個過程的一部分。以下是我學到的主要經(jīng)驗教訓：

1. 始終為外部調(diào)用配置超時。
2. 使用斷路器來防止級聯(lián)故障。
3. 集中錯誤處理，使其清晰且安全。
4. 實施速率限制以管理流量峰值。

這些變化改變了我進行 API 開發(fā)的方式。如果您遇到過類似的挑戰(zhàn)或有其他建議，我很想聽聽您的故事！

尾注：請記住，彈性不是您添加的功能，而是您從頭開始構(gòu)建到系統(tǒng)中的特性。這些組件中的每一個在創(chuàng)建 API 方面都發(fā)揮著至關(guān)重要的作用，這些 API 不僅可以工作，而且可以在壓力下繼續(xù)可靠地工作。

以上是構(gòu)建彈性 API：我犯的錯誤以及我如何克服這些錯誤的詳細內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！