基於個人的經驗,談談設計模式在閘道器中的應用。因為是經驗之談,沒有絕對的對與錯。

下面整理的是我最常使用的設計模式,我用設計模式的前提是

  • 讓程式碼的可讀性變強
  • 能支援日後功能擴充套件

單例

目的

保證全域性只有一個例項,防止因為頻繁的建立、銷燬物件而造成不必要的效能開銷。

在閘道器專案中,單例模式是出現頻率最高的模式。同時,所有的單例物件被 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_IDLOGIN_ID就是差異化的表現,由各子類負責。

場景 2

閘道器支援灰度釋出,即通過服務分組來將請求路由到指定分組的服務,通過定義模板,獲取分組資訊:group,然後差異化的路由由子類實現,比如:RandomFlowStrategyRoundRobinFlowStrategyWeightedFlowStrategy等。

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

閘道器在處理請求時,預設情況下只打印關鍵資訊到日誌,但是有時為了排查錯誤,需要列印更加豐富的日誌。這是一種動態功能的增強,以開關的形式啟用,關閉。如下,預設情況下RequestEndingHandlerTraceIdElapseTime 返回到客戶端:

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 = '\t';

  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 物件是個大物件,並且對於其中的 requestHeaderresponseBody 構建演算法複雜。

通過構建者模式,將複雜物件從業務中剝離,避免過多的 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();