编程思想：小谈网关项目中的设计模式

基于个人的经验，谈谈设计模式在网关中的应用。因为是经验之谈，没有绝对的对与错。

下面整理的是我最常使用的设计模式，我用设计模式的前提是

• 让代码的可读性变强
• 能支持日后功能扩展

单例

目的

保证全局只有一个实例，防止因为频繁的创建、销毁对象而造成不必要的性能开销。

在网关项目中，单例模式是出现频率最高的模式。同时，所有的单例对象被 IoC 框架 Guice 统一管理。

**场景 1 **

网关会处理各种逻辑。一般将业务逻辑从主流程中抽取出来，封装在一个独立对象中。可以使用单例模式来保证全局唯一，使用注解 Singleton 来表示这个一个单例：

@Singleton
public class HttpMethodPipeline {
  private List<HttpMethodHandler> handlers = new ArrayList<>();
  ...
}

使用注解 Inject 来注入对象

public class ApiRewriteFilter extends HttpInboundSyncFilter{

  @Inject
  private HttpMethodPipeline pipeline;

  @Override
  public HttpRequestMessage apply(HttpRequestMessage request) {
    ...  
    pipeline.process(request);
    ...
  }
}

减少 if-else

过多的 if-else 会导致

• 可读性变差
• 难以扩展维护
• 质量不可控，健壮性差
• 不利于单元测试

但是另一方面 if-else 是无法回避的代码。所以，为了让程序变得优雅，下面几种模式是我使用频次很高的模式，意在消除 if-else 代码段带来的负面影响。

1.表驱动法（策略）

目的

用表结构来驱动业务逻辑，减少 if-else 。这里的表结构可以参考 HashMap，通过对 Key 计算出 hash 从而快速获取数据

示例

以之前的游戏项目中一段代码举例，需要计算出当前的英雄的级别：

• 小于 80：等级 G
• 80 至140：等级 F
• 140 至 200：等级 E
• ...

使用表驱动法来计算等级的话，非常方便，只要预先定义好表即可，整体不会出现一行 if-else 代码，如下所示：

 public static String GetRoleAttributeClass(int attributeLv99) {

        Map<Integer,String> attributes = new HashMap<Integer, String>()
        {
            { 080, "G" },//  <=80 -> G
            { 140, "F" },//  >80 && <=140 -> F
            { 200, "E" },
            { 260, "D" },
            { 320, "C" },
            { 380, "B" },
            { 440, "A" },
            { 500, "S" },
        };
        var attributeClass = "?";
        foreach (var key in attributes.Keys.OrderBy(o=>o))
        {
            if (attributeLv99 <= key)
            {
                attributeClass = attributes[key];
                break;
            }
        }

        return attributeClass;
    }

当表驱动法+策略模式组合在一起时，可以极大的扩展系统。

场景 1

开放网关最初只支持 AppId+Secret 形式校验，但随着业务发展，为了满足不同的场景，需支持

• 简单认证，即 AppId+内网
  • 携带请求头：X-Tsign-Open-Auth-Model=simple 来告知网关走哪种模式鉴权
• Token 认证
  • 携带请求头：X-Tsign-Open-Auth-Mode=token 来告知网关走哪种模式鉴权
• 签名验签认证
  • 携带请求头：X-Tsign-Open-Auth-Mode=signature 来告知网关走哪种模式鉴权
• 默认 AppId+Secret
  • 携带请求头：X-Tsign-Open-Auth-Mode=signature 来告知网关走哪种模式鉴权

很显然，这是一种典型的横向扩展需求，鉴权模式会随着业务的发展而扩展。如果通过 if-else 将处理逻辑杂糅在主流程中，势必会造成越来越臃肿。

使用策略模式+表驱动法，可以有效缓解这种处境。

a.) 定义鉴权策略

public interface AuthStrategy {
    Observable<HttpRequestMessage> auth(HttpRequestMessage request) throws Exception;
}

b.) 定义不同的策略实现类

• SimpleAuthStrategy
• TokenAuthStrategy
• SignatureAuthStrategy
• SecretAuthStrategy

c.)通过 Guice 来定义表，即映射关系，映射的 Key= X-Tsign-Open-Auth-Model 传递过来的鉴权模式，Value=具体的实现类

MapBinder<String, AbstractAuthStrategy> authStrategyMapBinder = MapBinder.newMapBinder(binder(), String.class, AbstractAuthStrategy.class);
        authStrategyMapBinder.addBinding(OpenProtocol.SIMPLE_AUTH_STRATEGY).to(SimpleAuthStrategy.class);
        authStrategyMapBinder.addBinding(OpenProtocol.TOKEN_AUTH_STRATEGY).to(TokenAuthStrategy.class);
        authStrategyMapBinder.addBinding(OpenProtocol.SIGNATURE_AUTH_STRATEGY).to(SignatureAuthStrategy.class);
        authStrategyMapBinder.addBinding(OpenProtocol.SECRET_AUTH_STRATEGY).to(SecretAuthStrategy.class);

d.) 在主流程中，根据鉴权模式，获取到对象的策略对象

@Slf4j
@Singleton
public class OpenAuthFilter extends HttpInboundFilter implements OpenProtocol {

    @Inject
    private Map<String, AbstractAuthStrategy> strategies;

    @Configuration("${open.auth.default.mode}")
    private String AUTH_DEFAULT_MODE ="secret";

    @Override
    public Observable<HttpRequestMessage> applyAsync(HttpRequestMessage request) {
        //获取身份校验模式,如果不指定则使用默认的
        String mode=StringUtils.defaultIfEmpty(request.getHeaders().getFirst(AUTH_MODE), AUTH_DEFAULT_MODE).toLowerCase();
        //根据模式选择对应的策略
        AbstractAuthStrategy authStrategy = strategies.get(mode);
        if (authStrategy == null) {
            route2Error(ctx, Problem.valueOf(Status.UNAUTHORIZED));
            return Observable.just(request);
        }
        try {
            return authStrategy.auth(request);
        } catch (Exception cause) {
            logger.error("authentication failed.{}", cause);
            route2Error(ctx, Problem.valueOf(Status.UNAUTHORIZED));
            return Observable.just(request);
        }
    }
}

2.职责链

目的

一个逻辑可能由多种处理模式，通过将这些处理模式连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递。

场景 1

网关需要对 HTTP Method 进行适配，比如小程序客户端 Http Method 不支持 Put/Delete ，只支持 Get/Post。所以一般情况下使用 Post 来代替 Put/Delete，同时可能通过以下几种方式：

• 请求头

• 请求参数

• 请求 Body

来告诉网关真正的 Method，所以网关需要对 HTTP Method 支持适配。可以职责链来实现这个需求：

 public class HttpMethodPipeline {

  private List<HttpMethodHandler> handlers = new ArrayList<>();

  @PostConstruct
  private void init() {
    //第一优先级
    handlers.add(new InHeaderHttpMethodHandler());
    //第二优先级
    handlers.add(new InParameterHttpMethodHandler());
    //默认优先级，兜底方案
    handlers.add(new DefaultHttpMethodHandler());
  }

  public String process(HttpRequestMessage request) {
    try {
      for (HttpMethodHandler handler : handlers) {
        if (handler.shouldFilter(request)) {
          return handler.apply(request);
        }
      }
    } catch (Exception cause) {
      logger.error("{}", cause);
    }
    //容错方案
    return request.getMethod();
  }
}

场景 2

网关对用户 Token 鉴权时，需要对比 Token 中授权人的 Id是否与接口入参 accountId 保持一致。同时，这个 accountId 有可能位于

• Path
• Header
• Request Parameter
• Request Body

只要满足一个条件即可，通过职责链模式，可以有效解决问题，避免 if-else 带来的扩展麻烦

    private HttpRequestMessage postAuthentication(HttpRequestMessage request, MatchApi matchApi) {
       
        if (TokenMode.USER.toString().equals(tokenMode)) {
            //验证不过
            if (!validatorEngine.run(
                AuthContext
                    .builder()
                    .request(request)
                    .matchApi(matchApi)
                    .build())) {
                route2Error(ctx, Problem.valueOf(Status.UNAUTHORIZED));
            }
        }
        return request;
    }

定义验证引擎，本职上是一个处理链

    class ValidatorEngine {
        private List<AuthValidator> validators=new ArrayList<>();
        ScopeValidator scopeValidator=new ScopeValidator();
        ValidatorEngine(){
            validators.add(new PathValidator());
            validators.add(new HeaderValidatorEngine());
            validators.add(new BodyValidator());
            validators.add(new ParameterValidator());
        }

        boolean run(AuthContext authContext){
            boolean pass=false;
            try {
                if (scopeValidator.validate(authContext)){
                    for (AuthValidator validator : validators) {
                        if (validator.validate(authContext)){
                            pass=true;
                            break;
                        }
                    }
                }
            }catch (Exception cause){
                pass=true;
                logger.error("",cause);
            }
            return pass;
        }
    }

简单工厂

目的

提供创建实例的功能，而无需关心具体实现，彼此之间互相解耦。往往和策略模式组合使用，即从工厂中获取一个策略。

场景 1

根据灰度配置获取灰度策略

public interface RuleStrategyFactory {
    RuleStrategy getRuleStrategy(GrayRule grayRule);
}

场景 2

获取远程服务

public interface NettyOriginFactory {
  NettyOrigin create(@Assisted("name") String name, @Assisted("vip") String vip, int defaultMaxRetry, Routing routing);
}

场景 3

根据 Uri 获取模板

public interface UriTemplateFactory {
    UriTemplate create(String name);
}

场景 4

获取 WAF 拦截处理器

@Singleton
public class InboundRuleMatcherFactory {
  public InboundRuleMatcher create(RuleDefinition definition) {
    InboundRuleMatcher inboundRuleMatcher = null;
    switch (definition.getRuleStage()) {
      case CLIENT_IP:
        inboundRuleMatcher = new ClientIPRuleMatcher(definition);
        break;
      case CONTENT_TYPE:
        inboundRuleMatcher = new ContentTypeRuleMatcher(definition);
        break;
      case CONTENT_LENGTH:
        inboundRuleMatcher = new ContentLengthRuleMatcher(definition);
        break;
      case USER_AGENT:
        inboundRuleMatcher = new UserAgentRuleMatcher(definition);
        break;
      case REQUEST_ARGS:
        inboundRuleMatcher = new RequestArgsRuleMatcher(definition);
        break;
      case COOKIES:
        inboundRuleMatcher = new CookieRuleMatcher(definition);
        break;
      default:
        break;
    }
    return inboundRuleMatcher;
  }
}

简单工厂可以和表驱动法组合使用，这样会非常清爽：

@Singleton
@Slf4j
public class DefaultFlowStrategyFactory implements FlowStrategyFactory {

    @Inject
    private Injector injector;

    private static final ImmutableMap<LBAlgorithmType, Class<? extends AbstractFlowStrategy>> map = ImmutableMap.of(
            LBAlgorithmType.RANDOM, RandomFlowStrategy.class,
            LBAlgorithmType.ROUND_ROBIN, RoundRobinFlowStrategy.class,
            LBAlgorithmType.WEIGHTED, WeightedFlowStrategy.class);

    @Override
    public FlowStrategy getFlowStrategy(Flow flow) {
        AbstractFlowStrategy strategy = null;
        Class<? extends AbstractFlowStrategy> clazz = map.get(flow.getAlgorithm());
        if (clazz != null) {
            strategy = injector.getInstance(clazz);
        }
        if (strategy == null) {
            //容错机制，如果配置了非 RANDOM、ROUND_ROBIN、WEIGHTED 算法，或者忘记设置，默认返回 RANDOM
            strategy = new RandomFlowStrategy();
        }
        strategy.apply(flow.getValue());
        return strategy;
    }
}

模板方法

目的

定义处理逻辑的通用骨架，将差异化延迟到子类实现

场景 1

鉴权通过时，新老开放网关向下游传递的数据有差异，所有数据都会存储在 SessionContext中，通过模板方法定义通用骨架：

public abstract class AbstractAppPropertyStash implements AppPropertyStash {
  @Override
  public void apply(AppEntity appEntity, HttpRequestMessage request){
    SessionContext context = request.getContext();
    //记得在使用方做容错处理：DefaultValue
    context.set(APP_IP_WHITE_LIST_CTX_KEY, appEntity.getIps());
    context.set(APP_THROTTLE_INTERVAL_CTX_KEY, appEntity.getInterval());
    context.set(APP_THROTTLE_THRESHOLD_CTX_KEY, appEntity.getThreshold());
    store(appEntity,request);
  }
  protected abstract void store(AppEntity appEntity, HttpRequestMessage request);
}

对于新开放网关，向下游传递USER_ID

public class DefaultAppPropertyStash extends AbstractAppPropertyStash {
  @Override
  protected void store(AppEntity appEntity, HttpRequestMessage request) {
    SessionContext context = request.getContext();
    request.getHeaders().set(USER_ID, appEntity.getGId());
    context.set(USER_ID, appEntity.getGId());
  }
}

对于老开放网关，向下游传递LOGIN_ID

public class DefaultAppPropertyStash extends AbstractAppPropertyStash {
  @Override
  protected void store(AppEntity appEntity, HttpRequestMessage request) {
    String gId = appEntity.getGId();
    String oId = appEntity.getOId();
    if (StringUtils.isNotEmpty(oId)) {
      request.getHeaders().add(X_TSIGN_LOGIN_ID, oId);
      request.getContext().set(X_TSIGN_LOGIN_ID, oId);
    } else {
      request.getHeaders().add(X_TSIGN_LOGIN_ID, "GID$$" + gId);
      request.getContext().set(X_TSIGN_LOGIN_ID, "GID$$" + gId);
    }
  }

所以 USER_ID与LOGIN_ID就是差异化的表现，由各子类负责。

场景 2

网关支持灰度发布，即通过服务分组来将请求路由到指定分组的服务，通过定义模板，获取分组信息：group，然后差异化的路由由子类实现，比如：RandomFlowStrategy，RoundRobinFlowStrategy，WeightedFlowStrategy等。

public abstract class AbstractFlowStrategy implements FlowStrategy {

    protected List<String> groups;

    public void apply(Map<String, String> value) {
        groups = Arrays.asList(value.get("group").split(";"));
        preHandle(value);
    }

    protected abstract void preHandle(Map<String, String> value);

}

观察者

目的

定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新，彼此之间解耦。

场景 1

为了提高网关的响应，一般会将常用数据 LRU 缓存到本地。比如 WAF 拦截规则会预先从数据库中读取出来，同时这部分数据存在变更的可能，虽然频次很低，但还是每隔 5min 从数据库读取到内存中。

对于构建 WAF 规则是耗时的事情，特别是它需要正则表达式编译。故通过观察者模式，当感知到数据发生变化时，才通知下游处理程序构建 WAF 规则，如下 WAF 拦截规则即主题：

public class DynamicValue implements Value {

  private Set<Observer> observers = Collections.synchronizedSet(new HashSet<>());

  private Set<RuleDefinition> value = null;

  public DynamicValue() {
  }

  public DynamicValue(Set<RuleDefinition>  value) {
    super();
    this.value = value;
  }

  @Override
  public void addObserver(Observer observer) {
    observers.add(observer);
  }

  @Override
  public void removeObserver(Observer observer) {
    observers.remove(observer);
  }

  @Override
  public boolean updateValue(Set<RuleDefinition> newValue) {
    if (isEqual(value, newValue)) {
      return false;
    }
    value = newValue;
    //规则变化，更新
    for (Observer observer : observers) {
      observer.onChange(newValue);
    }
    return true;
  }

  @Override
  public void clear() {
    observers.clear();
  }

  private boolean isEqual(Set<RuleDefinition>  oldValue, Set<RuleDefinition> newValue) {
    if (oldValue == null && newValue == null) {
      return true;
    }
    if (oldValue == null) {
      return false;
    }
    return oldValue.equals(newValue);
  }
}

下游的处理程序作为观察者：

public class RuleManager {
  private Value wafDynamicValue = new DynamicValue();
    
  public void register(Observer observer){
    wafDynamicValue.addObserver(observer);
  }
}

场景 2

网关会将所有的 HTTP 请求、响应发送到 Kafka 中。虽然本身 Kafka Client 的 send 方法时异步的，但 Kafka 故障或者 Kafka 生产者的内存满时，会 block主线程。虽然可以通过多线程的方式解决，但线程之间的频繁切换以及send方法里的同步锁势必会造成性能影响。

借助 RxJava 中的生产者-消费者模式，可以有效的解决这个问题：

    Observable.<GatewayApiEntity>create(
        emitter -> {
          consumer = emitter::onNext;
          cleaner = emitter::onCompleted;
        })
        .onBackpressureBuffer(
            BUFFER_CAPACITY, // 经调试最终Capacity:BUFFER_CAPACITY+128(默认)
            () -> logger.info("Buffer is filling up now."),
            BackpressureOverflow.ON_OVERFLOW_DROP_OLDEST) // 当 Buffer 满时，Drop 旧值，并添加新值
        .filter(Objects::nonNull)
        .observeOn(Schedulers.io())//切换到异步线程消费
        .doOnCompleted(countDownLatch::countDown)
        .subscribe(this::sendMessage);

使用异步被压策略好处

• Kafka 获取元数据或者当 buffer.memory >32 时，Kafka 生产者将阻塞 max.block.ms =60000 ms ，故不能将 Send 放到 Zuul IO 线程中
• 通过生产者-消费者，将 Kafka 生产者 Send 方式并行转变为串行，减少多线程的同步、锁竞争等问题
• 当 Kafka 故障、吞吐量降低时，背压的丢弃策略，可以防止 OOM

装饰者

目的

动态地给一个对象添加一些额外的功能，能在不影响原有功能的基础上，对其扩展功能。

场景 1

网关路由时，需要获取远程服务相关元数据，然后通过本地负载均衡选取具体的服务实例。默认情况下，NettyOriginManager 对象将远程的 Origin 缓存在内存中：ConcurrentHashMap。从功能上来看，这是没问题的。但为了性能上的优化，试想一下，当网关重启时，这些缓存数据将丢失，又需要重新去获取一遍元数据，下游服务越多，第一次请求的性能影响越大。如果在网关重启时，默认同步所有服务元数据下来，是不是会更好？所以，需要确定哪些服务要被初始化，这就需要在 createOrigin方法中额外增加这个保存Origin的逻辑。

OriginManager 的实现类 NettyOriginManager 支持对 Origin 的管理，创建和获取

Slf4j
@Singleton
public class NettyOriginManager implements OriginManager<NettyOrigin>, Closeable {

    private final ConcurrentHashMap<OriginKey, NettyOrigin> originMappings = new ConcurrentHashMap<>();

    @Override
    public NettyOrigin getOrigin(String name, String vip, String uri, SessionContext ctx{
     
    }

    @Override
    public NettyOrigin createOrigin(String name, String vip, String uri, boolean useFullVipName, SessionContext ctx) {
       
    }
}

将元数据保存原本NettyOriginManager对象并不关心，同时如果NettyOriginManager有三方框架提供，是无法修改其源码。故使用装饰者模式，可以有效解决这个尴尬的问题，如下所示：在不侵入NettyOriginManager 的情况下，对其增强

public interface OriginManagerDecorator extends OriginManager<NettyOrigin> {

    void init();

    void saveOrigin(String name, String vip, Map<String, Boolean> routingEntries);

    void deleteOrigin(String data);
}

以保存到 Redis 为例，新增装饰对象：RedissonOriginManager 装饰 NettyOriginManager，在原有能力上具备持久化的功能

@Singleton
@Slf4j
public class RedissonOriginManager implements OriginManagerDecorator {

    @Inject
    private RedissonReactiveClient redissonClient;

    /*
    被装饰对象
     */
    @Inject

    private NettyOriginManager nettyOriginManager;

    @Override
    @PostConstruct
    public void init() {
        //获取redis namespace,初始化
    }

    @Override
    public void saveOrigin(String name, String vip, Map<String, Boolean> routingEntries){
    
    }

    @Override
    public void deleteOrigin(String data) {
        
    }

    @Override
    public NettyOrigin getOrigin(String name, String vip, String uri, SessionContext ctx{
        //pass through
        return nettyOriginManager.getOrigin(name, vip, uri, ctx);
    }

    @Override
    public NettyOrigin createOrigin(String name, String vip, String uri, boolean useFullVipName, SessionContext ctx) {
         //pass through
        NettyOrigin origin = nettyOriginManager.createOrigin(name, vip, uri, useFullVipName, ctx);
        //对原有的Origin Manager 进行增强，如果存在 Origin的话，对其缓存
        if (origin != null && origin instanceof SimpleNettyOrigin) {
            saveOrigin(name, vip, ((SimpleNettyOrigin) origin).getRouting().getRoutingEntries());
        }
        return origin;
    }
}

在原有功能上新增了持久化到 Redis 的功能，可以根据不同的场景，装饰不同的实现方式：Redis、数据库、配置中心等

场景 2

网关在处理请求时，默认情况下只打印关键信息到日志，但是有时为了排查错误，需要打印更加丰富的日志。这是一种动态功能的增强，以开关的形式启用，关闭。如下，默认情况下RequestEndingHandler将 TraceId 和 ElapseTime 返回到客户端：

public class RequestEndingHandler implements RequestHandler {

  private Set<HeaderName> headers=new HashSet<>(
      Arrays.asList(HttpHeaderNames.get(Inbound.X_Tsign_Elapse_Time),
                    HttpHeaderNames.get(Inbound.X_Tsign_Trace_Id)));

  @Override
  public void handle(Object obj) {
      //一些服务先走应用网关，再走开放网关，清空下开放网关的响应头，使用应用网关的
      response.getHeaders().removeIf(headerEntry -> headers.contains(headerEntry.getKey()));
      //统计消耗的时间，放在响应头，便于排查问题
      response.getHeaders().add(Inbound.X_Tsign_Elapse_Time,
          String.valueOf(TimeUnit.MILLISECONDS.convert(request.getDuration(), TimeUnit.NANOSECONDS)));
      //trace-id,用于调用链跟踪
      //谨防 Null
      response.getHeaders().add(Inbound.X_Tsign_Trace_Id, StringUtils
          .defaultString(             response.getOutboundRequest().getHeaders().getFirst(CerberusConstants.TRACE_ID), ""));
  }
}

当开启了详细模式后，对原功能进行增强，支持所有的业务参数打印到日志：

public class SessionContextLogHandler extends RequestLogHandleDecorator {

  private final static char DELIM = '	';

  protected SessionContextLogHandler(
      RequestHandler handler) {
    super(handler);
  }

  @Override
  protected void log(Object obj) {
      StringBuilder sb=new StringBuilder();
      sb
          .append(DELIM).append(context.getOrDefault(CerberusConstants.TRACE_ID,"-"))
          .append(DELIM).append(context.getOrDefault(Inbound.X_TSIGN_LOGIN_ID,"-"))
          .append(DELIM).append(context.getOrDefault(OpenProtocol.USER_ID,"-"))
      ;
      logger.info(sb.toString());
  }

建造者

目的

将复杂对象构建与主业务流程分离

场景 1

网关支持将所有经过网关的 HTTP 日志记录在 Kafka 中，这个 Message 对象是个大对象，并且对于其中的 requestHeader，responseBody 构建算法复杂。

通过构建者模式，将复杂对象从业务中剥离，避免过多的 if-else 造成混乱。

private GatewayApiEntity construct(HttpResponseMessage response){
    entity = GatewayApiEntity.builder()
          .appId(request.getHeaders().getFirst(Inbound.X_TSIGN_APP_ID))
          .clientIp(HttpUtils.getClientIP(request))
          .method(request.getMethod())
          .requestId(context.getUUID())
          .serviceId(context.getRouteVIP())
          .api((String) context.getOrDefault(CerberusConstants.ORIGINAL_API, ""))
          .requestTime((Long) context.get(CerberusConstants.TIMING_START_CTX_KEY))
          .source(getApplicationId())
          .timestamp(System.currentTimeMillis())
          .traceId((String) context.getOrDefault(CerberusConstants.TRACE_ID, ""))
          .url(request.getInboundRequest().getPathAndQuery())
          .userAgent(request.getHeaders().getFirst(HttpHeaders.USER_AGENT))
          .status(response.getStatus())
          .duration(getDuration(response))
          .requestHeader(getRequestHeader(request))
          .requestBody(getRequestBody(request))
          .responseBody(getResponseBody(response))
          .build();
}

  private String getRequestHeader(HttpRequestMessage request) throws JsonProcessingException {
    // 3.补充请求头 X-Tsign
  }

  private String getRequestBody(HttpRequestMessage request){
    //4.请求数据,如果是大包的话，不进行收集，因为 Broker 端对 Producer 发送过来的消息也有一定的大小限制，这个参数叫 message.max.bytes
  }

  private String getResponseBody(HttpResponseMessage response) throws IOException {
    // 5.处理 Body 里的数据,如果是大包的话，不进行收集，因为 Broker 端对 Producer 发送过来的消息也有一定的大小限制，这个参数叫 message.max.bytes
 	// Response body 被 gzip 压缩过
  }

场景 2

网关核心功能即路由，比如对请求： v1/accounts/abcdefg/infos 路由到 v1/accounts/{accountId}/infos 后端接口上 ，所以这需要正则表达式的支持。网关通过建造者模式，构建出一个复杂的 API 对象来表示元数据。

 Api.builder()
     .serviceId(entity.getServiceId())
     .url(url)
     .originalUrl(StringUtils.prependIfMissing(entity.originalUrl, "/"))
     .httpMethod(entity.getHttpMethod())
     .readTimeout(readTimeout)
     .uriTemplate(uriTemplateFactory.create(url))
     .build();