作者: 鍾科
一.TSeer簡介
TSeer是一套服務註冊發現容錯的方案，是對Tars名字服務功能的輕量化。在騰訊瀏覽器、應用寶、管家、手機書城、騰訊文學、廣點通等眾多業務中廣泛採用，目前日均承載百億級的請求量。
TSeer輕巧靈便，對業務的侵入性低，非tars服務亦可無縫接入。在服務發現的核心功能之上，Tseer還支援多種負載均衡演算法，提供可靠的故障容錯策略，可有效解決業務跨地區跨機房呼叫等難題，極大提升服務的可用性和呼叫質量，是微服務框架中優秀的名字服務解決方案。
TSeer擁有web管理介面和API接入兩種方式可供使用者根據需求自由選擇，通過代理節點和代理伺服器機制為需要頻繁釋出變更的業務提供透明的服務發現功能，學習成本很低，操作也很方便，對於業務維護人員十分友好。
目前TSeer已正式開源。Github地址為：github.com/Tencent/Tse…。
二.研發背景
在傳統的單體式應用中，變更釋出相對較少，系統中的網路位置也很少變化，偶爾的變更也可以通過手動更改配置的方式來應對。但是在當前海量服務的大環境下，這種架構已經無法高效穩定的支撐高速增長的業務。越來越龐大的分散式服務叢集和微服務框架已經逐漸成為主流。
但是新型架構為業務提供更好支撐的同時，頻繁的釋出更新與動態伸縮也導致了網路位置的頻繁變化，在這種情況下業務維護人員手動更改配置這種大規模重複性工作不僅增大了出錯的風險，其低效也會限制業務的高速發展。往往配置還沒改完，新的變更就需要釋出了。所以就必須要一個自動化的服務發現工具來解決這些問題。
然而這些也並不是問題的全部。在保證訪問成功的前提下，響應時間作為服務質量中最重要的指標，是影響業務發展最關鍵的一環。多業務集之間複雜的呼叫關係再加上跨地區跨網路呼叫等其他因素，響應時間達不到預期是持續困擾整個業務發展週期的棘手問題。與此同時，無論是採用物理機還是虛擬機器，節點掛掉導致的不可用時有發生，如何有效容錯也是亟待解決的問題。
基於這些問題，我們開發了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還支援多種負載均衡演算法，提供可靠的故障容錯策略，可有效解決業務跨地區跨機房呼叫等難題，極大提升服務的可用性和呼叫質量，是微服務框架中優秀的名字服務解決方案。