摘要：什么是是騰訊從年到今天一直在使用的后臺邏輯層統一應用框架的開源版本，目前支持和三種語言。目前該框架在騰訊內部的各大核心業務都在使用，頗受歡迎，基于該框架部署運行的服務節點規模達到上萬個。

| 博客文章

你所不知的TARS，卻幫閱文集團完成技術架構變革！
——TARS開啟閱文集團技術架構變革之門

作者簡介｜歐樑
后端研發架構師，現任職于閱文集團技術部基礎服務研發組，一直致力于Java應用架構設計以及業務架構演進研發，對分布式系統架構有深入理解。

0x00 什么是TARS
TARS是騰訊從2008年到今天一直在使用的后臺邏輯層統一應用框架（Total Application Framework）的開源版本，目前支持C++,Java和NodeJs三種語言。
該框架為用戶提供了涉及到開發、運維、以及測試的一整套解決方案，幫助一個產品或者服務快速開發、部署、測試、上線。 它集可擴展協議編解碼、高性能RPC通信框架、名字路由與發現、發布監控、日志統計、配置管理等于一體，通過它可以快速用微服務的方式構建自己的穩定可靠的分布式應用，并實現完整有效的服務治理。
目前該框架在騰訊內部的各大核心業務都在使用，頗受歡迎，基于該框架部署運行的服務節點規模達到上萬個。內外部版本在代碼結構、功能上基本相同。本文基于私有云版本的TARS，部分功能可能與目前開源及公有云TARS版本有所區別。

0x01 使用TARS的原由
一年半前，公司后端服務技術棧是.net加上各種Oracle存儲過程，就著當年頂級服務器，裝配著windows server前前后后浩浩蕩蕩300多臺。不論好壞，撐起了10多年網絡文學的情懷。
現今，隨著IP熱潮的涌動以及公司業務的飛速擴展，什么都不用說了，必須重構。
于是乎，我們選擇了90%的人會選擇的，擁有成熟技術圈的JAVA來做這件事情。秉承快速構建、共性開發、持續集成、快速迭代的理念，我們順理成章地開始了。
去年年初的某日，運維側力薦TARS。一時掀起波瀾，“這個東西學習成本如何？”，“和騰訊側用的是一套嗎？”，“用于線上合適嗎？”。揣著疑惑和擔心，看了內部使用資料和壓測報告（如今官方立碑于此https://github.com/Tencent/TA...），開始了TARS之旅。

0x02業務集的現狀
公司TARS業務服務集每日接口調用最大值近百億，單業務峰值可在數萬每秒，近300種業務服務。對于常規的開發部署方式，必然會花費大量成本進行編碼、部署以及運維的統一。使用TARS則輕松很多，正是TARS優秀的服務表現，為公司的APP抗住了515書友粉絲節，百萬紅包，除夕手Q線上聯動等過億級用戶量的活動。
][2]
業務集結構

0x03 TARS哪里好
TARS是個大而全的分布式應用。拋開對開發部署習慣的改變，用了TARS之后，確實省卻了很多且又方便了很多。
服務容錯方面，TARS擁有基本的容錯和負載均衡，讓我們可以忽略間歇、偶發、永久的設備故障，任何一臺服務器down掉都不影響業務訪問，同時提供對網絡異常，超時節點屏蔽，定時重試和流量導回的切換能力。
高性能方面，TARS運用Reactor模型以及能夠高效支持百萬級別的句柄監聽——Epoll ET。為TARS框架提供高達41w/s吞吐量。
伸縮性方面，擴容是業務發展必不可少的過程，TARS對平滑擴容提供良好支持，流程化的配置可完成無感知的服務擴容升級。
管理和運維方面，TARS自帶監控模塊，對主調反饋做了實時統計，在管理界面提供了多維度性能數據圖。供開發及運維判斷當前服務狀態，并可配置參數閾值進行短信或微信告警通知。

0x04 TARS的具體使用方法

TARS開發流程

01.開發TARS，必須知道如何撰寫JCE接口文件
JCE接口文件借鑒了ICE[1] ，引入代碼生成的思路，并結合無線側手機的應用場景，做到了編解碼效率和網絡帶寬使用的權衡考慮。TARS的JCE接口描述語言文件是以.tars后綴結尾的。
下圖為JCE文件：
[1] ICE是什么：ICE?，Internet Communications Engine，是一個面向對象，適用于異構環境的中間件平臺。

JCE文件

對于一個上層業務服務，調用5-6個基礎TARS是常有的事情。摸清產品業務后，分別找到對應服務的開發。由于每個服務基本是一個TARS服務，所以溝通一個服務只需3步：1、“××服務的JCE能給我下嗎？！”；2、傳來一個JCE文件；3、“Thanks”；
JCE的內容都是約定俗成的，對應的結構體和接口也有相應注釋。所以，溝通就是那么簡潔明了。

02.JCE與TARS服務端的實際開發
通過jce-maven-plugin編譯，可生成特定Servant接口。繼承接口就可實現業務邏輯。

Servant接口

繼承類

在遵循TARS規范的java項目里面，services.xml中配置此繼承類。

services.xml
TARS項目有特定目錄結構，具體結構如下圖gateway。service項目為一個普通java project，可在本地開發通過后，發布jar類庫引入gateway中，TARS容器只需編譯gateway即可。

TARS目錄結構

TARS的目錄結構以及嚴格maven化，省去了開發邏輯代碼多帶帶打包的過程。同時嚴格的區分了開發及上線測試流程，對規范研發管理流程有極大的幫助。

03.TARS客戶端調用流程
獲取Communicator實例
CommunicatorConfig cfg = CommunicatorConfig.load("config.conf");
Communicator communicator = CommunicatorFactory.getInstance().getCommunicator(cfg);

獲取ServantProxyConfig實例并配置
ServantProxyConfig proxyConfig = new ServantProxyConfig(taf.serverName);

TARS config對象常用參數設置

調用Communicator的stringToProxy方法并傳入ServantProxyConfig實例，最后返回Jce生成的動態代理對象，并調用對應的方法。
communicator.stringToProxy(api, proxyConfig);

ServantProxyFactory中創建動態代理對象

TARS支持接口同步或異步調用，通過對config對象超時時間的設置，可以實現軟件層面的服務過載保護。
同步調用:
HelloPrx prx = c.stringToProxy("TestApp.HelloServer.HelloObj");
//發起遠程調用
prx.hello(1000, "hello word");
異步調用:
HelloPrx prx = c.stringToProxy("TestApp.HelloServer.HelloObj");
//發起遠程調用
prx.async_hello(new HelloPrxCallback() {

    @Override
    public void callback_expired() { }
    @Override
    public void callback_exception(Throwable ex) { }
    @Override
    public void callback_hello(String ret) {
        System.out.println(ret);
    }
}, 1000, "hello word");

從去年到現在，公司遷移改造如火如荼的進行。主要目標是從.net代碼中閱讀邏輯，用JAVA改寫成一個個TARS服務。同時提供更高的可用性，為公司app相關的新需求迭代保駕護航。
在這個過程中，對于app的接口提供層（Tomcat部署）改動極大，從原來直接訪問數據持久層到調用一個個TARS微服務，其中不乏一些問題。
曾經一段時間，對于TARS的接入采取了最簡單有效的同步方式，并利用TARS提供的客戶端同步超時配置來處理接口超時。結果，一個訪問頻繁的讀取接口由于網絡傳輸的不穩定，會導致連鎖的處理線程獨占，從而降低整個服務吞吐能力，并伴有重啟等現象。
經過jvm，gc等分析，改用TARS提供的異步方式獲取接口返回以及編碼層面細粒度的超時控制，基本解決了上述問題。目前，業務層調用總量也翻了番（峰值從當時120W左右到目前250W），節省了一半的設備。
TARS被調方式的多樣性也對不同業務場景支持更加全面。

JCE-WUP協議
TARS除了支持客戶端通過JCE生成類的調用方式，還可以發起WUP數據包協議調用。

什么是WUP：
WUP（wireless uni-protocol）無線統一協議
基于JCE編碼的命令字(Command)層協議封裝
UniPacket實現請求與回應包對象的封裝
支持協議動態擴展
序列化的數據可用于網絡傳輸或者持久化存儲
支持直接調用TARS的服務端

JAVA版本封包方式
TafUniPacket uniPacket = new TafUniPacket();
uniPacket.setTafVersion(Const.VERSION_WUP3);
uniPacket.setEncodeName("UTF-8");
uniPacket.setServantName("TestApp.HelloServer.HelloObj");
uniPacket.setFuncName("hello");
uniPacket.put("word", "Hello World");
byte[] sendPackect = uniPacket.encode();
隨后自己使用Socket發包，調用信息為TARS服務物理機URL，而非主控URL。
TARS通過輪詢或者健康統計來選擇可用URL。
具體邏輯可查看tars-core源碼，com.qq.TARS.client.cluster.DefaultLoadBalance類：

對應于WUP，TARS有相同的概念TUP。相關工具類為TARSUniPacket，封包、解包、調用TARS服務方式完全一樣。
https://github.com/Tencent/TA...

05.結合版本控制工具編譯和發布
TARS支持常用版本控制管理工具的關聯編譯：SVN/GIT。錄入SVN路徑，可掃描到該路徑下有效的分支。錄入GIT路徑，可掃描該目錄下有效TAG分支。

TARS編譯界面

發布的相關日志管理也集成在平臺中，可實時確定發布情況。

TARS發布界面

所有的TARS項目用的編譯發布都是一套，通過一定隊列分配進行作業。編譯后會生成唯一的發布版本。存儲了歷史發布記錄，可追溯，方便回滾。
團隊中有很多業務開發并行進行，會創建很多分支。有時你想學習別人的代碼，但又發現有很多分支無法確定目前線上運行的版本，通過發布日志就可查詢最近發布的版本分支。

06.TARS提供了容器接口測試功能
服務正常發布后，遵循TARS自定義入參出參的格式，即可調用JCE中定義的方法進行自測。

TARS接口測試

對于一個接口的開發，本地測試完，只能說接口邏輯通了。放到線上可能會出種種問題，環境配置、接口性能、接口未能符合分布式的考慮等等。這個測試功能無疑是可以驗證線上是否正確的良好手段。
加上TARS的接口可以轉換暴露成HTTP形式，所以，QA與我們達成一致，每次提測的接口必須提供HTTP的調用。這樣既方便的了功能驗證，又可以遵循原先的壓測形式。

07.服務多維度監控
服務調量和性能指標監控直觀反應服務運行情況，通過不同維度的設置和查詢，可迅速評估流量高峰、定位響應異常、查看調用路徑以及優化調用毛刺。

TARS監控已經成為我們定位問題的第一入口。流量抖動和耗時增加基本可以一目了然。監控還細化到接口維度，為“閑暇時間”接口優化提供了參考。

08.TARS提供了豐富的參數配置
TARS的默認配置對于平日開發維護基本夠用。對于特殊業務的特定配置，TARS同樣支持，可通過調節各種參數來增加服務表現。舉例TARS-JAVA，可通過節點服務管理增加Reactor模型工作線程數，亦可通過修改配置模板調優jvm參數或服務超時等特性。
記得某業務服務從Tomcat改用TARS。原因不必多說，主要是默認了TARS的高吞吐以及容錯等特性。可運行一天后，突然收到了短信告警，平均耗時超過閾值。打開TARS監控觀察，調用量沒有明顯上漲，調用曲線也符合之前業務特性。
“怎么耗時一直在慢慢上漲”。當時第一反應是不是代碼層面問題，排查了一圈，基本確定和原有“湯姆貓”上運行的代碼一致，除了適配TARS入口調用的代碼。再查看了物理機的監控，CPU/IO/MEM均沒有特別異常。
通過對TARS特性監控的查看，注意到相關監控中req.queue.waitingtime(請求在隊列中等待時間)，jvm.thread.num(jvm當前線程總數) 確有異常。等待時間曲線階段性增長，線程數卻不多。初步判定應該與服務器處理線程有關。
“都是應用服務器，處理能力怎么那么低，如果是Tomcat會器調整maxConnections，acceptCount等等”。
倒騰了半天，原來TARS也支持容器性能細粒度的修改。于是把工作線程數，從默認配置的5改成了32，重啟觀察一陣，現象沒有再發生。
TARS同時提供私有模板功能，可做更細粒度的配置，甚至jvm層面的調優。把配置能力沒有保留的提供給使用者也是個優秀架構易用性的重要體現。

0x05 TARS的展望
Tencent已于2017年04月10日正式在github上對外開放了TARS的開源版本，同時提供了技術討論群（qq技術交流群：579079160），并表示會內部一直使用和對外一直維護。

可以預見，TARS將能夠支持更多天馬行空的產品需求，對于業務支撐和線上極端情況的容錯度將越來越大。希望這篇科普可以勾起各位的興趣，幫助大家早日加入使用TARS的行列。