一、背景介紹

網關作為微服務生態(tài)中的重要一環(huán)，由于歷史原因，中間件團隊沒有統(tǒng)一的微服務API網關，為此準備技術預研打造一個功能齊全、可用性高的業(yè)務網關。

二、技術選型

常見的開源網關按照語言分類有如下幾類：

• Nginx Lua：OpenResty、Kong 等；

• Java：Zuul1/Zuul2、Spring Cloud Gateway、gravitee-gateway、Dromara Soul 等；

• Go：janus、GoKu API Gateway 等；

• Node.js：Express Gateway、
  MicroGateway 等。

由于團隊內成員基本上為Java技術棧，因此并不打算深入研究非Java語言的網關。接下來我們主要調研了Zuul1、Zuul2、Spring Cloud Gateway、Dromara Soul。

業(yè)界主流的網關基本上可以分為下面三種：

• Servlet 線程池

• NIO(Tomcat / Jetty) Servlet 3.0 異步

• NettyServer NettyClient

在進行技術選型的時候，主要考慮功能豐富度、性能、穩(wěn)定性。在反復對比之后，決定選擇基于Netty框架進行網關開發(fā)；但是考慮到時間的緊迫性，最終選擇為針對 Zuul2 進行定制化開發(fā)，在 Zuul2 的代碼骨架之上去完善網關的整個體系。

三、Zuul2 介紹

接下來我們簡要介紹一下 Zuul2 關鍵知識點。

Zuul2 的架構圖：

為了解釋上面這張圖，接下來會分別介紹幾個點

• 如何解析 HTTP 協(xié)議

• Zuul2 的數據流轉

• 兩個責任鏈：Netty ChannelPipeline責任鏈 Filter責任鏈

3.1 如何解析 HTTP 協(xié)議

學習Zuul2需要一定的鋪墊知識，比如：Google Guice、RxJava、Netflix archaius等，但是更關鍵的應該是：如何解析HTTP協(xié)議，會影響到后續(xù)Filter責任鏈的原理解析，為此先分析這個關鍵點。

首先我們介紹官方文檔中的一段話：

By default Zuul doesn't buffer body content, meaning it streams the received headers to the origin before the body has been received.

This streaming behavior is very efficient and desirable, as long as your filter logic depends on header data.

翻譯成中文：

默認情況下Zuul2并不會緩存請求體，也就意味著它可能會先發(fā)送接收到的請求Headers到后端服務，之后接收到請求體再繼續(xù)發(fā)送到后端服務，發(fā)送請求體的時候，也不是組裝為一個完整數據之后才發(fā)，而是接收到一部分，就轉發(fā)一部分。

這個流式行為是高效的，只要Filter過濾的時候只依賴Headers的數據進行邏輯處理，而不需要解析RequestBody。

上面這段話映射到Netty Handler中，則意味著Zuul2并沒有使用HttpObjectAggregator。

我們先看一下常規(guī)的Netty Server處理HTTP協(xié)議的樣例：

NettyServer樣例

@Slf4jpublic class ConfigServerBootstrap { public static final int WORKER_THREAD_COUNT = Runtime.getRuntime().availableProcessors(); public void start(){ int port = 8080; EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup(WORKER_THREAD_COUNT); final BizServerHandler bizServerHandler = new BizServerHandler(); try { ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializer() { @Override protected void initChannel(Channel ch) throws Exception { ChannelPipeline pipeline = ch.pipeline(); pipeline.addLast(new IdleStateHandler(10, 10, 0)); pipeline.addLast(new HttpServerCodec()); pipeline.addLast(new HttpObjectAggregator(500 * 1024 * 1024)); pipeline.addLast(bizServerHandler); } }); log.info("start netty server, port:{}", port); serverBootstrap.bind(port).sync(); } catch (InterruptedException e) { bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); log.error(String.format("start netty server error, port:%s", port), e); } }}

這個例子中的兩個關鍵類為：HttpServerCodec、HttpObjectAggregator。

HttpServerCodec是HttpRequestDecoder、HttpResponseEncoder的組合器。

• HttpRequestDecoder職責：將輸入的ByteBuf解析成HttpRequest、HttpContent對象。

• HttpResponseEncoder職責：
  將HttpResponse、HttpContent對象轉換為ByteBuf，進行網絡二進制流的輸出。

HttpObjectAggregator的作用：組裝HttpMessage、HttpContent為一個完整的FullHttpRequest或者FullHttpResponse。

當你不想關心chunked分塊傳輸的時候，使用HttpObjectAggregator是非常有用的。

HTTP協(xié)議通常使用Content-Length來標識body的長度，在服務器端，需要先申請對應長度的buffer，然后再賦值。如果需要一邊生產數據一邊發(fā)送數據，就需要使用"Transfer-Encoding: chunked" 來代替Content-Length，也就是對數據進行分塊傳輸。

接下來我們看一下Zuul2為了解析HTTP協(xié)議做了哪些處理。

Zuul的源碼：https://github.com/Netflix/zuul，基于v2.1.5。

// com.netflix.zuul.netty.server.BaseZuulChannelInitializer#addHttp1Handlersprotected void addHttp1Handlers(ChannelPipeline pipeline) { pipeline.addLast(HTTP_CODEC_HANDLER_NAME, createHttpServerCodec()); pipeline.addLast(new Http1ConnectionCloseHandler(connCloseDelay)); pipeline.addLast("conn_expiry_handler", new Http1ConnectionExpiryHandler(maxRequestsPerConnection, maxRequestsPerConnectionInBrownout, connectionExpiry));}

// com.netflix.zuul.netty.server.BaseZuulChannelInitializer#createHttpServerCodecprotected HttpServerCodec createHttpServerCodec() { return new HttpServerCodec( MAX_INITIAL_LINE_LENGTH.get(), MAX_HEADER_SIZE.get(), MAX_CHUNK_SIZE.get(), false );}

通過對比上面的樣例發(fā)現，Zuul2并沒有添加HttpObjectAggregator，也就是需要自行去處理chunked分塊傳輸問題、自行組裝請求體數據。

為了解決上面說的chunked分塊傳輸問題，Zuul2通過判斷是否LastHttpContent，來判斷是否接收完成。

3.2 Zuul2 數據流轉

如上圖所示，Netty自帶的HttpServerCodec會將網絡二進制流轉換為Netty的HttpRequest對象，再通過ClientRequestReceiver編解碼器將HttpRequest轉換為Zuul的請求對象HttpRequestMessageImpl；

請求體RequestBody在Netty自帶的HttpServerCodec中被映射為HttpContent對象，ClientRequestReceiver編解碼器依次接收HttpContent對象。

完成了上述數據的轉換之后，就流轉到了最重要的編解碼ZuulFilterChainHandler，里面會執(zhí)行Filter鏈，也會發(fā)起網絡請求到真正的后端服務，這一切都是在ZuulFilterChainHandler中完成的。

得到了后端服務的響應結果之后，也經過了Outbound Filter的過濾，接下來就是通過ClientResponseWriter把Zuul自定義的響應對象HttpResponseMessageImpl轉換為Netty的HttpResponse對象，然后通過HttpServerCodec轉換為ByteBuf對象，發(fā)送網絡二進制流，完成響應結果的輸出。

這里需要特別說明的是：由于Zuul2默認不組裝一個完整的請求對象/響應對象，所以Zuul2是分別針對請求頭 請求Headers、請求體進行Filter過濾攔截的，也就是說對于請求，會走兩遍前置Filter鏈，對于響應結果，也是會走兩遍后置Filter鏈攔截。

3.3? 兩個責任鏈

3.3.1?Netty ChannelPipeline責任鏈

Netty的ChannelPipeline設計，通過往ChannelPipeline中動態(tài)增減Handler進行定制擴展。

接下來看一下Zuul2 Netty Server中的pipeline有哪些Handler？

接著繼續(xù)看一下Zuul2 Netty Client的Handler有哪些？

本文不針對具體的Handler進行詳細解釋，主要是給大家一個整體的視圖。

3.3.2?Filter責任鏈

請求發(fā)送到Netty Server中，先進行Inbound Filters的攔截處理，接著會調用Endpoint Filter，這里默認為ProxyEndPoint（里面封裝了Netty Client），發(fā)送請求到真實后端服務，獲取到響應結果之后，再執(zhí)行Outbound Filters，最終返回響應結果。

三種類型的Filter之間是通過nextStage屬性來銜接的。

Zuul2存在一個定時任務線程GroovyFilterFileManagerPoller，定期掃描特定的目錄，通過比對文件的更新時間戳，來判斷是否發(fā)生變化，如果有變化，則重新編譯并放入到內存中。

通過定位任務實現了Filter的動態(tài)加載。

四、功能介紹

上面介紹了Zuul2的部分知識點，接下來介紹網關的整體功能。

4.1?服務注冊發(fā)現

網關承擔了請求轉發(fā)的功能，需要一定的方法用于動態(tài)發(fā)現后端服務的機器列表。

這里提供兩種方式進行服務的注冊發(fā)現：

集成網關SDK

• 網關SDK會在服務啟動之后，監(jiān)聽ContextRefreshedEvent事件，主動操作zk登記信息到zookeeper注冊中心，這樣網關服務、網關管理后臺就可以訂閱節(jié)點信息。
  
  

• 網關SDK添加了ShutdownHook，在服務下線的時候，會刪除登記在zk的節(jié)點信息，用于通知網關服務、網關管理后臺，節(jié)點已下線。

手工配置服務的機器節(jié)點信息

• 在網關管理后臺，手工添加、刪除機器節(jié)點。

• 在網關管理后臺，手工設置節(jié)點上線、節(jié)點下線操。

為了防止zookeeper故障，網關管理后臺已提供HTTP接口用于注冊、取消注冊作為兜底措施。

4.2?動態(tài)路由

動態(tài)路由分為：機房就近路由、灰度路由(類似于Dubbo的標簽路由功能)。

• 機房就近路由：請求最好是不要跨機房，比如請求打到網關服務的X機房，那么也應該是將請求轉發(fā)給X機房的后端服務節(jié)點，如果后端服務不存在X機房的節(jié)點，則請求到其他機房的節(jié)點。
  
  

• 灰度路由：類似于Dubbo的標簽路由功能，如果希望對后端服務節(jié)點進行分組隔離，則需要給后端服務一個標簽名，建立"標簽名→節(jié)點列表"的映射關系，請求方攜帶這個標簽名，請求到相應的后端服務節(jié)點。

網關管理后臺支持動態(tài)配置路由信息，動態(tài)開啟/關閉路由功能。

4.3 負載均衡

當前支持的負載均衡策略：加權隨機算法、加權輪詢算法、一致性哈希算法。

可以通過網關管理后臺動態(tài)調整負載均衡策略，支持API接口級別、應用級別的配置。

負載均衡機制并未采用Netflix Ribbon，而是仿造Dubbo負載均衡的算法實現的。

4.4 動態(tài)配置

API網關支持一套自洽的動態(tài)配置功能，在不依賴第三方配置中心的條件下，仍然支持實時調整配置項，并且配置項分為全局配置、應用級別治理配置、API接口級別治理配置。

在自洽的動態(tài)配置功能之外，網關服務也與公司級別的配置中心進行打通，支持公司級配置中心配置相應的配置項。

4.5 API管理

API管理支持網關SDK自動掃描上報，也支持在管理后臺手工配置。

4.6 協(xié)議轉換

后端的服務有很多是基于Dubbo框架的，網關服務支持HTTP→HTTP的請求轉發(fā)，也支持HTTP→Dubbo的協(xié)議轉換。

同時C 技術棧，采用了tars框架，網關服務也支持HTTP → tras協(xié)議轉換。

4.7 安全機制

API網關提供了IP黑白名單、OAuth認證授權、appKey