:에서 재판 https://www.jianshu.com/p/2fc92a929e8e
이야기
보통 프로젝트에서 호출 무한히 많은 수없는 토큰 일부 API 액세스를 방지하기 위해, 일부 서비스의 API에 대한 필요성이 제한. 같은 일부 등록 인터페이스의 일부를 찍거나 인증 코드를 전송하는 악성 무제한 통화를하는 경우, 얼마나 많은 생산 비용의 일부 원인이됩니다, 전송 문자 메시지 나 이메일은 이상의 제 3 자 인터페이스, 수, 물론, 더 많은 비용의 일부입니다 심각한 직접 충돌 서비스. 스프링 클라우드 API-게이트웨이 구성을 한정하는 것은 여전히 필요하다 도입.
솔루션
Zuul 만 부가가 의존 파일 치어에 도입
<dependency>
<groupId>com.marcosbarbero.cloud</groupId>
<artifactId>spring-cloud-zuul-ratelimit</artifactId>
<version>1.3.2.RELEASE</version>
</dependency>YML 配置
更详细的配置解读下面有写，这里只是简单配置一下，以下这个配置就可以对服务进行限流了
zuul:
routes: 你的路由配置
test:
path:
serviceId:
ratelimit:
enabled: true
policies:
test: 路由名
limit: 限制次数
refresh-interval: 刷新时间
type: 类型
열 쇼
자신 현지 서비스가, 겨우 10 시간에 액세스 할 수있는 분 API 내에서 서비스에 10 배 이상을 구성, 게이트웨이는 오류가 발생하지
zuul:
routes:
test:
path: /api/test/**
serviceId: hscf-cloud-test-9457
ratelimit:
enabled: true
policies:
test:
limit: 10
refresh-interval: 60
type: origin 限流方式다음 짧게하여 소스 코드를 검사
만 부가 클래스 상속 ZuulFilter, 변수가 YML 구성 파일에서 우리의 재산의 가치를 어렵지 않다에서. "사전"으로 만 부가, filterType 내 소스 코드의 일부는 각 API에 액세스하기 전에 요격을 나타냅니다, LIMIT_HEADER, REMAINING_HEADER, RESET_HEADER 우리가 방문의 수를 구성 할 수 있어야이 세 가지 변수뿐만 아니라 남은 시간 기록에서 방문 횟수 .
public class RateLimitFilter extends ZuulFilter {
public static final String LIMIT_HEADER = "X-RateLimit-Limit";
public static final String REMAINING_HEADER = "X-RateLimit-Remaining";
public static final String RESET_HEADER = "X-RateLimit-Reset";
public String filterType() {
return "pre";
}
public int filterOrder() {
return -1;
}
public boolean shouldFilter() {
return this.properties.isEnabled() && this.policy(this.route()).isPresent();
}몸 로직 실행의 심판 (). 우선 this.policy (루트)를 통해 .ifPresent는 ((정책 ) 정책이 설정 정보는 프레 젠스 읽을 존재 판정
한계 값은 0보다 작은 나머지 최종 한계 값이 0보다 작은 결정이 남아, 전류 제한값에 도착을 그것은 비정상적인 너무 많은 요청에보고 된 것
TOO_MANY_REQUESTS (429, "너무 많은 요청을 ")
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletResponse response = ctx.getResponse();
HttpServletRequest request = ctx.getRequest();
Route route = this.route();
this.policy(route).ifPresent((policy) -> {
String key = this.rateLimitKeyGenerator.key(request, route, policy);
Rate rate = this.rateLimiter.consume(policy, key);
response.setHeader("X-RateLimit-Limit", policy.getLimit().toString());
response.setHeader("X-RateLimit-Remaining", String.valueOf(Math.max(rate.getRemaining().longValue(), 0L)));
response.setHeader("X-RateLimit-Reset", rate.getReset().toString());
if(rate.getRemaining().longValue() < 0L) {
ctx.setResponseStatusCode(HttpStatus.TOO_MANY_REQUESTS.value());
ctx.put("rateLimitExceeded", "true");
throw new ZuulRuntimeException(new ZuulException(HttpStatus.TOO_MANY_REQUESTS.toString(), HttpStatus.TOO_MANY_REQUESTS.value(), (String)null));
}
});
return null;
}
。。。。。。예외 정보 콘솔, 이상 코드는 이상 너무 많은 요청이다 429이다 : TOO_MANY_REQUESTS (429, "너무 많은 요청")
만 부가 상세한 구성 정보 해석
zuul:
ratelimit:
key-prefix: your-prefix #对应用来标识请求的key的前缀
enabled: true
repository: REDIS #对应存储类型（用来存储统计信息）
behind-proxy: true #代理之后
default-policy: #可选 - 针对所有的路由配置的策略，除非特别配置了policies
limit: 10 #可选 - 每个刷新时间窗口对应的请求数量限制
quota: 1000 #可选- 每个刷新时间窗口对应的请求时间限制（秒）
refresh-interval: 60 # 刷新时间窗口的时间，默认值 (秒)
type: #可选 限流方式
- user
- origin
- url
policies:
myServiceId: #特定的路由
limit: 10 #可选- 每个刷新时间窗口对应的请求数量限制
quota: 1000 #可选- 每个刷新时间窗口对应的请求时间限制（秒）
refresh-interval: 60 # 刷新时间窗口的时间，默认值 (秒)
type: #可选 限流方式
- user
- origin
- url
- URL 형의 유동 제한을 요청 경로에 의해 구별된다
- 원산지는 클라이언트 IP 주소에 의해 구별된다
- 사용자 로그인은 익명의 사용자를 포함하여, 사용자 이름으로 구별된다
