電子發(fā)燒友網(wǎng)>電子資料下載>電子資料>TarsGateway通用API網(wǎng)關

TarsGateway通用API網(wǎng)關

1692746 2022-06-17 | zip | 1.33 MB | 次下載 | 免費

普通下載普通下載

資料介紹

授權協(xié)議 BSD-3-Clause

開發(fā)語言 C/C++

操作系統(tǒng) 跨平臺

軟件類型開源軟件

所屬分類服務器軟件、代理服務器軟件

軟件簡介

TarsGateway是基于tars框架開發(fā)的一套通用api網(wǎng)關，請求為http協(xié)議，后端同時支持tars-tup&tars-tars協(xié)議、tars-json協(xié)議、http協(xié)議。除了協(xié)議轉發(fā)之外，還支持流量控制，黑白名單等功能。

支持版本說明

TarsCpp: >= v2.4.5
TarsJava: >= v1.7.2
TarsGo: >= v1.1.4
TarsNode: rpc: >= v2.0.14, stream: >= v2.0.3, tars2node: >= v20200707
TarsPHP: tars-server: >= v0.6.0

功能介紹

1. 代理類型的判斷

TarsGateway 是根據(jù)請求host+url 判斷當前請求是什么類型的請求，具體host和url通過配置設定。配置及對應邏輯說明如下：

配置所在域： /main/base
tup_host: tup請求對應的host，如果請求host在tup_host列表中，那么會進行后面的tup&&json請求的判斷。如果列表配置為空，那么也會判斷，這里支持前通配符。
tup_path: tup或tars請求的基礎path，默認為 /tup ;
json_path: json 請求的基礎path，默認為 /json ;
monitor_url: TarsGateway 的監(jiān)控地址，用來遠程判斷服務是否存活。
配置舉例：

    
        
            #tup_host 如果不配置，那么所有host開頭的，且沒有path或者path為 / ， 也判斷為 tup 請求
            tup_host=prx.tup.whup.com|prx2.tup.whup.com|*.prx.upchina.com
            tup_path=/tup
            json_path=/json
            monitor_url=/monitor/monitor.html

2. TARS-tup && TARS-tars 協(xié)議代理

TARS-tup協(xié)議代理，必須為post請求類型，路徑為/tup，body內(nèi)容為RequestPacket包tars序列化的內(nèi)容。TarsGateway收到包后，去反序列化body的內(nèi)容解析出RequestPacket包，然后根據(jù)其中的sServantName在配置中查找真是的tars服務的obj。如果配置auto_proxy=1，那么客戶端調(diào)用時 sServantName 可以填真實的obj地址。這里建議：直接對C外網(wǎng)暴露的TarsGateway，建議配置auto_proxy=0，避免內(nèi)網(wǎng)的服務都直接對外暴露。另外，proxy的配置還可以支持 sServerName:sFuncName 的配置，會優(yōu)先根據(jù), 這種類型配置優(yōu)先級高于只配置sServerName 類型的配置。 proxy配置如下：

    
        hello = TestApp.HelloServer.HelloObj
        hello:sayhello = TestApp.Hello2Server.HelloObj

經(jīng)過TarsGateway調(diào)用后端服務，客戶端請求的http頭，可以通過配置采用tars的context進行http頭的透傳，默認情況下，REMOTE_IP （客戶端ip）都會透傳給后端。配置為 filterheaders，可以是多個，比如：

    filterheaders = X-GUID|X-XUA

調(diào)用后端tars服務時，TarsGateway默認采用tars自己的缺省輪訓負載均衡策略（robin輪訓），也可以通過配置自定義hash策略，hash_type為1時，根據(jù)客戶端請求id進行tarshash調(diào)用; hash_type為2時，根據(jù)指定http頭(配種中的httpheader)進行tarshash調(diào)用，比如http頭中的 X-GUID，注意這里選擇httpheader需要合理，避免過于集中某個值導致負載均衡過于不均勻的現(xiàn)象； hash_type為3時，則根據(jù)客戶端的ip進行tarshash調(diào)用。如果obj后面沒有配置hash_type，那么采用tars默認輪訓調(diào)用。配置舉例如下：

    
        # servant = server_full_obj [| hash_type [| http header key] ]
        # hash_type: 0, 輪訓; 1: requestid, 2: http頭, 3: client ip
        # Hello=TestApp.HelloServer.HelloObj | 1
        # Hello=TestApp.HelloServer.HelloObj | 2 | X-GUID
        # Hello=TestApp.HelloServer.HelloObj | 3
        hello = TestApp.HelloServer.HelloObj | 3
        hello:sayhello = TestApp.Hello2Server.HelloObj

3. TARS-JSON 協(xié)議代理

TARS-JSON協(xié)議代理，支持兩種類型的接口。

servantName和funcName在http url路徑中指定

路徑為/json/servantName/funcName，其中/json是固定的，后面分別是servantName 和 funcName。

    請求：
    url： http://xx.xx.com/json/Test.GetSumServer.GetSumObj/getSumEx
    {"req":{"userKey":"upchina","userToken":"upchinatoken","x":1,"y":9900989}}

    響應：
    { "rsp": { "otherMsg": [ "1 + 9900989 = 9900990" ], "msg": "succ.", "sum": 9900990, "ret": 0 }, "": 0 }

相關參數(shù)都在http body中指定：

必須為post請求類型，路徑為/json，body內(nèi)容為json結構。其中必須有reqid, obj, func, data 四個字段，分別表示請求id、服務servant、服務接口、接口參數(shù)，對應RequestPacket中的reqid:iRequestId, obj:sServantName, func:sFuncName。data內(nèi)容為接口中的參數(shù)，key為參數(shù)名，value為參數(shù)內(nèi)容。除了以上必選四個字段之外，context為可選字段。回包內(nèi)容包括 reqid 和 data， data為接口出參內(nèi)容，其中 "" 的key對應內(nèi)容為函數(shù)返回值。這里除了這里包格式不一樣，其他后面的邏輯都和TARS-tup類型一樣。請求參數(shù)舉例如下：

    請求包：
    {
        "reqid": 99999,
        "obj": "getsum",
        "func": "getSumEx",
        "data": "{"req":{"userKey":"upchina","userToken":"upchinatoken","x":1,"y":9900989}}"
    }
    響應包：
    { 
        "data": "{ "rsp": { "otherMsg": [ "1 + 9900989 = 9900990" ], "msg": "succ.", "sum": 9900990, "ret": 0 }, "": 0 }", 
        "reqid": 99999 
    }

4. 普通HTTP協(xié)議代理

普通HTTP協(xié)議代理，類似nginx的反向代理功能，主要功能包括根據(jù)domain和url進行請求轉發(fā)，后端負載均衡，容錯容災，黑名單屏蔽，流量控制等功能。

路由策略

先匹配server_name,再匹配path,然后根據(jù) proxy_pass 路徑進行轉發(fā),具體規(guī)則如下：

server_name 匹配邏輯：
{
	1、查找全匹配
	2、通配符在前匹配
	3、通配符在后面匹配
	4、正則匹配
	5、如果server_name為空， 則默認都匹配
}

path 匹配邏輯：
{
	1、= 全匹配：  /login
	2、^~ uri以某個常規(guī)字符串開頭： ^~ /static/   （一旦匹配成功， 不再往后面匹配）
	3、~ 正則匹配(區(qū)分大小寫)：  ~ \.(gif|jpg|png|js|css)$  （正則表達式匹配多個的情況下， 按最長的匹配）
	4、~* 正則匹配(不區(qū)分大小寫)：~* \.png$
	5、!~和!~*分別為區(qū)分大小寫不匹配及不區(qū)分大小寫不匹配 的正則：  !~ \.xhtml$，  !~* \.xhtml$
	6、/xxx 從頭開始匹配路徑（匹配長度越長優(yōu)先級越高）
	7、/ 任何請求都會匹配
}

proxy_pass:
{
	1、如果proxy_pass配置中沒有路徑（http://host/ 這個是有路徑的 /），這時候 location 匹配的完整路徑將直接透傳給 url 
	2、proxy_pass配置中包含路徑（哪怕只有一個 / ， 也算）， 新路徑 = proxypassPath + (訪問路徑-location路徑)
	3、當 location 中為正則時， proxy_pass 不能帶路徑
}

負載均衡

支持普通輪訓和帶權重輪訓策略，默認權重（weight）為1，數(shù)據(jù)越大，權重越高。權重表示在一次輪訓周期內(nèi)輪訓的次數(shù)。

容錯容災

當后端節(jié)點為多個節(jié)點時（大于等于2個節(jié)點），可以支持后端熔斷策略，這里是否進行熔斷可以配置，默認是打開的。

失效屏蔽：如果出現(xiàn)連接出錯，那么就會直接臨時屏蔽該節(jié)點，對應inactive配置，其中的值為RequestCallback::FAILED_CODE類型。加入到失效的節(jié)點，如果該站點配置了monitor_url，那么會定時輪訓該url，如果出現(xiàn)http 200，那么恢復該節(jié)點，輪訓檢測間隔遞增，最大為2分鐘。如果沒有配置 monitor_url, 那么直接connect該節(jié)點的ip:port，能夠正常連接，那么恢復該節(jié)點。

超時切換：當超時次數(shù)在指定時間窗口達到一定閾值時，或者超過一定比例時，那么臨時屏蔽一段時間，一定時間后會嘗試超時恢復。

        配置如下：
        
            # 定義哪些返回碼做超時容錯處理，哪些返回碼做出錯容災處理
            inactive=2|6
            timeout=1|3
        

        RequestCallback::FAILED_CODE類型定義如下： 
        enum FAILED_CODE
        {
            Failed_Net     = 0x01,      //網(wǎng)絡出錯
            Failed_Connect = 0x02,      //連接服務器出錯
            Failed_Timeout = 0x03,      //超時
            Failed_Interrupt = 0x04,    //中斷接收數(shù)據(jù)
            Failed_Close    = 0x05,     //服務器主動關閉了鏈接
            Failed_ConnectTimeout = 0x06, //鏈接超時
        };

IP黑名單和流控策略，同時支持TarsGateway的三種協(xié)議，所以后面統(tǒng)一介紹。

5. 流量控制

可以支持訪問TarsGateway 訪問后端進行流量控制，支持單機控制，也支持多機協(xié)同控制，也可以關閉流控。

開關控制:?配置flow_control_onoff可以對流控進行開關控制。另外如果服務servant沒有配置FlowControlObj，那么就不會開啟流控策略。

流控策略:?一定時間內(nèi)最多訪問多少次, 通過時間滑動窗口動態(tài)控制，滑動窗口大小為1s，超過次數(shù)則直接返回http 403。

多機協(xié)同:?配置了tup_report_obj，那么會通過該obj進行多機協(xié)同流量控制，否則進行單機控制。注意，如果是單機的策略，那么流控配置的一定時間內(nèi)最多可以訪問多少次就是單機最多可以訪問該站點多少次；如果是多機協(xié)同，那么就是多機同時允許訪問該站點多少次。

配置說明:?如果是TARS-tup或者TARS-JSON協(xié)議，那么流控的站點ID為服務Obj，如果是http協(xié)議，那么站點ID為配置中的stationId.