【開源】Tseer產品介紹

做者: 鍾科

一.TSeer簡介

TSeer是一套服務註冊發現容錯的方案，是對Tars名字服務功能的輕量化。在騰訊瀏覽器、應用寶、管家、手機書城、騰訊文學、廣點通等衆多業務中普遍採用，目前日均承載百億級的請求量。

TSeer輕巧靈便，對業務的侵入性低，非tars服務亦可無縫接入。在服務發現的核心功能之上，Tseer還支持多種負載均衡算法，提供可靠的故障容錯策略，可有效解決業務跨地區跨機房調用等難題，極大提高服務的可用性和調用質量，是微服務框架中優秀的名字服務解決方案。

TSeer擁有web管理界面和API接入兩種方式可供用戶根據需求自由選擇，經過代理節點和代理服務器機制爲須要頻繁發佈變動的業務提供透明的服務發現功能，學習成本很低，操做也很方便，對於業務維護人員十分友好。

二.研發背景

在傳統的單體式應用中，變動發佈相對較少，系統中的網絡位置也不多變化，偶爾的變動也能夠經過手動更改配置的方式來應對。可是在當前海量服務的大環境下，這種架構已經沒法高效穩定的支撐高速增加的業務。愈來愈龐大的分佈式服務集羣和微服務框架已經逐漸成爲主流。

可是新型架構爲業務提供更好支撐的同時，頻繁的發佈更新與動態伸縮也致使了網絡位置的頻繁變化，在這種狀況下業務維護人員手動更改配置這種大規模重複性工做不只增大了出錯的風險，其低效也會限制業務的高速發展。每每配置還沒改完，新的變動就須要發佈了。因此就必需要一個自動化的服務發現工具來解決這些問題。

然而這些也並非問題的所有。在保證訪問成功的前提下，響應時間做爲服務質量中最重要的指標，是影響業務發展最關鍵的一環。多業務集之間複雜的調用關係再加上跨地區跨網絡調用等其餘因素，響應時間達不到預期是持續困擾整個業務發展週期的棘手問題。與此同時，不管是採用物理機仍是虛擬機，節點掛掉致使的不可用時有發生，如何有效容錯也是亟待解決的問題。
基於這些問題，咱們開發了TSeer。

三.TSeer架構

整個Tseer的結構分爲四部分：TseerServer、業務客戶端（主調）、業務服務端（被調）、web管理。

• TseerServer

TseerServer是整個Tseer的樞紐與核心模塊。 當新節點上線時，須要先經過WEB管理平臺在Tseer服務集羣註冊，將其網絡位置信息記錄在Tseer系統中。當須要對節點進行下線或者其餘修改時，也須要在WEB管理平臺就行相關操做。被調節點也會定時上報心跳給TseerServer，server端會屏蔽心跳超時的節點使其沒法被調用。

• 業務客戶端

業務客戶端是須要調用其餘服務的節點，稱之爲主調，是服務發現功能的使用者。 Tseer爲業務客戶端提供了：安裝Agent與API調用兩種方式來從TseerServer得到須要調用的服務（被調）的地址來完成調用。

• 業務服務端

業務服務端是須要被調用的節點，稱之爲被調，是服務的提供者。 當新節點上線時，被調須要在TseerServer註冊。不論同一個被調服務集羣有多少個節點，註冊時該服務集羣都須要註冊一個統一的名字。主調在調用邏輯中只須要寫明須要調用的服務的名字，Tseer會根據被調名字來返回被調地址。當被調須要擴容時，只須要把新節點加在該服務對應的名字下面便可。業務人員無需管理被調集羣下繁多的服務節點信息，十分方便。

• Web管理

業務信息及節點路由信息的增刪改查都是經過web管理界面操做，簡便快捷直觀。甚至agent安裝包均可以經過web平臺更新發布。詳細使用方式可參考github上TSeer項目的使用文檔。

四.Tseer功能的特色

1.負載均衡

當同一業務集羣中某些節點被頻繁調用而另外一些節點沒有承擔合理的負載時，不只業務的服務質量和響應時間會大幅降低，同時也會形成資源的浪費。

Tseer系統中，當主調發起調用時，會針對被調名字下全部可用節點爲調用提供四種負載均衡方式來保障各個節點的合理負載，分別是

• 輪詢

• 隨機

• 靜態權重

• 一致性哈希

用戶還可使用調用分組的方式來自定義負載均衡實現，調用分組會在下文中提到。

2.故障容錯

爲了解決節點故障致使的業務不可用與服務質量下降，Tseer還提供了可靠的故障容錯機制。

當主調進行一次調用以後，會將調用結果上報。若是調用失敗Tseer會暫時將該節點屏蔽來避免故障節點被反覆調用，Tseer會定時探測被屏蔽的節點，當發現故障節點恢復服務時，會從新將其激活。

對於任意被調節點，知足下列條件之一則屏蔽該節點：

1.在一個檢測週期（60秒）內調用失敗次數達到2次，且調用錯誤數佔總調用次數的50%以上

2.在5秒內連續調用失敗5次以上

對於被屏蔽的節點Tseer Agent/Api將每隔30秒對已屏蔽的節點進行重試。

同時當Tseer故障時，主調也能根據緩存信息繼續調用。

3.調用優化

Tseer爲調用邏輯提供IDC分組、Set分組、All三種方式來解決跨地區調用等問題。

• All

爲主調提供全部可用被調節點地址

• IDC分組

IDC分組能夠近似的看做就近接入。

該方法按照兩個層次進行劃分。第一個是物理小組，是最小的組調度單位，即按照節點所在的機房或者區域分配統 一的組名。第二個是物理小組組成的邏輯組，能夠理解爲按照更大的區域來劃分的統一的組名。

針對IDC的邏輯分組，Tseer還定義了調用優先級策略。即部分邏輯組不可用時，會按照優先級策略返回可用被調節點地址列表。

• Set分組

IDC分組主要是在區域概念上去劃分分組，實現就近訪問策略，在後臺服務架構中，業務規模達到必定數量時，若是要對某幾個服務節點實現根據容量、灰度，分區域管理的隔離控制，IDC分組是沒法知足的，而Set分組則是對IDC分組的再細化。

Set分組的命名規則爲： Set名.Set地區.Set組。其中Set組是最小區分單元的名稱，支持通配符*，表示Set地區下的全部分組。好比0,1,2,3,4或者a,b,c,d。

Set分組的調用邏輯以下：

1.主調（客戶端）和被調（服務端）都啓用了Set分組，而且Set名要一致才認爲是啓用同SET內

2.啓用Set分組的主調和被調只能訪問同Set內的節點

3.主調啓用Set分組，被調沒有啓用Set分組，則默認會走按IDC分組查詢的邏輯（前提是啓用了IDC分組）

4.兩種接入方式

根據服務客戶端是否在其物理機中部署Tseer Agent，Tseer的使用方式能夠分爲Agent 和Tseer API兩種方式：

• Agent 方式

名字路由

Agent 方式下，Tseer Agent會按期緩存被調方的信息。並根據調用方指定的負載均衡策略將被調節點信息返給調用方。若是調用方但願經過服務特性來實現負載均衡，Tseer也支持按照調用方指定的分組策略將被調的組信息返給調用方。

數據上報

每次調用完成後，調用方須要調用Tseer Api提供的上報接口上報調用信息，調用信息將由Tseer Api即便上報至Tseer Agent。Tseer Agent將根據調用信息剔除失效被調節點。

容錯 使用Agent 方式時，若是Tseer Agent失效，Tseer Api將會從內存中返回已訪問過的節點給主調，若是Tseer Api緩存失效，此時Tseer Api將會從本地磁盤中的緩存文件恢復緩存信息提供給主調。須要注意的是此時Tseer Api提供給主調服務的信息爲有損信息，Tseer Api不保證節點必定健康。

• Tseer Api方式

名字路由

Agent 方式與Tseer Api方式的區別在因而否須要在主調的宿主機中部署Tseer Agent。Tseer Api會直接訪問Tseer server。而且被調方信息緩存、負載均衡以及失效節點剔除都在Tseer Api中完成。

Tseer Api會定時拉取Tseerserver的後端信息並屏蔽不可用的被調節點。

容錯

Tseerserver故障時，Tseer Api會將內存中緩存的信息返回給主調。當內存緩存不可用時，Tseer Api將會用本地磁盤中的緩存恢復內存緩存。

Agent Api方式 與Tseer Api方式對比

結語

TSeer是一套服務註冊發現容錯的方案，是對Tars名字服務功能的輕量化，輕巧靈便，對業務的侵入性低。在服務發現的核心功能之上，Tseer還支持多種負載均衡算法，提供可靠的故障容錯策略，可有效解決業務跨地區跨機房調用等難題，極大提高服務的可用性和調用質量，是微服務框架中優秀的名字服務解決方案。