來自零點智慧社群

一、前言

TAF，一個後臺邏輯層的高效能RPC框架，目前支援C++,Java, node 三種語言， 往後可能會考慮提供更多主流語言的支援如 go等，自定義協議JCE，同時也支援HTTP。 它集可擴充套件協議編解碼、高效能RPC通訊框架、名字路由與發現、釋出監控、日誌統計、配置管理等於一體，通過它可以快速用微服務的方式構建自己的穩定可靠的分散式應用，並實現完整有效的服務治理。

當前已開源，易名為“TARS”，趕緊上github去star一下吧。

此係列文章選用Java語言進行描述，先對TAF部署開發環境、相關概念和整體架構做介紹，後面分taf-server、taf-client兩部分展開，相關文件不多，主要從程式碼上進行理解。

二、部署開發環境

1. 部署

TAF的部署有管理平臺的支援，如果是147或213測試環境，申請服務節點和部署都不需要管理人員的審批，已經接入docker環境，按需申請，上線成功後支援動態擴容，非常方便，使用完關閉下線即可。

2. 開發

需要使用maven進行專案管理，引入如下依賴：

<dependencies>
		<dependency>
			<groupId>qq-central</groupId>
			<artifactId>taf-server</artifactId>
			<version>
 
3.0.0-SNAPSHOT</version>
		</dependency>
		<dependency>
			<groupId>qq-central</groupId>
			<artifactId>taf-proxy</artifactId>
			<version>3.0.0-SNAPSHOT</version>
		</dependency>
</dependencies>

然後需要在code平臺上建立一個svn程式碼倉庫，將建立好對應的位置填寫到管理平臺的編譯選項中，這樣平臺就可以直接從你填寫的位置去拉取程式碼到編譯機上進行編譯了。注意：程式碼倉庫需要新增一個使用者svn_taf 的讀許可權；當然也可以採用其他的編譯方式，如申請編譯機和開發機，可km上查詢並理解區分一下taf 測試機，編譯機，開發機。

最後需要有一個mnet 跳板機，這個需要leader審批，申請之後安裝go工具用來遠端登入taf節點看日誌，這樣準備工作就基本完成了。

在開發中只需要關注業務邏輯實現即可，但如果想進一步瞭解清楚框架底層的機制和實現，後面的文章將進行相關探討。

部署開發過程如下圖所示：

三、整體互動流程

官方文件的這張圖再清晰不過了

其中registry為主控服務，提供路由查詢； 另外這裡的patch為釋出服務請求，傳達到patch服務後由node服務在各個節點上拉起；

petsvr服務會定期上報心跳到node服務，由node服務統一將心跳上報registry，我覺得這樣是要比單獨一個個上報更加高效的，同時可以向petsvn傳送管理admin命令；

下面的各個服務節點就是TAF提供的運營支援，定期上報統計資訊到stat，列印遠端日誌到log，定期上報屬性資訊到property、上報異常資訊到notify、從config拉取服務配置資訊 ；

最後需要注意，Java部分程式碼沒有主控的實現，僅包括Server和Client端，但在使用上只要將registry，node和各個運營服務部署執行成功，服務之間都是可以通過走JCE協議進行互動的。

四、配置管理

TAF有配置管理服務，此外管理平臺上也有許多配置項，程式碼中有很多地方都會從配置檔案中讀取配置項的，容易搞混，這裡先簡單做個介紹。

服務上線後，跳板機登入進入到目錄 /usr/local/app/taf，展開目錄結構如下：

├── app_log -> /dockerdata
└── app.service
    ├── bin
    │   ├── apps
    │   ├── conf
    │   ├── lib
    │   └── log
    ├── conf
    │   └── app.service.config.conf
    └── data
        └── tafnodes.dat

其中：app.service為你上線服務對應的應用名和服務名；

apps目錄下的ROOT即為專案程式碼資源所在位置；

管理平臺的服務配置項上新增的配置檔案，可push或拉取到本地 bin/conf 目錄；

另外，有三個重要的預設目錄提一下，

應用根目錄：basepath=/user/local/app/taf/app.service/bin

日誌目錄：logpath=/user/local/app/taf/app_log

資料目錄：datapath=/user/local/app/taf/app.service/data

當然以上這些配置你也在配置檔案中看到，管理平臺上的操作為：

服務管理頁中，點選私有模版可對模版進行更改；

點選Servant管理頁可對單個服務的最大連線數，執行緒數，執行緒池大小，是否灰度等選項進行更改，如下圖：

五、RPC

RPC（Remote Procedure Call），即遠端過程呼叫，可理解為一種通訊協議，該協議允許運行於一臺計算機的程式呼叫另一臺計算機的子程式。使用RPC框架的好處就是不需要額外編寫網路互動這部分程式碼了，這部分程式碼編寫上也極容易出錯，因此框架相當於在Socket層之上做了一層可靠的應用層封裝。另外，遠端呼叫涉及資料包的編解碼，框架通常會定義介面描述語言（Interface Description Language，IDL），方便跨平臺的遠端過程呼叫。

TAF框架正是提供了以上問題的完整方案，服務端採用非同步NIO通訊模式，客戶端可支援同步或非同步呼叫； 資料編碼提供了JCE協議支援，同時支援編寫IDL執行指令碼實現程式碼自動生成。從某種意義來說，我覺得可以簡化跨語言混合程式設計，

在服務端處理客戶端的併發請求中，TAF實現上採用了Reactor多執行緒模式，這裡貼兩張網上看到覺得比較好的NIO時序圖，有利於理解。

服務端：

客戶端：

下節單獨對TAF執行緒模型做介紹。

感謝閱讀，有錯誤之處還請不吝賜教。

上週答辯結束，終於有時間把之前整理的整理一下

這段時間的實習還是收穫良多，除了技術上的，還有思維邏輯和方法論上的吧，有許多的致謝，留待以後慢慢言謝吧

0827 update：

不知不覺已完成了預期的總結，該系列文章彙總如下，歡迎閱讀指教，交流學習：

TAF-必修課（一）：整體架構理解

TAF-必修課（二）：Reactor多執行緒模型

TAF-必修課（三）：Server啟動全過程

TAF-必修課（四）：過載保護

TAF-必修課（五）：Client端呼叫

TAF-必修課（六）：容錯

TAF-必修課（七）：負載均衡

當然，TAF相關的內容遠不止這些，比如這裡暫時沒有具體探討的還有：協議、IDC分組、Set部署、就近接入、日誌相關、訊息染色、配置中心、運營監控服務等；

計劃往後繼續深入學習慢慢補充，或許還可以搞成一個系列，再升級到選修課 …..（先給自己定個小目標，比如 * * *是吧）

由於水平有限，文章難免有錯誤或紕漏之處，請各位看官不吝賜教