sentinel-1.8.6 基于生産實踐遇到的坑

最近基于sentinel-1.8.6搭建了一套供生産使用。在開發的過程中遇到了一些問題并進行了改造，在此記錄一下。

1、http通路支援ip級别限流

如果是基于servlet容器的,可以手動複制

com.alibaba.csp.sentinel.adapter.servlet.CommonFilter

，自定義一個filter，加載自定義的filter，重寫

com.alibaba.csp.sentinel.adapter.servlet.CommonFilter#parseOrigin

方法

private String parseOrigin(HttpServletRequest request) {
        String origin = IPUtils.getIpAddress(request);
        if (StringUtil.isEmpty(origin)) {
            return EMPTY_ORIGIN;
        }
        return origin;
    }
           

如果是springmvc

@Configuration
public class SentinelInterceptorConfig extends WebMvcConfigurerAdapter {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        // Add Sentinel interceptor
        addSpringMvcInterceptor(registry);
    }

    private void addSpringMvcInterceptor(InterceptorRegistry registry) {
        SentinelWebMvcConfig config = new SentinelWebMvcConfig();
        config.setBlockExceptionHandler(new CustomBlockExceptionHandler());
        config.setHttpMethodSpecify(true);
        config.setWebContextUnify(true);
        //設定來源解析
        config.setOriginParser(request -> {
            //針對IP解析
            return IPUtils.getIpAddress(request);
        });
        // Add sentinel interceptor
        registry.addInterceptor(new SentinelWebInterceptor(config)).addPathPatterns("/**");
    }
}
           

2、熱點參數、授權規則，資料結構不一緻的情況

在原有的記憶體方式實作，dashboard會通過調用接口方式将rule傳遞到用戶端，

但是生産lz使用的是push模式，規則配置持久化至nacos，是以也就序列化了

AuthorityRuleEntity

這個實體，後來發現，授權規則，熱點參數，與其他流控，熔斷，系統保護規則不一緻，授權/熱點參數對應的序列化entity中存在rule字段，用戶端進行反序列化的entity是對應的rule實體是沒有rule字段，會導緻rule字段丢失。

最小的改造成本就是在dashboard中儲存熱點參數規則以及授權規則的時候，将rule字段内的内容提升至最外圍的entity字段層級（即模仿流控，熔斷的實作方式）。

在dashboard的頁面回顯/傳參等操作上也要處理。

3、實體id的持久化

在進行respository.save()方法時，會生成對應id，記憶體實作是維護了一個atomic，如果應用重新開機，會導緻id丢失錯亂的情況。

改造方法可以選擇集中式持久化，比如db,redis等方式