vivo億級(jí)微服務(wù)?API?網(wǎng)關(guān)架構(gòu)實(shí)踐
[導(dǎo)讀]一、背景介紹網(wǎng)關(guān)作為微服務(wù)生態(tài)中的重要一環(huán)，由于歷史原因，中間件團(tuán)隊(duì)沒有統(tǒng)一的微服務(wù)API網(wǎng)關(guān)，為此準(zhǔn)備技術(shù)預(yù)研打造一個(gè)功能齊全、可用性高的業(yè)務(wù)網(wǎng)關(guān)。二、技術(shù)選型常見的開源網(wǎng)關(guān)按照語言分類有如下幾類：NginxLua：OpenResty、Kong等；Java：Zuul1/Zuul...
一、背景介紹
網(wǎng)關(guān)作為微服務(wù)生態(tài)中的重要一環(huán)，由于歷史原因，中間件團(tuán)隊(duì)沒有統(tǒng)一的微服務(wù)API網(wǎng)關(guān)，為此準(zhǔn)備技術(shù)預(yù)研打造一個(gè)功能齊全、可用性高的業(yè)務(wù)網(wǎng)關(guān)。
二、技術(shù)選型
常見的開源網(wǎng)關(guān)按照語言分類有如下幾類：
由于團(tuán)隊(duì)內(nèi)成員基本上為Java技術(shù)棧，因此并不打算深入研究非Java語言的網(wǎng)關(guān)。接下來我們主要調(diào)研了Zuul1、Zuul2、Spring Cloud Gateway、Dromara Soul。
業(yè)界主流的網(wǎng)關(guān)基本上可以分為下面三種：
在進(jìn)行技術(shù)選型的時(shí)候，主要考慮功能豐富度、性能、穩(wěn)定性。在反復(fù)對(duì)比之后，決定選擇基于Netty框架進(jìn)行網(wǎng)關(guān)開發(fā)；但是考慮到時(shí)間的緊迫性，最終選擇為針對(duì) Zuul2 進(jìn)行定制化開發(fā)，在 Zuul2 的代碼骨架之上去完善網(wǎng)關(guān)的整個(gè)體系。
三、Zuul2 介紹
接下來我們簡(jiǎn)要介紹一下 Zuul2 關(guān)鍵知識(shí)點(diǎn)。
Zuul2 的架構(gòu)圖：
為了解釋上面這張圖，接下來會(huì)分別介紹幾個(gè)點(diǎn)
3.1 如何解析 HTTP 協(xié)議
學(xué)習(xí)Zuul2需要一定的鋪墊知識(shí)，比如：Google Guice、RxJava、Netflix archaius等，但是更關(guān)鍵的應(yīng)該是：如何解析HTTP協(xié)議，會(huì)影響到后續(xù)Filter責(zé)任鏈的原理解析，為此先分析這個(gè)關(guān)鍵點(diǎn)。
首先我們介紹官方文檔中的一段話：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.
翻譯成中文：默認(rèn)情況下Zuul2并不會(huì)緩存請(qǐng)求體，也就意味著它可能會(huì)先發(fā)送接收到的請(qǐng)求Headers到后端服務(wù)，之后接收到請(qǐng)求體再繼續(xù)發(fā)送到后端服務(wù)，發(fā)送請(qǐng)求體的時(shí)候，也不是組裝為一個(gè)完整數(shù)據(jù)之后才發(fā)，而是接收到一部分，就轉(zhuǎn)發(fā)一部分。
這個(gè)流式行為是高效的，只要Filter過濾的時(shí)候只依賴Headers的數(shù)據(jù)進(jìn)行邏輯處理，而不需要解析RequestBody。
上面這段話映射到Netty Handler中，則意味著Zuul2并沒有使用HttpObjectAggregator。
我們先看一下常規(guī)的Netty Server處理HTTP協(xié)議的樣例：
NettyServer樣例
這個(gè)例子中的兩個(gè)關(guān)鍵類為：HttpServerCodec、HttpObjectAggregator。
HttpServerCodec是HttpRequestDecoder、HttpResponseEncoder的組合器。
HttpObjectAggregator的作用：組裝HttpMessage、HttpContent為一個(gè)完整的FullHttpRequest或者FullHttpResponse。
當(dāng)你不想關(guān)心chunked分塊傳輸?shù)臅r(shí)候，使用HttpObjectAggregator是非常有用的。
HTTP協(xié)議通常使用Content-Length來標(biāo)識(shí)body的長度，在服務(wù)器端，需要先申請(qǐng)對(duì)應(yīng)長度的buffer，然后再賦值。如果需要一邊生產(chǎn)數(shù)據(jù)一邊發(fā)送數(shù)據(jù)，就需要使用"Transfer-Encoding: chunked" 來代替Content-Length，也就是對(duì)數(shù)據(jù)進(jìn)行分塊傳輸。
接下來我們看一下Zuul2為了解析HTTP協(xié)議做了哪些處理。
Zuul的源碼：https://github.com/Netflix/zuul，基于v2.1.5。
通過對(duì)比上面的樣例發(fā)現(xiàn)，Zuul2并沒有添加HttpObjectAggregator，也就是需要自行去處理chunked分塊傳輸問題、自行組裝請(qǐng)求體數(shù)據(jù)。
為了解決上面說的chunked分塊傳輸問題，Zuul2通過判斷是否LastHttpContent，來判斷是否接收完成。
3.2 Zuul2 數(shù)據(jù)流轉(zhuǎn)
如上圖所示，Netty自帶的HttpServerCodec會(huì)將網(wǎng)絡(luò)二進(jìn)制流轉(zhuǎn)換為Netty的HttpRequest對(duì)象，再通過ClientRequestReceiver編解碼器將HttpRequest轉(zhuǎn)換為Zuul的請(qǐng)求對(duì)象HttpRequestMessageImpl；
請(qǐng)求體RequestBody在Netty自帶的HttpServerCodec中被映射為HttpContent對(duì)象，ClientRequestReceiver編解碼器依次接收HttpContent對(duì)象。
完成了上述數(shù)據(jù)的轉(zhuǎn)換之后，就流轉(zhuǎn)到了最重要的編解碼ZuulFilterChainHandler，里面會(huì)執(zhí)行Filter鏈，也會(huì)發(fā)起網(wǎng)絡(luò)請(qǐng)求到真正的后端服務(wù)，這一切都是在ZuulFilterChainHandler中完成的。
得到了后端服務(wù)的響應(yīng)結(jié)果之后，也經(jīng)過了Outbound Filter的過濾，接下來就是通過ClientResponseWriter把Zuul自定義的響應(yīng)對(duì)象HttpResponseMessageImpl轉(zhuǎn)換為Netty的HttpResponse對(duì)象，然后通過HttpServerCodec轉(zhuǎn)換為ByteBuf對(duì)象，發(fā)送網(wǎng)絡(luò)二進(jìn)制流，完成響應(yīng)結(jié)果的輸出。
這里需要特別說明的是：由于Zuul2默認(rèn)不組裝一個(gè)完整的請(qǐng)求對(duì)象/響應(yīng)對(duì)象，所以Zuul2是分別針對(duì)請(qǐng)求頭 請(qǐng)求Headers、請(qǐng)求體進(jìn)行Filter過濾攔截的，也就是說對(duì)于請(qǐng)求，會(huì)走兩遍前置Filter鏈，對(duì)于響應(yīng)結(jié)果，也是會(huì)走兩遍后置Filter鏈攔截。
3.3? 兩個(gè)責(zé)任鏈
3.3.1?Netty ChannelPipeline責(zé)任鏈
Netty的ChannelPipeline設(shè)計(jì)，通過往ChannelPipeline中動(dòng)態(tài)增減Handler進(jìn)行定制擴(kuò)展。
接下來看一下Zuul2 Netty Server中的pipeline有哪些Handler？
接著繼續(xù)看一下Zuul2 Netty Client的Handler有哪些？
本文不針對(duì)具體的Handler進(jìn)行詳細(xì)解釋，主要是給大家一個(gè)整體的視圖。
3.3.2?Filter責(zé)任鏈
請(qǐng)求發(fā)送到Netty Server中，先進(jìn)行Inbound Filters的攔截處理，接著會(huì)調(diào)用Endpoint Filter，這里默認(rèn)為ProxyEndPoint（里面封裝了Netty Client），發(fā)送請(qǐng)求到真實(shí)后端服務(wù)，獲取到響應(yīng)結(jié)果之后，再執(zhí)行Outbound Filters，最終返回響應(yīng)結(jié)果。
三種類型的Filter之間是通過nextStage屬性來銜接的。
Zuul2存在一個(gè)定時(shí)任務(wù)線程GroovyFilterFileManagerPoller，定期掃描特定的目錄，通過比對(duì)文件的更新時(shí)間戳，來判斷是否發(fā)生變化，如果有變化，則重新編譯并放入到內(nèi)存中。
通過定位任務(wù)實(shí)現(xiàn)了Filter的動(dòng)態(tài)加載。
四、功能介紹
上面介紹了Zuul2的部分知識(shí)點(diǎn)，接下來介紹網(wǎng)關(guān)的整體功能。
4.1?服務(wù)注冊(cè)發(fā)現(xiàn)
網(wǎng)關(guān)承擔(dān)了請(qǐng)求轉(zhuǎn)發(fā)的功能，需要一定的方法用于動(dòng)態(tài)發(fā)現(xiàn)后端服務(wù)的機(jī)器列表。
這里提供兩種方式進(jìn)行服務(wù)的注冊(cè)發(fā)現(xiàn)：
集成網(wǎng)關(guān)SDK
手工配置服務(wù)的機(jī)器節(jié)點(diǎn)信息
為了防止zookeeper故障，網(wǎng)關(guān)管理后臺(tái)已提供HTTP接口用于注冊(cè)、取消注冊(cè)作為兜底措施。
4.2?動(dòng)態(tài)路由
動(dòng)態(tài)路由分為：機(jī)房就近路由、灰度路由(類似于Dubbo的標(biāo)簽路由功能)。
網(wǎng)關(guān)管理后臺(tái)支持動(dòng)態(tài)配置路由信息，動(dòng)態(tài)開啟/關(guān)閉路由功能。
4.3 負(fù)載均衡
當(dāng)前支持的負(fù)載均衡策略：加權(quán)隨機(jī)算法、加權(quán)輪詢算法、一致性哈希算法。
可以通過網(wǎng)關(guān)管理后臺(tái)動(dòng)態(tài)調(diào)整負(fù)載均衡策略，支持API接口級(jí)別、應(yīng)用級(jí)別的配置。
負(fù)載均衡機(jī)制并未采用Netflix Ribbon，而是仿造Dubbo負(fù)載均衡的算法實(shí)現(xiàn)的。
4.4 動(dòng)態(tài)配置
API網(wǎng)關(guān)支持一套自洽的動(dòng)態(tài)配置功能，在不依賴第三方配置中心的條件下，仍然支持實(shí)時(shí)調(diào)整配置項(xiàng)，并且配置項(xiàng)分為全局配置、應(yīng)用級(jí)別治理配置、API接口級(jí)別治理配置。
在自洽的動(dòng)態(tài)配置功能之外，網(wǎng)關(guān)服務(wù)也與公司級(jí)別的配置中心進(jìn)行打通，支持公司級(jí)配置中心配置相應(yīng)的配置項(xiàng)。
4.5 API管理
API管理支持網(wǎng)關(guān)SDK自動(dòng)掃描上報(bào)，也支持在管理后臺(tái)手工配置。
4.6 協(xié)議轉(zhuǎn)換
后端的服務(wù)有很多是基于Dubbo框架的，網(wǎng)關(guān)服務(wù)支持HTTP→HTTP的請(qǐng)求轉(zhuǎn)發(fā)，也支持HTTP→Dubbo的協(xié)議轉(zhuǎn)換。
同時(shí)C 技術(shù)棧，采用了tars框架，網(wǎng)關(guān)服務(wù)也支持HTTP → tras協(xié)議轉(zhuǎn)換。
4.7 安全機(jī)制
API網(wǎng)關(guān)提供了IP黑白名單、OAuth認(rèn)證授權(quán)、appKey
網(wǎng)關(guān)作為微服務(wù)生態(tài)中的重要一環(huán)，由于歷史原因，中間件團(tuán)隊(duì)沒有統(tǒng)一的微服務(wù)API網(wǎng)關(guān)，為此準(zhǔn)備技術(shù)預(yù)研打造一個(gè)功能齊全、可用性高的業(yè)務(wù)網(wǎng)關(guān)。
二、技術(shù)選型
常見的開源網(wǎng)關(guān)按照語言分類有如下幾類：
- Nginx Lua：OpenResty、Kong 等；
- Java：Zuul1/Zuul2、Spring Cloud Gateway、gravitee-gateway、Dromara Soul 等；
- Go：janus、GoKu API Gateway 等；
- Node.js：Express Gateway、MicroGateway 等。
由于團(tuán)隊(duì)內(nèi)成員基本上為Java技術(shù)棧，因此并不打算深入研究非Java語言的網(wǎng)關(guān)。接下來我們主要調(diào)研了Zuul1、Zuul2、Spring Cloud Gateway、Dromara Soul。
業(yè)界主流的網(wǎng)關(guān)基本上可以分為下面三種：
- Servlet 線程池
- NIO(Tomcat / Jetty) Servlet 3.0 異步
- NettyServer NettyClient
在進(jìn)行技術(shù)選型的時(shí)候，主要考慮功能豐富度、性能、穩(wěn)定性。在反復(fù)對(duì)比之后，決定選擇基于Netty框架進(jìn)行網(wǎng)關(guān)開發(fā)；但是考慮到時(shí)間的緊迫性，最終選擇為針對(duì) Zuul2 進(jìn)行定制化開發(fā)，在 Zuul2 的代碼骨架之上去完善網(wǎng)關(guān)的整個(gè)體系。
三、Zuul2 介紹
接下來我們簡(jiǎn)要介紹一下 Zuul2 關(guān)鍵知識(shí)點(diǎn)。
Zuul2 的架構(gòu)圖：
為了解釋上面這張圖，接下來會(huì)分別介紹幾個(gè)點(diǎn)
- 如何解析 HTTP 協(xié)議
- Zuul2 的數(shù)據(jù)流轉(zhuǎn)
- 兩個(gè)責(zé)任鏈：Netty ChannelPipeline責(zé)任鏈 Filter責(zé)任鏈
3.1 如何解析 HTTP 協(xié)議
學(xué)習(xí)Zuul2需要一定的鋪墊知識(shí)，比如：Google Guice、RxJava、Netflix archaius等，但是更關(guān)鍵的應(yīng)該是：如何解析HTTP協(xié)議，會(huì)影響到后續(xù)Filter責(zé)任鏈的原理解析，為此先分析這個(gè)關(guān)鍵點(diǎn)。
首先我們介紹官方文檔中的一段話：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.
翻譯成中文：默認(rèn)情況下Zuul2并不會(huì)緩存請(qǐng)求體，也就意味著它可能會(huì)先發(fā)送接收到的請(qǐng)求Headers到后端服務(wù)，之后接收到請(qǐng)求體再繼續(xù)發(fā)送到后端服務(wù)，發(fā)送請(qǐng)求體的時(shí)候，也不是組裝為一個(gè)完整數(shù)據(jù)之后才發(fā)，而是接收到一部分，就轉(zhuǎn)發(fā)一部分。
這個(gè)流式行為是高效的，只要Filter過濾的時(shí)候只依賴Headers的數(shù)據(jù)進(jìn)行邏輯處理，而不需要解析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); } }}這個(gè)例子中的兩個(gè)關(guān)鍵類為：HttpServerCodec、HttpObjectAggregator。
HttpServerCodec是HttpRequestDecoder、HttpResponseEncoder的組合器。
- HttpRequestDecoder職責(zé)：將輸入的ByteBuf解析成HttpRequest、HttpContent對(duì)象。
- HttpResponseEncoder職責(zé)：將HttpResponse、HttpContent對(duì)象轉(zhuǎn)換為ByteBuf，進(jìn)行網(wǎng)絡(luò)二進(jìn)制流的輸出。
HttpObjectAggregator的作用：組裝HttpMessage、HttpContent為一個(gè)完整的FullHttpRequest或者FullHttpResponse。
當(dāng)你不想關(guān)心chunked分塊傳輸?shù)臅r(shí)候，使用HttpObjectAggregator是非常有用的。
HTTP協(xié)議通常使用Content-Length來標(biāo)識(shí)body的長度，在服務(wù)器端，需要先申請(qǐng)對(duì)應(yīng)長度的buffer，然后再賦值。如果需要一邊生產(chǎn)數(shù)據(jù)一邊發(fā)送數(shù)據(jù)，就需要使用"Transfer-Encoding: chunked" 來代替Content-Length，也就是對(duì)數(shù)據(jù)進(jìn)行分塊傳輸。
接下來我們看一下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 );}通過對(duì)比上面的樣例發(fā)現(xiàn)，Zuul2并沒有添加HttpObjectAggregator，也就是需要自行去處理chunked分塊傳輸問題、自行組裝請(qǐng)求體數(shù)據(jù)。
為了解決上面說的chunked分塊傳輸問題，Zuul2通過判斷是否LastHttpContent，來判斷是否接收完成。
3.2 Zuul2 數(shù)據(jù)流轉(zhuǎn)
如上圖所示，Netty自帶的HttpServerCodec會(huì)將網(wǎng)絡(luò)二進(jìn)制流轉(zhuǎn)換為Netty的HttpRequest對(duì)象，再通過ClientRequestReceiver編解碼器將HttpRequest轉(zhuǎn)換為Zuul的請(qǐng)求對(duì)象HttpRequestMessageImpl；
請(qǐng)求體RequestBody在Netty自帶的HttpServerCodec中被映射為HttpContent對(duì)象，ClientRequestReceiver編解碼器依次接收HttpContent對(duì)象。
完成了上述數(shù)據(jù)的轉(zhuǎn)換之后，就流轉(zhuǎn)到了最重要的編解碼ZuulFilterChainHandler，里面會(huì)執(zhí)行Filter鏈，也會(huì)發(fā)起網(wǎng)絡(luò)請(qǐng)求到真正的后端服務(wù)，這一切都是在ZuulFilterChainHandler中完成的。
得到了后端服務(wù)的響應(yīng)結(jié)果之后，也經(jīng)過了Outbound Filter的過濾，接下來就是通過ClientResponseWriter把Zuul自定義的響應(yīng)對(duì)象HttpResponseMessageImpl轉(zhuǎn)換為Netty的HttpResponse對(duì)象，然后通過HttpServerCodec轉(zhuǎn)換為ByteBuf對(duì)象，發(fā)送網(wǎng)絡(luò)二進(jìn)制流，完成響應(yīng)結(jié)果的輸出。
這里需要特別說明的是：由于Zuul2默認(rèn)不組裝一個(gè)完整的請(qǐng)求對(duì)象/響應(yīng)對(duì)象，所以Zuul2是分別針對(duì)請(qǐng)求頭 請(qǐng)求Headers、請(qǐng)求體進(jìn)行Filter過濾攔截的，也就是說對(duì)于請(qǐng)求，會(huì)走兩遍前置Filter鏈，對(duì)于響應(yīng)結(jié)果，也是會(huì)走兩遍后置Filter鏈攔截。
3.3? 兩個(gè)責(zé)任鏈
3.3.1?Netty ChannelPipeline責(zé)任鏈
Netty的ChannelPipeline設(shè)計(jì)，通過往ChannelPipeline中動(dòng)態(tài)增減Handler進(jìn)行定制擴(kuò)展。
接下來看一下Zuul2 Netty Server中的pipeline有哪些Handler？
接著繼續(xù)看一下Zuul2 Netty Client的Handler有哪些？
本文不針對(duì)具體的Handler進(jìn)行詳細(xì)解釋，主要是給大家一個(gè)整體的視圖。
3.3.2?Filter責(zé)任鏈
請(qǐng)求發(fā)送到Netty Server中，先進(jìn)行Inbound Filters的攔截處理，接著會(huì)調(diào)用Endpoint Filter，這里默認(rèn)為ProxyEndPoint（里面封裝了Netty Client），發(fā)送請(qǐng)求到真實(shí)后端服務(wù)，獲取到響應(yīng)結(jié)果之后，再執(zhí)行Outbound Filters，最終返回響應(yīng)結(jié)果。
三種類型的Filter之間是通過nextStage屬性來銜接的。
Zuul2存在一個(gè)定時(shí)任務(wù)線程GroovyFilterFileManagerPoller，定期掃描特定的目錄，通過比對(duì)文件的更新時(shí)間戳，來判斷是否發(fā)生變化，如果有變化，則重新編譯并放入到內(nèi)存中。
通過定位任務(wù)實(shí)現(xiàn)了Filter的動(dòng)態(tài)加載。
四、功能介紹
上面介紹了Zuul2的部分知識(shí)點(diǎn)，接下來介紹網(wǎng)關(guān)的整體功能。
4.1?服務(wù)注冊(cè)發(fā)現(xiàn)
網(wǎng)關(guān)承擔(dān)了請(qǐng)求轉(zhuǎn)發(fā)的功能，需要一定的方法用于動(dòng)態(tài)發(fā)現(xiàn)后端服務(wù)的機(jī)器列表。
這里提供兩種方式進(jìn)行服務(wù)的注冊(cè)發(fā)現(xiàn)：
集成網(wǎng)關(guān)SDK
- 網(wǎng)關(guān)SDK會(huì)在服務(wù)啟動(dòng)之后，監(jiān)聽ContextRefreshedEvent事件，主動(dòng)操作zk登記信息到zookeeper注冊(cè)中心，這樣網(wǎng)關(guān)服務(wù)、網(wǎng)關(guān)管理后臺(tái)就可以訂閱節(jié)點(diǎn)信息。
- 網(wǎng)關(guān)SDK添加了ShutdownHook，在服務(wù)下線的時(shí)候，會(huì)刪除登記在zk的節(jié)點(diǎn)信息，用于通知網(wǎng)關(guān)服務(wù)、網(wǎng)關(guān)管理后臺(tái)，節(jié)點(diǎn)已下線。
手工配置服務(wù)的機(jī)器節(jié)點(diǎn)信息
- 在網(wǎng)關(guān)管理后臺(tái)，手工添加、刪除機(jī)器節(jié)點(diǎn)。
- 在網(wǎng)關(guān)管理后臺(tái)，手工設(shè)置節(jié)點(diǎn)上線、節(jié)點(diǎn)下線操。
為了防止zookeeper故障，網(wǎng)關(guān)管理后臺(tái)已提供HTTP接口用于注冊(cè)、取消注冊(cè)作為兜底措施。
4.2?動(dòng)態(tài)路由
動(dòng)態(tài)路由分為：機(jī)房就近路由、灰度路由(類似于Dubbo的標(biāo)簽路由功能)。
- 機(jī)房就近路由：請(qǐng)求最好是不要跨機(jī)房，比如請(qǐng)求打到網(wǎng)關(guān)服務(wù)的X機(jī)房，那么也應(yīng)該是將請(qǐng)求轉(zhuǎn)發(fā)給X機(jī)房的后端服務(wù)節(jié)點(diǎn)，如果后端服務(wù)不存在X機(jī)房的節(jié)點(diǎn)，則請(qǐng)求到其他機(jī)房的節(jié)點(diǎn)。
- 灰度路由：類似于Dubbo的標(biāo)簽路由功能，如果希望對(duì)后端服務(wù)節(jié)點(diǎn)進(jìn)行分組隔離，則需要給后端服務(wù)一個(gè)標(biāo)簽名，建立"標(biāo)簽名→節(jié)點(diǎn)列表"的映射關(guān)系，請(qǐng)求方攜帶這個(gè)標(biāo)簽名，請(qǐng)求到相應(yīng)的后端服務(wù)節(jié)點(diǎn)。
網(wǎng)關(guān)管理后臺(tái)支持動(dòng)態(tài)配置路由信息，動(dòng)態(tài)開啟/關(guān)閉路由功能。
4.3 負(fù)載均衡
當(dāng)前支持的負(fù)載均衡策略：加權(quán)隨機(jī)算法、加權(quán)輪詢算法、一致性哈希算法。
可以通過網(wǎng)關(guān)管理后臺(tái)動(dòng)態(tài)調(diào)整負(fù)載均衡策略，支持API接口級(jí)別、應(yīng)用級(jí)別的配置。
負(fù)載均衡機(jī)制并未采用Netflix Ribbon，而是仿造Dubbo負(fù)載均衡的算法實(shí)現(xiàn)的。
4.4 動(dòng)態(tài)配置
API網(wǎng)關(guān)支持一套自洽的動(dòng)態(tài)配置功能，在不依賴第三方配置中心的條件下，仍然支持實(shí)時(shí)調(diào)整配置項(xiàng)，并且配置項(xiàng)分為全局配置、應(yīng)用級(jí)別治理配置、API接口級(jí)別治理配置。
在自洽的動(dòng)態(tài)配置功能之外，網(wǎng)關(guān)服務(wù)也與公司級(jí)別的配置中心進(jìn)行打通，支持公司級(jí)配置中心配置相應(yīng)的配置項(xiàng)。
4.5 API管理
API管理支持網(wǎng)關(guān)SDK自動(dòng)掃描上報(bào)，也支持在管理后臺(tái)手工配置。
4.6 協(xié)議轉(zhuǎn)換
后端的服務(wù)有很多是基于Dubbo框架的，網(wǎng)關(guān)服務(wù)支持HTTP→HTTP的請(qǐng)求轉(zhuǎn)發(fā)，也支持HTTP→Dubbo的協(xié)議轉(zhuǎn)換。
同時(shí)C 技術(shù)棧，采用了tars框架，網(wǎng)關(guān)服務(wù)也支持HTTP → tras協(xié)議轉(zhuǎn)換。
4.7 安全機(jī)制
API網(wǎng)關(guān)提供了IP黑白名單、OAuth認(rèn)證授權(quán)、appKey
下載文檔
