Tencent高效能微服務治理方案Tars
簡介
Tars是基於名字服務使用Tars協議的高效能RPC開發框架,同時配套一體化的服務治理平臺,幫助個人或者企業快速的以微服務的方式構建自己穩定可靠的分散式應用。Tars是將騰訊內部使用的微服務架構TAF(Total Application Framework)多年的實踐成果總結而成的開源專案。
已經在騰訊內部打磨十年之久,並在手機QQ瀏覽器、應用寶、手機管家等160多個核心業務、5萬多臺伺服器上廣泛應用。2017年4月,TARS正式宣佈開源,社群參與度顯著提升。在過去八個月中,TARS又主動進行了三個版本的迭代,涉及多種新功能、語言及ProtoBuf協議的更新。此外,閱文集團、虎牙、優品財富、科大訊飛等專案成員也積極為TARS與TSeer貢獻,帶動了TARS與TSeer在金融、教育、健康醫療、政務等多個行業領域的應用。
設計思想
Tars的設計思路是採用微服務的思想對服務進行治理,同時對整個系統的各個模組進行抽象分層,將各個層次之間相互解耦或者鬆耦合,如下圖:
最底的協議層,設計思路是將業務網路通訊的協議進行統一,以IDL(介面定義語言)的方式,開發支援多平臺、可擴充套件、協議程式碼自動生成的統一協議。在開發過程中,開發人員只需要關注通訊的協議欄位的內容,不需要關注其實現的細節,大大減輕了開發服務時需要考慮的協議是否能跨平臺使用、是否可能需要相容、擴充套件等問題。
中間的公共庫、通訊框架、平臺層,設計思路是讓業務開發更加聚焦業務邏輯的本身。因此,從使用者的角度出發,封裝了大量日常開發過程中經常使用的公共庫程式碼和遠端過程呼叫,讓開發使用更簡單方便;從框架本身的角度出發,做到高穩定性、高可用性、高效能,這樣才能讓業務服務運營更加放心;從分散式平臺的角度出發,解決服務運營過程中,遇到的容錯、負載均衡、容量管理、就近接入、灰度釋出等問題,讓平臺更加強大。
最上面的運營層,設計思路是讓運維只需要關注日常的服務部署、釋出、配置、監控、排程管理等操作。
整體架構
整體架構的拓撲圖主要分為2個部分:服務節點與公共框架節點。
服務節點:
服務節點可以認為是服務所實際執行的一個具體的作業系統例項,可以是物理主機或者虛擬主機、雲主機。隨著服務的種類擴充套件和規模擴大,服務節點可能成千上萬甚至數以十萬計。 每臺服務節點上均有一個Node服務節點和N(N>=0)個業務服務節點,Node服務節點會對業務服務節點進行統一管理,提供啟停、釋出、監控等功能,同時接收業務服務節點上報過來的心跳。
公共框架節點:
除了服務節點以外的服務,其他服務節點均歸為一類。
公共框架節點,數量不定,為了自身的容錯容災,一般也要求在在多個機房的多個伺服器上進行部署,具體的節點數量,與服務節點的規模有關,比如,如果某些服務需要打較多的日誌,就需要部署更多的日誌服務節點。
又可細分為如下幾個部分:
Web管理系統:在Web上可以看到服務執行的各種實時資料情況,以及對服務進行釋出、啟停、部署等操作;
Registry(路由+管理服務):提供服務節點的地址查詢、釋出、啟停、管理等操作,以及對服務上報心跳的管理,通過它實現服務的註冊與發現;
Patch(釋出管理):提供服務的釋出功能;
Config(配置中心):提供服務配置檔案的統一管理功能;
Log(遠端日誌):提供服務打日誌到遠端的功能;
Stat(呼叫統計):統計業務服務上報的各種呼叫資訊,比如總流量、平均耗時、超時率等,以便對服務出現異常時進行告警;
Property(業務屬性):統計業務自定義上報的屬性資訊,比如記憶體使用大小、佇列大小、cache命中率等,以便對服務出現異常時進行告警;
Notify(異常資訊):統計業務上報的各種異常資訊,比如服務狀態變更資訊、訪問db失敗資訊等,以便對服務出現異常時進行告警;
原則上要求全部的節點之間網路互通,至少每臺機器的node能夠與公共框架節點之間都是可以連通的。
服務互動流程
框架服務在整個系統中執行時,服務之間的互動分:業務服務之間的互動、業務服務與框架基礎服務之間的互動。
服務釋出流程:在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,Client會從registry上拉取server的路由資訊(如ip、port資訊),然後根據具體的業務特性(同步或者非同步,tcp或者udp方式)訪問server(當然client也可以通過ip/port直接訪問server)。
參考:
1. https://github.com/TarsCloud/Tars
2. https://github.com/TarsCloud
3. https://www.lanindex.com/tars%E6%A1%86%E6%9E%B6future-promise%E4%BD%BF%E7%94%A8/
4. https://blog.csdn.net/tencent__open
5. https://blog.csdn.net/jiange_zh/article/details/78507590
相關文章
- Tencent高效能多框架下服務發現方案Tseer框架
- 微服務治理平臺的RPC方案實現微服務RPC
- SpringCloud微服務治理SpringGCCloud微服務
- 微服務治理攻略 - 隔離微服務
- 微服務概覽與治理微服務
- 微服務17:微服務治理之異常驅逐微服務
- SOA服務治理方案
- 聊聊微服務治理體系思想微服務
- 微服務治理與統計分析微服務
- 微服務18:微服務治理之異地多活容災微服務
- MSE 微服務治理髮布企業版,助力企業構建完整微服務治理體系微服務
- silky微服務框架的服務治理介紹微服務框架
- SpringCloud微服務治理二(Robbin,Hystix,Feign)SpringGCCloud微服務
- TARS為SpringCloud提供高效能的RPC能力SpringGCCloudRPC
- Gome 高效能撮合引擎微服務Go微服務
- 微服務的服務間通訊與服務治理微服務
- 微服務系列 2:微服務化框架的模型和治理能力設計微服務框架模型
- 微服務9:服務治理來保證高可用微服務
- SpringCloud微服務治理三(Zuul閘道器)SpringGCCloud微服務Zuul
- Proxyless的多活流量和微服務治理微服務
- SpringCloud微服務治理技術入門(SCN)SpringGCCloud微服務
- 微服務治理之自適應降載微服務
- 微服務高可用方案微服務
- SpringCloudAlibaba 微服務講解(三)Nacos Discovery-服務治理SpringGCCloud微服務
- 華為雲服務治理 | 微服務常見故障模式微服務模式
- 微服務治理平臺產品化實踐與應用微服務化解析微服務
- 菜鳥 CPaaS 平臺微服務治理實踐微服務
- 如何透過 Serverless 提高 Java 微服務治理效率?ServerJava微服務
- 微服務環境下,資料如何治理微服務
- 基於Spring Cloud微服務叢集的服務治理思考SpringCloud微服務
- nodejs微服務解決方案NodeJS微服務
- 你問我答:微服務治理應該如何去做?微服務
- 從微服務治理的角度看RSocket,. Envoy和. Istio微服務
- 不改一行程式碼,輕鬆擁有企業級微服務治理|MSE微服務治理專業版重磅釋出行程微服務
- Go使用grpc+http打造高效能微服務GoRPCHTTP微服務
- 應用量化時代 | 微服務架構的服務治理之路微服務架構
- nodejs微服務框架解決方案NodeJS微服務框架
- java springcloud 微服務設計方案JavaSpringGCCloud微服務