_4-10_ 봄 클라우드 보안 서비스의 전투 제한 마이크로 스프링 클라우드 zuul-만 부가 함께 할

Benpian 말하는 게이트웨이 스트림에 대한 제한

오픈 소스 프로젝트로 스프링 클라우드 zuul-만 부가가 게이트웨이에 제한을 (프로젝트 GitHub의 : https://github.com/marcosbarbero/ )

1 게이트웨이 프로젝트들은 종속 전류 제한을 받는다는 성분이 소개

2 게이트웨이 프로젝트 YML 구성, 구성은 제한과 연관된

GitHub의도 관련 구성 지침 : https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit

일부 정보를 저장할 필요성을 제한하는 프레임 워크를 제한하는 것은,이 또한 여기 레디 스 실험, 레디 스에 존재할 수있는 데이터베이스가 될 수 있지만, 내가 열거 급 스토리지 구성 요소를 제한 생각, 정보를 제한 저장된 데이터베이스를 사용하는 경우, 단지 사용의 MyBatis (비뚤어진 너트 JPA를 선호 할 수있다)이 될 수 없습니다, JPA를 사용합니다 :

공공  열거 RateLimitRepository { 
    레디 스, 
    CONSUL, 
    JPA, 
    BUCKET4J_JCACHE, 
    BUCKET4J_HAZELCAST, 
    BUCKET4J_IGNITE,
    BUCKET4J_INFINISPAN,
}

YML 구성을 제한 :

정보를 제한, 기간이 자동으로 (난 그냥 설정 시작 1 초 때문에 시간 창은 10 초로 설정되어 레디 스를 제한에 대한 정보를보기 위해, 지워집니다 동안, 레디 스의 기간이 레디 스 삶과 죽음은) 시간 십분을 낭비하고, 정보를 제한 표시되지 않습니다

Zuul : 
  경로 : # 라우팅 구성, 여러 구성 할 수있는지도입니다 
    토큰 :   #을 , 끝을 요청 토큰은 HTTP로 전달됩니다 : // localhost를 : 9090 인증 서버 주소 
      URL : HTTP : // localhost를 : 9090 
    순서 :   #의 순서의 끝 요청은 HTTP로 전달됩니다 : // localhost를 : 9060 땡 단일 서비스 
      URL : HTTP : // localhost를 : 9060 
  민감한 헤더 :   널   #은 null로 설정되어 민감한 머리를 설정, 인증 요청 헤더와 다른 요청이 전달됩니다 다시
  만 부가 :
      키 -prefix : 속도
      사용 : true로 
      저장소 : 레디 스의
       기본 -policy- 목록 :
         #은     다음과 같은 구성을 말할 ########### : 1 개 초마다 요청은 2, 두 시간이 1 초 이상을 요구하지 않습니다 초과 할 수 없습니다 (할당량) ############ 
        - 제한 : 2 # 옵션 - 간격 창마다 새로 고침 요청 번호 제한 
          할당량 :. 1 # 옵션 - 창 당 제한 간격으로 새로 고침 요청 시간 (초 단위) 
          새로 고침 간격 The- : 10  # 시간 창 (초) 
          을 입력합니다 # 조합하여 사용할 수있다 내용에 따라 # 제어 트래픽이 같은 URL, httpmethod 조합, 둘 것이다 / 주문 수 및 사후 요청은 별도로 처리 
            - URL을
             -http_method
           # - # 보안 사용자 컨트롤이 지원을 필요로하는 사용자에 따라, (일반적으로 할) 
          # - # 원산지 클라이언트의 IP 제어에 따라

3. 실험

1에 각각 개시 순서, 인증, 서비스 게이트웨이 세

게이트웨이 토큰으로부터 취득한 2 :

OAuth2를 암호 모드 매개 변수

게이트웨이 클라이언트의 사용자 이름, 암호

3, 주문을 생성하기 위해 토큰 액세스 게이트웨이 걸릴

포인트 손 속도는 빠르게는 HTTP 429 반환 상태 코드가 너무 많은 요청을 나타냅니다.

룩 레디 스, 정보를 이미 제한 흐름 :

제한 키가 생성됩니다 속도 : 주문 / 주문 : POST가 속도 제한 정보가 접두사 구성, 순서가 zuul 전달 규칙, / 주문입니다 : POST는 구성과 흐름을 제한 URL을 입력의 조합 http_method

레디 스에 따라 다음 키를 계산할 때 다음 요청 키를 찾아 올 것이다 때, 현재 키 요청의 수 있었다 참조 요청이 너무 판단 할 수 없습니다.

대부분의 경우, 사용자, 원산지, URL에 따라, http_method 이미 수요를 충족. 특별한 시나리오, 제한 매개 변수를 통해 전달하는 필요에 따라 초당 처리 할 수있는 초당 100 명 요청, 복잡한 쿠폰 B를 처리 할 수있는이 개 같은 쿠폰을 A, B, A 쿠폰 간단한 작업이있다 요청은 이번에는 수요를 충족 할 수없는 제한 규정되어 있습니다. 제한 전류 제한 최종 하단 찢어 그것은 키 생성 규칙을 사용자 정의 할이 시간에 필요, 키입니다.

사용자 정의 키 생성 규칙 :

import com.marcosbarbero.cloud.autoconfigure.zuul.ratelimit.config.RateLimitUtils;
import com.marcosbarbero.cloud.autoconfigure.zuul.ratelimit.config.properties.RateLimitProperties;
import com.marcosbarbero.cloud.autoconfigure.zuul.ratelimit.support.DefaultRateLimitKeyGenerator;
import org.springframework.cloud.netflix.zuul.filters.Route;
import org.springframework.stereotype.Component;

import javax.servlet.http.HttpServletRequest;

/**
 * 自定义限流key生成规则，自定义限流规则
 */
@Component
public class MyKeyGen extends DefaultRateLimitKeyGenerator {

    public MyKeyGen(RateLimitProperties properties, RateLimitUtils rateLimitUtils){
        super(properties,rateLimitUtils);
    }

    @Override
    public String key(HttpServletRequest request, Route route, RateLimitProperties.Policy policy) {
        //可以从route拿出路由信息，自定义key生成规则：https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit#usage
        return super.key(request, route, policy);
    }
}

重写错误处理：

package com.nb.security.filter;

import com.marcosbarbero.cloud.autoconfigure.zuul.ratelimit.config.repository.DefaultRateLimiterErrorHandler;
import org.springframework.stereotype.Component;

/**
 * 限流错误自定义处理
 */
@Component
public class MyRateLimitErrorHandler extends DefaultRateLimiterErrorHandler {

    //限流数据存时候报错了的处理，一般不覆盖
    @Override
    public void handleSaveError(String key, Exception e) {
        super.handleSaveError(key, e);
    }

    //限流取数据报错的处理，一般不覆盖
    @Override
    public void handleFetchError(String key, Exception e) {
        super.handleFetchError(key, e);
    }

    //限流错误处理，记日志等
    @Override
    public void handleError(String msg, Exception e) {
        super.handleError(msg, e);
    }
}

都在网关上做限流是有问题的

1，耦合

　　如上所述的根据不同的优惠券进行的限流，如果优惠券又多了种类型，就要重写网关的限流的代码，重写部署网关，这就是耦合，是不行的。服务和服务之间，以及服务和基础组件之间，一定要解耦。微服务场景下解耦是价值最大的事。一旦两个服务耦合在一块，一个变了，另一个也要跟着变。

2，限流的数量的问题

　　网关只能处理从整个微服务外边进来的请求，并不处理微服务之间的调用。如，有A B两个微服务，A还调用了B服务，A、B服务每秒处理的请求最大都是100个，网关限流 A 100请求/秒，B 100请求/秒。此时有100个A请求到网关，100个B请求也到了网关，都通过了网关，而此时，100个到A的请求又请求了100次B，导致B服务不可用！

所以：在网关上不要做细粒度的限流，没有用，因为很多服务之间的调用，都不走网关。网关层面只根据硬件设备的处理能力做一些限流，如服务的节点用的是tomcat，根据每个tomcat的资源配置，计算能处理的多少并发请求，根据这个去限流。具体的方法，跟业务逻辑的耦合，都不要发生在网关上的限流逻辑里。这就是上边配置里说的，限流类型 user最好不在网关上用。

本篇github ： https://github.com/lhy1234/springcloud-security/tree/chapt-4-10-ratelimit 如果对你有一点帮助，点个小星星吧！谢谢