gRPC 網(wǎng)關(guān)如何提升 HTTP 2.0 長連接吞吐量
最近要搞個網(wǎng)關(guān)GateWay，由于系統(tǒng)間請求調(diào)用是基于gRPC框架，所以網(wǎng)關(guān)第一職責(zé)就是能接收并轉(zhuǎn)發(fā)gRPC請求，大致的系統(tǒng)架構(gòu)如下所示:
簡單看下即可，由于含有定制化業(yè)務(wù)背景，架構(gòu)圖看不懂也沒關(guān)系，后面我會對里面的核心技術(shù)點(diǎn)單獨(dú)剖析講解
為什么要引入網(wǎng)關(guān)？請求鏈路多了一跳，性能有損耗不說，一旦宕機(jī)就全部玩完了！
但現(xiàn)實(shí)就是這樣，不是你想怎么樣，就能怎么樣！
有時技術(shù)方案繞一個大圈子，就是為了解決一個無法避開的因素。這個因素可能是多方面：
可能是技術(shù)上的需求，比如要做監(jiān)控統(tǒng)計，需要在上層某個位置加個攔截層，收集數(shù)據(jù)，統(tǒng)一處理 可能是技術(shù)實(shí)現(xiàn)遇到巨大挑戰(zhàn)，至少是當(dāng)前技術(shù)團(tuán)隊(duì)研發(fā)實(shí)力解決不了這個難題 可能上下文會話關(guān)聯(lián)，一個任務(wù)要觸發(fā)多次請求，但始終要在一臺機(jī)器上完成全部處理 可能是政策因素，為了數(shù)據(jù)安全，你必須走這一繞。
本文引入的網(wǎng)關(guān)就是安全原因，由于一些公司的安全限制，外部服務(wù)無法直接訪問公司內(nèi)部的計算節(jié)點(diǎn)，需要引入一個前置網(wǎng)關(guān)，負(fù)責(zé)反向代理、請求路由轉(zhuǎn)發(fā)、數(shù)據(jù)通信、調(diào)用監(jiān)控等。
1、問題抽象，技術(shù)選型
上面的業(yè)務(wù)架構(gòu)可能比較復(fù)雜，不了解業(yè)務(wù)背景同學(xué)很容易被繞暈。那么我們簡化一些，抽象出一個具體要解決的問題，簡化描述。
過程分為三步：
1、client端發(fā)起gPRC調(diào)用（基于HTTP2），請求打到gRPC網(wǎng)關(guān)
2、網(wǎng)關(guān)接到請求，根據(jù)請求約定的參數(shù)標(biāo)識，從Redis緩存里查詢目標(biāo)服務(wù)器的映射關(guān)系
3、最后，網(wǎng)關(guān)將請求轉(zhuǎn)發(fā)給目標(biāo)服務(wù)器，獲取響應(yīng)結(jié)果，將數(shù)據(jù)原路返回。
gRPC必須使用 HTTP/2 傳輸數(shù)據(jù)，支持明文和TLS加密數(shù)據(jù)，支持流數(shù)據(jù)的交互。充分利用 HTTP/2 連接的多路復(fù)用和流式特性。
技術(shù)選型
1、最早計劃采用Netty來做，但由于gRPC的proto模板不是我們定義的，所以解析成本很高，另外還要讀取請求Header中的數(shù)據(jù)，開發(fā)難度較大，所以這個便作為了備選方案。
2、另一種改變思路，往反向代理框架方向?qū)ふ?，重新回到主流的Nginx這條線，但是nginx采用C語言開發(fā)，如果是基于常規(guī)的負(fù)載均衡策略轉(zhuǎn)發(fā)請求，倒是沒什么大的問題。但是，我們內(nèi)部有依賴任務(wù)資源關(guān)系，也間接決定著要依賴外部的存儲系統(tǒng)。
Nginx適合處理靜態(tài)內(nèi)容，做一個靜態(tài)web服務(wù)器，但我們又看重其高性能，最后我們選型 Openresty
OpenResty? 是一個基于 Nginx 與 Lua 的高性能 Web 平臺，其內(nèi)部集成了大量精良的 Lua 庫、第三方模塊以及大多數(shù)的依賴項(xiàng)。用于方便地搭建能夠處理超高并發(fā)、擴(kuò)展性極高的動態(tài) Web 應(yīng)用、Web 服務(wù)和動態(tài)網(wǎng)關(guān)。
2、Openresty 代碼 SHOW
http {
include mime.types;
default_type application/octet-stream;
access_log logs/access.log main;
sendfile on;
keepalive_timeout 120;
client_max_body_size 3000M;
server {
listen 8091 http2;
location / {
set $target_url '' ;
access_by_lua_block{
local headers = ngx.req.get_headers(0)
local jobid= headers["jobid"]
local redis = require "resty.redis"
local red = redis:new()
red:set_timeouts(1000) -- 1 sec
local ok, err = red:connect("156.9.1.2", 6379)
local res, err = red:get(jobid)
ngx.var.target_url = res
}
grpc_pass grpc://$target_url;
}
}
}3、性能壓測
1、Client 端機(jī)器，壓測期間，觀察網(wǎng)絡(luò)連接：
結(jié)論：
并發(fā)壓測場景下，請求會轉(zhuǎn)發(fā)到三臺網(wǎng)關(guān)服務(wù)器，每臺服務(wù)器處于TIME_WAIT狀態(tài)的TCP連接并不多。可見此段連接基本能達(dá)到連接復(fù)用效果。
2、gRPC網(wǎng)關(guān)機(jī)器，壓測期間，觀察網(wǎng)絡(luò)連接情況：
有大量的請求連接處于TIME_WAIT狀態(tài)。按照端口號可以分為兩大類：6379和 40928
[root@tf-gw-64bd9f775c-qvpcx nginx]# netstat -na | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
LISTEN 2
ESTABLISHED 6
TIME_WAIT 27500
通過linux shell 統(tǒng)計命令，172.16.66.46服務(wù)器有27500個TCP連接處于 TIME_WAIT
[root@tf-gw-64bd9f775c-qvpcx nginx]# netstat -na | grep 6379 |awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
ESTABLISHED 1
TIME_WAIT 13701
其中，連接redis（redis的訪問端口 6379） 并處于 TIME_WAIT 狀態(tài)有 13701 個連接
[root@tf-gw-64bd9f775c-qvpcx nginx]# netstat -na | grep 40928 |awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
ESTABLISHED 2
TIME_WAIT 13671
其中，連接后端Server目標(biāo)服務(wù)器 并處于 TIME_WAIT 狀態(tài)有 13671 個連接。兩者的連接數(shù)基本相等，因?yàn)槊恳淮无D(zhuǎn)發(fā)請求都要查詢一次Redis。
結(jié)論匯總：
1、client端發(fā)送請求到網(wǎng)關(guān)，目前已經(jīng)維持長連接，滿足要求。
2、gRPC網(wǎng)關(guān)連接Redis緩存服務(wù)器，目前是短連接，每次請求都去創(chuàng)建一個連接，性能開銷太大。需要單獨(dú)優(yōu)化
3、gRPC網(wǎng)關(guān)轉(zhuǎn)發(fā)請求到目標(biāo)服務(wù)器，目前也是短連接，用完即廢棄，完全沒有發(fā)揮Http2.0的長連接優(yōu)勢。需要單獨(dú)優(yōu)化
4、什么是 TIME_WAIT
統(tǒng)計服務(wù)器tcp連接狀態(tài)處于TIME_WAIT的命令腳本：
netstat -anpt | grep TIME_WAIT | wc -l
我們都知道TCP是三次握手，四次揮手。那揮手具體過程是什么？
1、主動關(guān)閉連接的一方，調(diào)用close()，協(xié)議層發(fā)送FIN包，主動關(guān)閉方進(jìn)入FIN_WAIT_1狀態(tài)
2、被動關(guān)閉的一方收到FIN包后，協(xié)議層回復(fù)ACK；然后被動關(guān)閉的一方，進(jìn)入CLOSE_WAIT狀態(tài)，主動關(guān)閉的一方等待對方關(guān)閉，則進(jìn)入FIN_WAIT_2狀態(tài)；此時，主動關(guān)閉的一方 等待 被動關(guān)閉一方的應(yīng)用程序，調(diào)用close()操作
3、被動關(guān)閉的一方在完成所有數(shù)據(jù)發(fā)送后，調(diào)用close()操作；此時，協(xié)議層發(fā)送FIN包給主動關(guān)閉的一方，等待對方的ACK，被動關(guān)閉的一方進(jìn)入LAST_ACK狀態(tài)；
4、主動關(guān)閉的一方收到FIN包，協(xié)議層回復(fù)ACK；此時，主動關(guān)閉連接的一方，進(jìn)入TIME_WAIT狀態(tài)；而被動關(guān)閉的一方，進(jìn)入CLOSED狀態(tài)
5、等待 2MSL（Maximum Segment Lifetime， 報文最大生存時間），主動關(guān)閉的一方，結(jié)束TIME_WAIT，進(jìn)入CLOSED狀態(tài)
2MSL到底有多長呢？這個不一定，1分鐘、2分鐘或者4分鐘，還有的30秒。不同的發(fā)行版可能會不同。在Centos 7.6.1810 的3.10內(nèi)核版本上是60秒。
來張TCP狀態(tài)機(jī)大圖，一目了然：
為什么一定要有 TIME_WAIT ？
雖然雙方都同意關(guān)閉連接了，而且握手的4個報文也都協(xié)調(diào)和發(fā)送完畢，按理可以直接到CLOSED狀態(tài)。但是網(wǎng)絡(luò)是不可靠的，發(fā)起方無法確保最后發(fā)送的ACK報文一定被對方收到，比如丟包或延遲到達(dá)，對方處于LAST_ACK狀態(tài)下的SOCKET可能會因?yàn)槌瑫r未收到ACK報文，而重發(fā)FIN報文。所以TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的ACK報文。
簡單講，TIME_WAIT之所以等待2MSL的時長，是為了避免因?yàn)榫W(wǎng)絡(luò)丟包或者網(wǎng)絡(luò)延遲而造成的tcp傳輸不可靠，而這個TIME_WAIT狀態(tài)則可以最大限度的提升網(wǎng)絡(luò)傳輸?shù)目煽啃浴?/span>
注意：一個連接沒有進(jìn)入 CLOSED 狀態(tài)之前，這個連接是不能被重用的！
如何優(yōu)化 TIME_WAIT 過多的問題
1、調(diào)整系統(tǒng)內(nèi)核參數(shù)
net.ipv4.tcp_syncookies = 1 表示開啟SYN Cookies。當(dāng)出現(xiàn)SYN等待隊(duì)列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認(rèn)為0，表示關(guān)閉；
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將 TIME-WAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉；
net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連接中 TIME-WAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉。
net.ipv4.tcp_fin_timeout = 修改系統(tǒng)默認(rèn)的 TIMEOUT 時間
net.ipv4.tcp_max_tw_buckets = 5000 表示系統(tǒng)同時保持TIME_WAIT套接字的最大數(shù)量，(默認(rèn)是18000). 當(dāng)TIME_WAIT連接數(shù)量達(dá)到給定的值時，所有的TIME_WAIT連接會被立刻清除，并打印警告信息。但這種粗暴的清理掉所有的連接，意味著有些連接并沒有成功等待2MSL，就會造成通訊異常。一般不建議調(diào)整
net.ipv4.tcp_timestamps = 1(默認(rèn)即為1)60s內(nèi)同一源ip主機(jī)的socket connect請求中的timestamp必須是遞增的。也就是說服務(wù)器打開了 tcp_tw_reccycle了，就會檢查時間戳，如果對方發(fā)來的包的時間戳是亂跳的或者說時間戳是滯后的，那么服務(wù)器就會丟掉不回包，現(xiàn)在很多公司都用LVS做負(fù)載均衡，通常是前面一臺LVS，后面多臺后端服務(wù)器，這其實(shí)就是NAT，當(dāng)請求到達(dá)LVS后，它修改地址數(shù)據(jù)后便轉(zhuǎn)發(fā)給后端服務(wù)器，但不會修改時間戳數(shù)據(jù)，對于后端服務(wù)器來說，請求的源地址就是LVS的地址，加上端口會復(fù)用，所以從后端服務(wù)器的角度看，原本不同客戶端的請求經(jīng)過LVS的轉(zhuǎn)發(fā)，就可能會被認(rèn)為是同一個連接，加之不同客戶端的時間可能不一致，所以就會出現(xiàn)時間戳錯亂的現(xiàn)象，于是后面的數(shù)據(jù)包就被丟棄了，具體的表現(xiàn)通常是是客戶端明明發(fā)送的SYN，但服務(wù)端就是不響應(yīng)ACK，還可以通過下面命令來確認(rèn)數(shù)據(jù)包不斷被丟棄的現(xiàn)象，所以根據(jù)情況使用
其他優(yōu)化：
net.ipv4.ip_local_port_range = 1024 65535 ，增加可用端口范圍，讓系統(tǒng)擁有的更多的端口來建立鏈接，這里有個問題需要注意，對于這個設(shè)置系統(tǒng)就會從1025~65535這個范圍內(nèi)隨機(jī)分配端口來用于連接，如果我們服務(wù)的使用端口比如8080剛好在這個范圍之內(nèi)，在升級服務(wù)期間，可能會出現(xiàn)8080端口被其他隨機(jī)分配的鏈接給占用掉
net.ipv4.ip_local_reserved_ports = 7005,8001-8100 針對上面的問題，我們可以設(shè)置這個參數(shù)來告訴系統(tǒng)給我們預(yù)留哪些端口，不可以用于自動分配。
2、將短連接優(yōu)化為長連接
短連接工作模式：連接->傳輸數(shù)據(jù)->關(guān)閉連接
長連接工作模式：連接->傳輸數(shù)據(jù)->保持連接 -> 傳輸數(shù)據(jù)-> 。。。->關(guān)閉連接
5、訪問 Redis 短連接優(yōu)化
高并發(fā)編程中，必須要使用連接池技術(shù)，把短鏈接改成長連接。也就是改成創(chuàng)建連接、收發(fā)數(shù)據(jù)、收發(fā)數(shù)據(jù)... 拆除連接，這樣我們就可以減少大量創(chuàng)建連接、拆除連接的時間。從性能上來說肯定要比短連接好很多
在 OpenResty 中，可以設(shè)置set_keepalive 函數(shù)，來支持長連接。
set_keepalive 函數(shù)有兩個參數(shù)：
第一個參數(shù)：連接的最大空閑時間 第二個參數(shù)：連接池大小
local res, err = red:get(jobid)
// redis操作完后，將連接放回到連接池中
// 連接池大小設(shè)置成40，連接最大空閑時間設(shè)置成10秒
red:set_keepalive(10000, 40)
reload nginx配置后，重新壓測
結(jié)論：redis的連接數(shù)基本控制在40個以內(nèi)。
其他的參數(shù)設(shè)置可以參考：
https://github.com/openresty/lua-resty-redis#set_keepalive
6、訪問目標(biāo) Server 機(jī)器短連接優(yōu)化
nginx 提供了一個upstream模塊，用來控制負(fù)載均衡、內(nèi)容分發(fā)。提供了以下幾種負(fù)載算法：
輪詢（默認(rèn)）。每個請求按時間順序逐一分配到不同的后端服務(wù)器，如果后端服務(wù)器down掉，能自動剔除。 weight(權(quán)重)。指定輪詢幾率，weight和訪問比率成正比，用于后端服務(wù)器性能不均的情況。 ip_hash。每個請求按訪問ip的hash結(jié)果分配，這樣每個訪客固定訪問一個后端服務(wù)器，可以解決session的問題。 fair（第三方）。按后端服務(wù)器的響應(yīng)時間來分配請求，響應(yīng)時間短的優(yōu)先分配。 url_hash（第三方）。按訪問url的hash結(jié)果來分配請求，使每個url定向到同一個后端服務(wù)器，后端服務(wù)器為緩存時比較有效。
由于 upstream提供了keepalive函數(shù)，每個工作進(jìn)程的高速緩存中保留的到上游服務(wù)器的空閑保持連接的最大數(shù)量，可以保持連接復(fù)用，從而減少TCP連接頻繁的創(chuàng)建、銷毀性能開銷。
缺點(diǎn)：
Nginx官方的upstream不支持動態(tài)修改，而我們的目標(biāo)地址是動態(tài)變化，請求時根據(jù)業(yè)務(wù)規(guī)則動態(tài)實(shí)時查詢路由。為了解決這個動態(tài)性問題，我們引入OpenResty的balancer_by_lua_block。
通過編寫Lua腳本方式，來擴(kuò)展upstream功能。
修改nginx.conf的upstream，動態(tài)獲取路由目標(biāo)的IP和Port，并完成請求的轉(zhuǎn)發(fā)，核心代碼如下：
upstream grpcservers {
balancer_by_lua_block{
local balancer = require "ngx.balancer"
local host = ngx.var.target_ip
local port = ngx.var.target_port
local ok, err = balancer.set_current_peer(host, port)
if not ok then
ngx.log(ngx.ERR, "failed to set the current peer: ", err)
return ngx.exit(500)
end
}
keepalive 40;
}
修改配置后，重啟Nginx，繼續(xù)壓測，觀察結(jié)果：
TCP連接基本都處于ESTABLISHED狀態(tài)，優(yōu)化前的TIME_WAIT狀態(tài)幾乎沒有了。
[root@tf-gw-64bd9f775c-qvpcx nginx]# netstat -na | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
LISTEN 2
ESTABLISHED 86
TIME_WAIT 242寫在最后
本文主要是解決gRPC的請求轉(zhuǎn)發(fā)問題，構(gòu)建一個網(wǎng)關(guān)系統(tǒng)，技術(shù)選型OpenResty，既保留了Nginx的高性能又兼具了OpenResty動態(tài)易擴(kuò)展。然后針對編寫的LUA代碼，性能壓測，不斷調(diào)整優(yōu)化，解決各個鏈路區(qū)間的TCP連接保證可重復(fù)使用。