荊門百姓網 歡迎您!
首頁 即時發布 互動 本地服務 本地文化 樂活本地 專題熱點 娛樂資訊 圖庫 親子 健康 旅遊 财富 樓市
您的當前位置:首頁 > 本地服務 > 正文
騰訊開源基于微服務的平台Tars:RPC開發、服務治理及一體化運營管理
更新時間:2019-08-13 07:25:23 點擊數:92 來源:本站

  Tars取名于電影“星際穿越”中的機器人,是騰訊内部使用将近十年的基于微服務的統一應用框架TAF(Total Application Framework),目前騰訊有160多個業務(如手機浏覽器、應用寶、手機管家等)在1.6多萬台服務器上使用Tars。

  Tars主要是支持多語言的高性能RPC開發框架和配套一體化的服務治理平台,可以幫助企業或者用戶以微服務的方式快速構建穩定可靠的分布式應用。目前開源的Tars支持C++、Java兩種語言,同時Node.js語言的Tars開源地址為:

  Tars取名于電影“星際穿越”中的機器人,是騰訊内部使用将近十年的基于微服務的統一應用框架TAF(Total Application Framework),目前騰訊有160多個業務(如手機浏覽器、應用寶、手機管家等)在1.6多萬台服務器上使用Tars。

  近幾年,業内已經有越來越多人關注并開始落地微服務,那麼騰訊這款經曆近十年探索的微服務治理平台是怎樣的?它的開源會為社區帶來哪些福音?為此,InfoQ采訪了騰訊專家鐘科。

  在業務變化不大的情況下,這種方案一般能很好的工作幾年、甚至十年。但是,彼時業務發展很快,業務需求、系統複雜度、業務規模、參與人數、代碼腐化程度都在不斷上升,各個業務團隊慢慢陷于一種混亂狀态,主要包括以下幾點:

  面對業務海量訪,騰訊開始采用微服務架構的思想,設計和實現一個通用的統一應用框架平台,對業務提供涉及到開發、運維以及測試的一整套解決方案,讓開發更簡單,運維更高效。

  第一個階段,框架産生的階段。目的是做以微服務為基礎的分布式架構。這個時期,開發側面對的情況如下:服務模型多樣化、業務協議不統一、基礎組件或框架能力參差不齊等,導緻開發大部分精力關注在協議的交互、網絡通信的實現、系統的容錯容災、以及服務的部署、發布、擴容等,不能聚焦業務自身的邏輯,同時跨業務團隊之間的系統互通效率底下;而運營側處于的狀況:運維工具各異,部署管理淩亂,監控能力薄弱,導緻系統出現問題和故障後,基本靠用戶投訴才能定位和發現。

  為了解決面對的這些問題,同時更好地應對在互聯網/移動互聯網時代下業務海量訪問的發展趨勢,我們設計和實現了一個通用的應用框架,它具有以下能力:

  這便是Tars微服務架構的雛形,有了它之後,業務開發人員開始聚焦業務真正的邏輯,提高了開發效率,系統的運營管理開始簡單化、規範化、流程化,提升了運維效率。

  性能問題:以前程序大都是在2核或者4核的機器運行,而這個時期公司使用的機型在不斷發展,慢慢出現了8核、16核、24核等的機器,同時系統也支持多隊列網卡,由于框架是多線程模型的,同時為了保證代碼良好的可讀性和結構的簡單性,在高性能這塊,沒有做太多精細的優化,線程共享資源之間粗粒度鎖的使用和數據交互之間存在的内存拷貝等情況比較多,同時先前的網絡收發隻會被cpu0處理,導緻一些對性能要求比較高的業務,在新的機型上使用框架時出現瓶頸問題,cpu和網絡等資源利用不起來。

  為了讓框架在多核和多隊列網卡的機器上充分利用資源和提供更高的性能,同時更好地為服務業務,我們對框架進行重構,原來隻支持單線程的收發包模式,改造成多線程收發包,原來框架内影響線程并發運行的粗粒度鎖和數據拷貝,改造成鎖細粒度化或者無鎖化,數據交互盡量做到零拷貝,最終框架的性能在8核機器上由19w/s提升到40w/s,cpu的最大利用率由62%提升到90%。

  開發易用性問題:随着業務的發展,業務的服務模塊越來越多,服務模塊之間交互的關系越來越複雜,線上業務服務為了保證服務的穩定性,一般采用異步Callback方式進行服務交互,而異步Callback方式的代碼邏輯分散,閱讀和維護起來比較困難。為了讓開發編寫代碼更加簡單,我們提供了協程和future/promise兩種編碼方式。對原來的同步調用方式,通過協程技術,不改變原來的同步編碼方式,對業務透明,隻需通過配置開關,可将其實際執行變同步為異步;對于原來的異步調用方式,通過future/promise技術,讓編碼方式像同步一樣。

  服務混合部署問題:這個時期,使用tars的機器規模達到了1w多台,服務進程數量達到了6w個,而其中小服務比例很高,80%的進程CPU峰值小于1核,這中間還有75%的進程連0.1核都用不到。為了提高資源利用率,必須要将服務混合部署。但是進程依賴的運行環境差異大,不同進程的依賴經常存在沖突,導緻混合部署難度很大。

  即便沒有環境沖突,各個服務進程部署到一台機器上之後,經常出現資源競争,影響服務質量的問題。于是我們通過使用Docker方案将每個進程的運行環境和資源消耗隔離起來。服務部署、打包、發布等标準化,這樣提高了部署效率,保證了交付質量,提升了資源利用率。

  彈性調度問題:通過使用Docker技術,服務進程不再對機器有特殊要求,使得進程可以被部署到所有類型的機器上,給彈性調度巨大的操作空間。同時,通過Docker技術,一個服務下的所有容器可以被規整為相同的規格,使得服務的流量調度變得更加簡單,簡化了彈性調度的操作。

  Tars微服務架構的主要設計思想是以開發與運營之間DO分離為原則,采用分層思想,将各個層次之間相互解耦或者松耦合。

  最底的協議層:設計思路是将業務網絡通信的協議進行統一,以IDL(接口定義語言)的方式,開發支持多平台、可擴展、協議代碼自動生成的統一協議。在開發過程中,開發人員隻需要關注通訊的協議字段的内容,不需要關注其實現的細節。

  中間的公共庫、通訊框架、平台層:設計思路是讓業務開發更加聚焦業務邏輯的本身。因此,從使用者的角度出發,封裝了大量日常開發過程中經常使用的公共庫代碼和遠程過程調用RPC,讓開發使用更簡單方便;從框架本身的角度出發,做到高穩定性、高可用性、高性能,這樣才能讓業務服務運營更加放心;從分布式平台的角度出發,解決服務運營過程中,遇到的容錯、負載均衡、容量管理、就近接入、灰度發布等問題,讓平台更加強大。

  最上面的運營層,設計思路是讓運維隻需要關注日常的服務部署、發布、配置、監控、調度管理等操作,運維更高效。

  最底的協議層:設計思路是将業務網絡通信的協議進行統一,以IDL(接口定義語言)的方式,開發支持多平台、可擴展、協議代碼自動生成的統一協議。在開發過程中,開發人員隻需要關注通訊的協議字段的内容,不需要關注其實現的細節。

  中間的公共庫、通訊框架、平台層:設計思路是讓業務開發更加聚焦業務邏輯的本身。因此,從使用者的角度出發,封裝了大量日常開發過程中經常使用的公共庫代碼和遠程過程調用RPC,讓開發使用更簡單方便;從框架本身的角度出發,做到高穩定性、高可用性、高性能,這樣才能讓業務服務運營更加放心;從分布式平台的角度出發,解決服務運營過程中,遇到的容錯、負載均衡、容量管理、就近接入、灰度發布等問題,讓平台更加強大。

  最上面的運營層,設計思路是讓運維隻需要關注日常的服務部署、發布、配置、監控、調度管理等操作,運維更高效。

  一方面,希望框架提供的功能和特性更全面、更完整,解決開發和運維面對的一些共性問題,比如涉及到分布式系統的高可用、容錯容災等,涉及運營操作的服務部署、發布、配置、監控、日志等,讓業務開發更加聚焦其業務本身的邏輯開發,提高開發效率,同時讓運維管理更加簡單化、規範化、流程化,提升運維效率;

  另一方面,希望框架支持的能力更靈活,業務可以使用整個系統中的某些部分或者整個功能和特性,這樣業務在接入使用時,可以自主選擇,減少改造成本,滿足不同業務不同場景的需求。比如:終端與後端需要交互的業務,可以隻使用統一的協議層進行通信;已有自身通信協議的業務,可以使用支持自定義協議的通信框架層等;對使用其他框架開發服務的業務,可以使用平台層提供的服務管理、監控等功能特性。

  服務節點可以認為是服務所實際運行的一個具體的操作系統實例,可以是物理主機或者虛拟主機、雲主機。随着服務的種類擴展和規模擴大,服務節點可能成千上萬甚至數以十萬計。 每台服務節點上包括一個Node服務節點和N(大于等于0)個業務服務節點,Node服務節點對業務服務節點進行統一管理,提供啟停、監控服務節點等功能,同時接收業務服務節點上報過來的心跳。

  公共框架節點,數量不定,為了自身的容錯容災,一般也要求在在多個機房的多個服務器上進行部署,具體的節點數量,與服務節點的規模有關,比如:如果某些服務需要打較多的日志,就需要部署更多的日志服務節點。

  Web管理系統:在Web上可以看到服務運行的各種實時數據情況,以及對服務進行發布、啟停、部署等操作;

  Registry(路由+管理服務):提供服務節點的地址查詢、發布、啟停、管理等操作,以及對服務上報心跳的管理,通過它實現服務的注冊與發現;

  Stat(調用統計):統計業務服務上報的各種調用信息,比如總流量、平均耗時、超時率等,以便對服務出現異常時進行告警;

  Property(業務屬性):統計業務自定義上報的屬性信息,比如内存使用大小、隊列大小、cache命中率等,以便對服務出現異常時進行告警;

  Notify(異常信息):統計業務上報的各種異常信息,比如服務狀态變跟信息、訪問db失敗信息等,以便對服務出現異常時進行告警;

  Web管理系統:在Web上可以看到服務運行的各種實時數據情況,以及對服務進行發布、啟停、部署等操作;

  Registry(路由+管理服務):提供服務節點的地址查詢、發布、啟停、管理等操作,以及對服務上報心跳的管理,通過它實現服務的注冊與發現;

  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拉取服務配置信息。

  服務發布流程:在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拉取服務配置信息。

  Tars協議采用接口描述語言(Interface deion language,縮寫IDL)來實現,它是一種二進制、可擴展、代碼自動生成、支持多平台的協議,使得在不同平台上運行的對象和用不同語言編寫的程序可以用PRC遠程調用的方式相互通信交流, 主要應用在後台服務之間的網絡傳輸協議,以及對象的序列化和反序列化等方面。

  框架通過IDL語言協議,可以定義服務提供的接口,并自動生成客戶端和服務端的相關通信代碼,服務端隻需實現業務邏輯即可對外提供服務,客戶端通過自動生成的代碼即可調用服務,調用方式支持三種模式:

  框架通過名字服務來實現服務的注冊與發現,Client通過訪問名字服務獲取到被調服務的地址信息列表,Client再根據需要選擇合适的負載均衡方式來調用服務,負載均衡支持輪詢、hash、權重等多種方式。

  業務服務主動上報心跳給名字服務,使名字服務知道服務部署的節點存活情況,當服務的某節點故障時,名字服務不在返回故障節點的地址給Client,達到排除故障節點的目标。名字服務排除故障需要通過服務心跳和Client地址列表拉取兩個過程,故障排除時間在1分鐘左右。

  為了更及時的屏蔽故障節點,Client根據調用被調服務的異常情況來判斷是否有故障來更快進行故障屏蔽。具體策略是,當client調用某個svr出現調用連續超時,或者調用的超時比率超過一定百分比,client會對此svr進行屏蔽,讓流量分發到正常的節點上去。對屏蔽的svr節點,每隔一定時間進行重連,如果正常,則進行正常的流量分發。

  為了防止業務因為訪問量突增或服務器故障造成系統整體的繁忙,進而導緻全部服務的不可用,框架内部做相應設計來應對。實現請求隊列,服務調用通過非阻塞方式實現異步系統,從而達到提升系統處理能力的目的。并且對隊列的長度進行監控,當超過某個閥值,則拒絕新的請求。對請求設置超時時間,當請求包從隊列裡讀取出來是判斷請求是否超時,如果超時則不做處理。

  框架提供了對某服務某接口的特定請求進行染色的能力,染色的消息可以透傳到後面需要訪問的所有服務上,對染色的請求,服務自動把日志上報到特定的染色日志服務器上,使用者隻需在染色服務器上即可分析請求訪問的路徑,方便跟蹤定位問題。

  為了加快服務間的訪問速度,建設跨地區、跨機房調用帶來的網絡資源消耗,減少網絡故障帶來的影響,框架提供了跨地區、跨機房,就近接入的功能。

  為了方便對業務服務部署管理進行标準化和容量化,框架提供了Set部署能力,set之間沒有調用關系,互不幹擾,故障隔離,提高運維效率和服務可用性。

  為了更好反映和監控小到服務進程、大到業務的運行質量情況,框架支持以下數據上報的功能:A.提供了服務模塊間調用信息統計上報的功能,方便用戶查看服務的流量、延時、超時、異常等情況;

  B.提供了用戶自定義屬性數據上報的功能,方便用戶查看服務的某些緯度或者指标,比如内存使用情況、隊列大小、cache命中率等;

  C.提供了服務狀态變更和異常信息上報的功能,方便用戶查看服務的何時發布過、重啟過、宕過以及遇到的異常緻命錯誤等;

  對業務配置進行集中管理并且操作web化,使配置修改更容易,通知更及時,配置變更也更安全;對配置變更進行曆史記錄,讓配置可以輕松回退到前一版本。配置拉取服務化,服務隻需調用配置服務的接口即可獲取到配置文件。

  應用配置為最高一級的配置文件,它是多個服務配置提煉出來的公共配置,服務配置通過引用它來使用其配置内容。

  應用配置為最高一級的配置文件,它是多個服務配置提煉出來的公共配置,服務配置通過引用它來使用其配置内容。

  目前騰訊内部和外部開源的框架的核心功能和代碼都是一樣的,主要區别在于運維側,精簡和優化了和内部系統耦合比較深、以及内部運維管理相關的一些功能特性。

  Tars适合消息調用客戶端和服務端比較明确的業務場景,不太适合消息需要訂閱/發布的業務場景。

  一是Tars提供了支持多語言(C++/Java)的高性能(性能可達40w/s)RPC開發框架,比如業界開源的Dubbo隻支持Java,業界開源的Thrift、gRPC性能沒有Tars好;

  二是Tars具有針對服務進行治理的運營管理平台,比如名字路由與發現、部署/發布/擴縮容、立體化監控、日志管理、配置管理等,讓系統的運行狀态一切盡在掌握,而業界的Thrift、gRPC隻是RPC通信框架,業務在它們之上還要做很多時期;

  三是Tars經過多年在不同業務上的實踐和發展,其成熟度和穩定性更好,目前騰訊内部有160多個業務(比如手機浏覽器、應用寶、手機管家、手機QQ等)、在上萬台機器上在使用Tars框架。

  鐘科,十餘年的互聯網工作經驗,主要負責騰訊移動互聯網事業群的基礎框架平台的建設,專注于微服務架構、雲平台、分布式NoSQL存儲等技術領域。

上一篇:社交化協同辦公平台

下一篇:互動未來丨一站式企業互聯網化服務


酷圖熱圖

最受歡迎7家旅行預訂
樓市|學習新加坡模式—
想建一個同城生活服務
幹将莫邪古法鑄劍技藝

Powerd by 荊門百姓網 版權所有

冀ICP備16008783号-1

免責聲明:本網站所刊登、轉載的各種圖片、稿件是為傳播更多的信息,本網不承擔此類稿件侵權行為的連帶責任。

違法信息舉報:企鵝:1 2 6 9 2 4 5 3 8 1