目錄
1.介紹
2.設計思路
3.整體架構
4.平台特性
1. 介紹
Tars是【基於名字服務】【使用Tars協議】的高性能【RPC】開發框架，同時配套一體化的【服務治理平台】，幫助個人或者企業快速的以微服務的方式構建自己穩定可靠的分布式應用。
Tars在騰訊內部名為TAF，內部從08年開始使用，到現在將近10個年頭了，今年終於開源。目前該框架在騰訊內部，有100多個業務、1.6多萬台服務器上運行使用。
Tars也是一個兼顧易用性、高性能、服務治理的框架，目的是讓開發更簡單，聚焦業務邏輯，讓運營更高效，一切盡在掌握。
目前，我日常開發也是使用該框架，十分方便快捷，而且配套的服務管理系統，為服務監控、運維到來了很大的便利。
代碼地址：https://github.com/Tencent/Tars
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(即通過名字服務來路由，而不是寫死IP)，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分組
為了加快服務間的訪問速度，建設跨地區、跨機房調用帶來的網絡資源消耗，減少網絡故障帶來的影響，框架提供了跨地區、跨機房，就近接入的功能。
4.8. SET分組
為了方便對業務服務部署管理進行標准化和容量化，框架提供了Set部署能力，set之間沒有調用關系，互不干擾，故障隔離，提高運維效率和服務可用性。
4.9. 數據監控
為了更好反映和監控小到服務進程、大到業務的運行質量情況，框架支持以下數據上報的功能:
1.提供了服務模塊間調用信息統計上報的功能，方便用戶查看服務的流量、延時、超時、異常等情況；
2.提供了用戶自定義屬性數據上報的功能，方便用戶查看服務的某些緯度或者指標，比如內存使用情況、隊列大小、cache命中率等；
3.提供了服務狀態變更和異常信息上報的功能，方便用戶查看服務的何時發布過、重啟過、宕過以及遇到的異常致命錯誤等；
4.10. 集中配置
對業務配置進行集中管理並且操作web化，使配置修改更容易，通知更及時，配置變更也更安全；對配置變更進行歷史記錄，讓配置可以輕松回退到前一版本。配置拉取服務化，服務只需調用配置服務的接口即可獲取到配置文件。
為了能靈活管理配置文件，配置文件分為幾個級別：應用配置、Set配置、服務配置和節點配置。
應用配置為最高一級的配置文件，它是多個服務配置提煉出來的公共配置，服務配置通過引用它來使用其配置內容。
Set配置是具體一個Set分組下所有服務的公共配置，在應用配置的基礎上進行補充追加。
服務配置是具體一個服務下所有節點的公共配置，可以引用應用配置。
節點配置是一個應用節點的個性化配置，它和服務配置合並成為具體一個服務節點的配置。
---------------------
作者：jiange_zh
來源：CSDN
原文：https://blog.csdn.net/jiange_zh/article/details/78507590
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！