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

錯(cuò)誤一：忽略逾時(shí)配置

發(fā)生了什麼事：在我的一個(gè)早期專案中，我建立了一個(gè) API，可以對(duì)第三方服務(wù)進(jìn)行外部呼叫。我認(rèn)為這些服務(wù)總是會(huì)快速回應(yīng)，並且不會(huì)費(fèi)心設(shè)定超時(shí)。一切看起來(lái)都很好，直到流量增加，第三方服務(wù)開(kāi)始變慢。我的 API 將無(wú)限期掛起，等待回應(yīng)。

影響： API 的反應(yīng)能力急遽下降。相關(guān)服務(wù)開(kāi)始出現(xiàn)故障，用戶面臨長(zhǎng)時(shí)間的延遲，有些甚至遇到了可怕的 500 內(nèi)部伺服器錯(cuò)誤。

我是如何修復(fù)它的：那時(shí)我意識(shí)到超時(shí)配置的重要性。以下是我使用 Spring Boot 修復(fù)這個(gè)問(wèn)題的方法：

@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è)定適當(dāng)?shù)挠鈺r(shí)，還包括日誌記錄以幫助監(jiān)控外部服務(wù)效能。

錯(cuò)誤2：沒(méi)有實(shí)施斷路器

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

級(jí)聯(lián)故障是分散式系統(tǒng)中最具挑戰(zhàn)性的問(wèn)題之一。當(dāng)一項(xiàng)服務(wù)出現(xiàn)故障時(shí)，可能會(huì)產(chǎn)生骨牌效應(yīng)，導(dǎo)致整個(gè)系統(tǒng)癱瘓。

影響：重複的重試使系統(tǒng)不堪重負(fù)，減慢了應(yīng)用程式的其他部分並影響了所有用戶。

我是如何修復(fù)它的：就在那時(shí)我發(fā)現(xiàn)了斷路器模式。使用 Spring Cloud Resilience4j，我能夠打破這個(gè)循環(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();
    }
}

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

錯(cuò)誤 3：錯(cuò)誤處理能力弱

發(fā)生了什麼事： 早期，我沒(méi)有對(duì)錯(cuò)誤處理投入太多考慮。我的 API 要么拋出一般錯(cuò)誤（例如所有內(nèi)容的 HTTP 500），要么在堆疊追蹤中暴露敏感的內(nèi)部詳細(xì)資訊。

影響：使用者對(duì)出了什麼問(wèn)題感到困惑，內(nèi)部細(xì)節(jié)的暴露造成了潛在的安全風(fēng)險(xiǎn)。

我是如何修復(fù)它的：我決定使用 Spring 的 @ControllerAdvice 註解來(lái)集中處理錯(cuò)誤。這就是我所做的：

@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;
        }
    }
}

這使得錯(cuò)誤訊息清晰且安全，為使用者和開(kāi)發(fā)人員提供協(xié)助。

錯(cuò)誤四：忽視速率限制

發(fā)生了什麼事：在一個(gè)晴朗的日子，我們發(fā)起了一項(xiàng)促銷(xiāo)活動(dòng)，我們的 API 流量猛增。雖然這對(duì)企業(yè)來(lái)說(shuō)是個(gè)好消息，但一些用戶開(kāi)始向 API 發(fā)送垃圾郵件請(qǐng)求，導(dǎo)致其他人資源匱乏。

影響：每個(gè)人的表現(xiàn)都下降了，我們收到了大量投訴。

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

@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();
    }
}

這確保了公平使用並保護(hù) API 免受濫用。

錯(cuò)誤5：忽視可觀察性

發(fā)生了什麼事：每當(dāng)生產(chǎn)中出現(xiàn)問(wèn)題時(shí)，就像大海撈針一樣。我沒(méi)有適當(dāng)?shù)娜照I記錄或指標(biāo)，因此診斷問(wèn)題花費(fèi)的時(shí)間比應(yīng)有的時(shí)間要長(zhǎng)。

影響：故障排除變成了一場(chǎng)噩夢(mèng)，延遲了問(wèn)題解決並使用戶感到沮喪。

我是如何解決這個(gè)問(wèn)題的：我添加了 Spring Boot Actuator 來(lái)進(jìn)行健康檢查，並將 Prometheus 與 Grafana 整合起來(lái)以實(shí)現(xiàn)指標(biāo)視覺(jué)化：

@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）實(shí)作了結(jié)構(gòu)化日誌記錄。這使得日誌更具可操作性。

重點(diǎn)

建立彈性 API 是一個(gè)旅程，錯(cuò)誤是這個(gè)過(guò)程的一部分。以下是我學(xué)到的主要經(jīng)驗(yàn)教訓(xùn)：

1. 始終為外部呼叫配置逾時(shí)。
2. 使用斷路器來(lái)防止級(jí)聯(lián)故障。
3. 集中錯(cuò)誤處理，使其清晰且安全。
4. 實(shí)作速率限制以管理流量峰值。

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

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

以上是建立彈性 API：我犯的錯(cuò)誤以及我如何克服這些錯(cuò)誤的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！