騰訊高性能RPC開發框架Tars實現服務治理(微服務)

Github：https://github.com/Tencent/Tars

1. 介紹

Tars是基於名字服務使用Tars協議的高性能RPC開發框架，同時配套一體化的服務治理平臺，幫助我的或者企業快速的以微服務的方式構建本身穩定可靠的分佈式應用。

Tars是將騰訊內部使用的微服務架構TAF（Total Application Framework）多年的實踐成果總結而成的開源項目。Tars這個名字來自星際穿越電影人機器人Tars，電影中Tars有着很是友好的交互方式，任何初次接觸它的人均可以輕鬆的和它進行交流，同時能在外太空、外星等複雜地形上，超預期的高效率的完成託付的全部任務。擁有着相似設計理念的Tars也是一個兼顧易用性、高性能、服務治理的框架，目的是讓開發更簡單，聚焦業務邏輯，讓運營更高效，一切盡在掌握。

目前該框架在騰訊內部，有100多個業務、1.6多萬臺服務器上運行使用。

2. 設計思想

Tars的設計思路是採用微服務的思想對服務進行治理，同時對整個系統的各個模塊進行抽象分層，將各個層次之間相互解耦或者鬆耦合，以下圖：

最底的協議層，設計思路是將業務網絡通訊的協議進行統一，以IDL(接口定義語言)的方式，開發支持多平臺、可擴展、協議代碼自動生成的統一協議。在開發過程當中，開發人員只須要關注通信的協議字段的內容，不須要關注其實現的細節，大大減輕了開發服務時須要考慮的協議是否能跨平臺使用、是否可能須要兼容、擴展等問題。

中間的公共庫、通信框架、平臺層，設計思路是讓業務開發更加聚焦業務邏輯的自己。所以，從使用者的角度出發，封裝了大量平常開發過程當中常用的公共庫代碼和遠程過程調用，讓開發使用更簡單方便；從框架自己的角度出發，作到高穩定性、高可用性、高性能，這樣才能讓業務服務運營更加放心；從分佈式平臺的角度出發，解決服務運營過程當中，遇到的容錯、負載均衡、容量管理、就近接入、灰度發佈等問題，讓平臺更增強大。

最上面的運營層，設計思路是讓運維只須要關注平常的服務部署、發佈、配置、監控、調度管理等操做。

3. 總體架構

3.1. 架構拓撲圖

總體架構的拓撲圖主要分爲2個部分：服務節點與公共框架節點。

服務節點:

服務節點能夠認爲是服務所實際運行的一個具體的操做系統實例，能夠是物理主機或者虛擬主機、雲主機。隨着服務的種類擴展和規模擴大，服務節點可能成千上萬甚至數以十萬計。每臺服務節點上均有一個Node服務節點和N(N>=0)個業務服務節點，Node服務節點會對業務服務節點進行統一管理，提供啓停、發佈、監控等功能，同時接收業務服務節點上報過來的心跳。

公共框架節點:

除了服務節點之外的服務，其餘服務節點均歸爲一類。

公共框架節點，數量不定，爲了自身的容錯容災，通常也要求在在多個機房的多個服務器上進行部署，具體的節點數量，與服務節點的規模有關，好比，若是某些服務須要打較多的日誌，就須要部署更多的日誌服務節點。

又可細分爲以下幾個部分：

Web管理系統：在Web上能夠看到服務運行的各類實時數據狀況，以及對服務進行發佈、啓停、部署等操做；

Registry（路由+管理服務）：提供服務節點的地址查詢、發佈、啓停、管理等操做，以及對服務上報心跳的管理，經過它實現服務的註冊與發現；

Patch（發佈管理）：提供服務的發佈功能；

Config（配置中心）：提供服務配置文件的統一管理功能；

Log（遠程日誌）：提供服務打日誌到遠程的功能；

Stat（調用統計）：統計業務服務上報的各類調用信息，好比總流量、平均耗時、超時率等，以便對服務出現異常時進行告警；

Property（業務屬性）：統計業務自定義上報的屬性信息，好比內存使用大小、隊列大小、cache命中率等，以便對服務出現異常時進行告警；

Notify（異常信息）：統計業務上報的各類異常信息，好比服務狀態變跟信息、訪問db失敗信息等，以便對服務出現異常時進行告警；

原則上要求所有的節點之間網絡互通，至少每臺機器的node可以與公共框架節點之間都是能夠連通的。

3.2. 服務交互流程圖

框架服務在整個系統中運行時，服務之間的交互分：業務服務之間的交互、業務服務與框架基礎服務之間的交互。

服務發佈流程：在Web系統上傳server的發佈包到patch，上傳成功後，在web上提交發布server請求，由registry服務傳達到node，而後node拉取server的發佈包到本地，拉起server服務。

管理命令流程：Web系統上的能夠提交管理server服務命令請求，由registry服務傳達到node服務，而後由node向server發送管理命令。

心跳上報流程：server服務運行後，會按期上報心跳到node，node而後把服務心跳信息上報到registry服務，由registry進行統一管理。

信息上報流程：server服務運行後，會按期上報統計信息到stat，打印遠程日誌到log，按期上報屬性信息到property、上報異常信息到notify、從config拉取服務配置信息。

Client訪問Server流程：client能夠經過server的對象名Obj間接訪問server，Client會從registry上拉取server的路由信息（如ip、port信息），而後根據具體的業務特性（同步或者異步，tcp或者udp方式）訪問server(固然client也能夠經過ip/port直接訪問server)。

3.3. web管理系統

web管理系統主要包含如下功能：

• 業務管理：包括已部署的服務，以及服務管理、發佈管理、服務配置、服務監控、特性監控等；

• 運維管理：包括服務部署、擴容、模版管理等；

3.4. 服務結構圖

框架核心的服務端與客戶端實現結構圖以下:

服務端：

NetThread： 收發包，鏈接管理，多線程(可配置），採用epoll ET觸發實現，支持tcp/udp；

BindAdapter： 綁定端口類，用於管理servent對應的綁定端口的信息操做；

ServantHandle：業務線程類，根據對象名分派Servant的對象和接口調用；

AdminServant： 管理端口的對象；

ServantImp： 繼承Servant的業務處理基類（Servent：服務端接口對象的基類）；

客戶端：

NetThread： 收發包，鏈接管理，多線程(可配置），採用epoll ET觸發實現，支持tcp/udp；

AdapterProxy： 具體服務器某個節點的本地代理，管理到服務器的鏈接，以及請求超時處理；

ObjectProxy： 遠程對象代理，負責路由分發、負載均衡、容錯，支持輪詢/hash/權重；

ServantProxy： 遠程對象調用的本地代理，支持同步/異步/單向，Tars協議和非Tars協議；

AsyncThread： 異步請求的迴應包處理線程；

Callback： 具體業務Callback的處理基類對象；

4. 平臺特性

4.1. tars協議

tars協議採用接口描述語言（Interface description language，縮寫IDL）來實現，它是一種二進制、可擴展、代碼自動生成、支持多平臺的協議，使得在不一樣平臺上運行的對象和用不一樣語言編寫的程序能夠用PRC遠程調用的方式相互通訊交流，主要應用在後臺服務之間的網絡傳輸協議，以及對象的序列化和反序列化等方面。

協議支持的類型分兩種，基本類型和複雜類型。

基本類型包括：void、bool、byte、short、int、long、float、double、string、unsigned byte、unsigned short、unsigned int；

複雜類型包括：enum、const、struct、vector、map，以及struct、vector、map的嵌套。

例如:

4.2. 調用方式

經過IDL語言協議，能夠定義服務提供的接口，並自動生成客戶端和服務端的相關通訊代碼，服務端只需實現業務邏輯便可對外提供服務，客戶端經過自動生成的代碼便可調用服務，調用方式支持三種模式：

同步調用：客戶端發出調用請求後等待服務返回結果後再繼續邏輯；

異步調用：客戶端發出調用請求後繼續其餘業務邏輯，服務端返回結果又由回調處理類處理結果；

單向調用：客戶端發出調用請求後就結束調用，服務端不返回調用結果；

4.3. 負載均衡

框架經過名字服務來實現服務的註冊與發現，Client經過訪問名字服務獲取到被調服務的地址信息列表，Client再根據須要選擇合適的負載均衡方式來調用服務，

負載均衡支持輪詢、hash、權重等多種方式。

4.4. 容錯保護

容錯保護經過兩種方式實現：名字服務排除和Client主動屏蔽。

名字服務排除的策略：

業務服務主動上報心跳給名字服務，使名字服務知道服務部署的節點存活狀況，當服務的某節點故障時，名字服務不在返回故障節點的地址給Client，達到排除故障節點的目標。名字服務排除故障須要經過服務心跳和Client地址列表拉取兩個過程，故障排除時間在1分鐘左右

Client主動屏蔽：

爲了更及時的屏蔽故障節點，Client根據調用被調服務的異常狀況來判斷是否有故障來更快進行故障屏蔽。具體策略是，當client調用某個svr出現調用連續超時，或者調用的超時比率超過必定百分比，client會對此svr進行屏蔽，讓流量分發到正常的節點上去。對屏蔽的svr節點，每隔必定時間進行重連，若是正常，則進行正常的流量分發。

4.5. 過載保護

爲了防止業務由於訪問量突增或服務器故障形成系統總體的繁忙，進而致使所有服務的不可用，框架內部作相應設計來應對。實現請求隊列，服務調用經過非阻塞方式實現異步系統，從而達到提高系統處理能力的目的。而且對隊列的長度進行監控，當超過某個閥值，則拒絕新的請求。對請求設置超時時間，當請求包從隊列裏讀取出來是判斷請求是否超時，若是超時則不作處理。

4.6. 消息染色

框架提供了對某服務某接口的特定請求進行染色的能力，染色的消息能夠透傳到後面須要訪問的全部服務上，對染色的請求，服務自動把日誌上報到特定的染色日誌服務器上，使用者只需在染色服務器上便可分析請求訪問的路徑，方便跟蹤定位問題。以下：

4.7. IDC分組

爲了加快服務間的訪問速度，建設跨地區、跨機房調用帶來的網絡資源消耗，減小網絡故障帶來的影響，框架提供了跨地區、跨機房，就近接入的功能。

詳細介紹參見docs目錄下的tars_idc_set.md

4.8. SET分組

爲了方便對業務服務部署管理進行標準化和容量化，框架提供了Set部署能力，set之間沒有調用關係，互不干擾，故障隔離，提升運維效率和服務可用性。

詳細介紹參見docs目錄下的tars_idc_set.md

4.9. 數據監控

爲了更好反映和監控小到服務進程、大到業務的運行質量狀況，框架支持如下數據上報的功能:

1.提供了服務模塊間調用信息統計上報的功能，方便用戶查看服務的流量、延時、超時、異常等狀況；

2.提供了用戶自定義屬性數據上報的功能，方便用戶查看服務的某些緯度或者指標，好比內存使用狀況、隊列大小、cache命中率等；

3.提供了服務狀態變動和異常信息上報的功能，方便用戶查看服務的什麼時候發佈過、重啓過、宕過以及遇到的異常致命錯誤等；

4.10. 集中配置

對業務配置進行集中管理而且操做web化，使配置修改更容易，通知更及時，配置變動也更安全；對配置變動進行歷史記錄，讓配置能夠輕鬆回退到前一版本。配置拉取服務化，服務只需調用配置服務的接口便可獲取到配置文件。

爲了能靈活管理配置文件，配置文件分爲幾個級別：應用配置、Set配置、服務配置和節點配置。

應用配置爲最高一級的配置文件，它是多個服務配置提煉出來的公共配置，服務配置經過引用它來使用其配置內容。

Set配置是具體一個Set分組下全部服務的公共配置，在應用配置的基礎上進行補充追加。

服務配置是具體一個服務下全部節點的公共配置，能夠引用應用配置。

節點配置是一個應用節點的個性化配置，它和服務配置合併成爲具體一個服務節點的配置。

詳細介紹能夠參見docs目錄下的tars_config.md