電子發燒友網>電子資料下載>電子資料>TarsGateway通用API網關

TarsGateway通用API網關

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

普通下載普通下載

資料介紹

授權協議 BSD-3-Clause

開發語言 C/C++

操作系統跨平臺

軟件類型開源軟件

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

軟件簡介

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

支持版本說明

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 是根據請求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 的監控地址，用來遠程判斷服務是否存活。
配置舉例：

    
        
            #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 協議代理

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

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

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

    filterheaders = X-GUID|X-XUA

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

    
        # 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 協議代理

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

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 }

相關參數都在http body中指定：

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

    請求包：
    {
        "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協議代理

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

路由策略

先匹配server_name,再匹配path,然后根據 proxy_pass 路徑進行轉發,具體規則如下：

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

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

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

負載均衡

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

容錯容災

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

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

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

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

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

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