騰訊推出高性能 RPC 開發框架

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

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

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

設計思想

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

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

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

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

整體架構

架構拓撲

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

服務節點:

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

公共框架節點:

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

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

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

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

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

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

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

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

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

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

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

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

特性

tars 協議

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

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

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

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

例如:

調用方式

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

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

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

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

負載均衡

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

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

容錯保護

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

名字服務排除的策略：

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

Client 主動屏蔽：

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

過載保護

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

消息染色

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

IDC 分組

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

SET 分組

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

數據監控

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

image

集中配置

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

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

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

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

服務配置是具體一個服務下所有節點的公共配置，可以引用應用配置。

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

項目地址

開源地址：https://gitee.com/TarsCloud/Tars

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/KNz7QWKbR2hj7DJspeOj7Q

猜你喜歡