Tencent高效能多框架下服務發現方案Tseer
簡介
Tseer是一套解決多框架服務叢集之間服務發現的工具,基於名字進行路由實現,效能優越,接入友好,在騰訊內部被廣泛採用,目前日均承載百億級別的請求量。
在服務發現的核心功能之上,Tseer還支援多種優秀的負載均衡演算法,提供可靠的故障容錯策略。針對發展迅速的海量服務,還支援就近接入,按SET邏輯分組,全量排程三種不同的路由策略。實現了高度智慧的排程優化,有效解決了業務跨地區跨機房呼叫等業界難題,最大化保證了服務的可用,對業務質量有顯著提升。
Tseer架構
整個Tseer的結構分為三部分:Tseerserver、業務客戶端(主調)、業務服務端(被調)。
-
Tseerserver
Tseerserver是整個Tseer的樞紐與核心模組。 當新節點上線時,需要先通過WEB管理平臺在Tseer服務叢集註冊,將其網路位置資訊記錄在Tseer系統中。當需要對節點進行下線或者其他修改時,也需要在WEB管理平臺就行相關操作。被調節點也會定時上報心跳給Tseerserver,server端會遮蔽心跳超時的節點使其無法被呼叫。
-
業務客戶端
業務客戶端是需要呼叫其他服務的節點,稱之為主調,是服務發現功能的使用者。 Tseer為業務客戶端提供了:安裝Agent與API呼叫兩種方式來從Tseerserver獲得需要呼叫的服務(被調)的地址來完成呼叫。
-
業務服務端
業務服務端是需要被呼叫的節點,稱之為被調,是服務的提供者。 當新節點上線時,被調需要在Tseerserver註冊。不論同一個被調服務叢集有多少個節點,註冊時該服務叢集都需要註冊一個統一的名字。主調在呼叫邏輯中只需要寫明需要呼叫的服務的名字,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將會用本地磁碟中的快取恢復記憶體快取。
參考:1. https://github.com/Tencent/TSeer
相關文章
- Tencent高效能微服務治理方案Tars微服務
- Tseer:Tars名字服務功能的輕量化實現
- C#高效能 TCP 服務的多種實現方式C#TCP
- [翻譯]微服務設計模式 - 5. 服務發現 - 服務端服務發現微服務設計模式服務端
- 微服務之服務註冊和發現的可行性方案微服務
- 微服務實戰:服務發現的可行方案以及實踐案例微服務
- shell監控web服務的多種方案Web
- Docker實現服務發現Docker
- NodeJs服務註冊與服務發現實現NodeJS
- 微服務之Eureka服務發現微服務
- 2-服務發現
- go微服務系列(二) - 服務註冊/服務發現Go微服務
- etcd實現服務發現
- 高效能服務端漫談服務端
- 如何在Spring Boot框架下實現高效的Excel服務端匯入匯出?Spring Boot框架Excel服務端
- 10行C++程式碼實現高效能HTTP服務C++HTTP
- Zookeeper實現服務註冊/發現
- 服務發現-從原理到實現
- 小白入門微服務(4) – 服務註冊與服務發現微服務
- 小白入門微服務(4) - 服務註冊與服務發現微服務
- 高效能服務端優化之路服務端優化
- 微服務4:服務註冊與發現微服務
- 【微服務之Eureka服務註冊發現】微服務
- consul服務註冊與服務發現的巨坑
- 微服務之服務註冊和服務發現篇微服務
- ZooKeeper服務發現客戶端客戶端
- Nacos服務註冊與發現
- Eureka實現服務註冊與發現
- 微服務~Eureka實現的服務註冊與發現及服務之間的呼叫微服務
- .Net Core微服務——服務發現:Consul(一)微服務
- .Net Core微服務——服務發現:Consul(二)微服務
- 聊聊微服務的服務註冊與發現!微服務
- 【SpringCloud】(二):服務發現和服務註冊SpringGCCloud
- 微服務架構中的服務發現策略微服務架構
- 實現etcd服務註冊與發現
- 服務發現的基本原理
- prometheus k8s服務發現PrometheusK8S
- Nodejs 使用 ZooKeeper 做服務發現NodeJS