摘要：年月日，在上海舉行的第六屆中國開發(fā)者大會上，騰訊開源項目首次全面發(fā)布版本，閱文集團高級開發(fā)工程師梁晨對如何通過構建高性能框架做了經驗分享。分享內容作為騰訊開源的框架，在發(fā)布之后即受到開源領域的關注。閱文集團本身也有一塊新的業(yè)務在使用。

2018年5月19日，在上海舉行的第六屆中國PHP開發(fā)者大會（PHPCon）上，騰訊開源項目TARS首次全面發(fā)布PHP版本，閱文集團高級開發(fā)工程師梁晨對PHP如何通過TARS構建高性能RPC框架做了經驗分享。

TARS作為騰訊開源的RPC框架，在發(fā)布之后即受到開源領域的關注。它在微服務、協(xié)議、多語言和運營體系上的支持，都非常的完善。在微服務方面，實現(xiàn)了服務自動發(fā)現(xiàn)、智能調度、容災容錯、柔性熔斷，以及路由與灰度的功能。與此同時，通過使用私有二進制協(xié)議，可以有效的降低服務之間調用的流量。而在語言支持的層面，TARS對C++、Java、Nodejs、PYTHON都提供了比較好的方案。考慮到PHP在WEB后臺領域的使用非常的廣泛，TARS-PHP的出現(xiàn)，勢在必行。

那么在設計TARS-PHP的時候，必須考慮到現(xiàn)有PHP的開發(fā)生態(tài)，至少要做到 功能完善、靈活、輕量和高效。在功能方面，TARS-PHP對標了現(xiàn)有的C++、JAVA、NodeJS的功能體系，做到了對CLIENT能力和SERVER能力的支持。而在靈活方面，PHP一直是出類拔萃的，作為泛型腳本語言，開發(fā)的過程，誰用誰知道。而在輕量設計方面，TARS-PHP遵循一個最簡化、輕量級、可插拔的設計想法，讓整個方案自成體系的同時，也能具備最大程度的可擴展性。最后，也是最重要的，高效。通過引入PHP業(yè)界優(yōu)秀的SWOOLE框架，再結合SWOOLE2.0的協(xié)程能力，讓TARS-PHP插上協(xié)程的翅膀。

TARS-PHP的解決方案，按照功能模塊，會分成以下四個部分：

TARS-CLIENT

TARS-EXT擴展

TARS-SERVER

開發(fā)效率模塊

TARS-CLIENT
對于熟悉TARS-PHP的同學來說，TARS-CLIENT的能力在半年前就已經開源，并提供使用了。本次TARS-PHP的重新設計，也對TARS-CLIENT現(xiàn)有的能力做了一個梳理。全新設計之后的TARS-CLIENT具備了配置統(tǒng)一化、一鍵調用、以及多種網(wǎng)絡能力的特點。而在功能上，集成也更為豐富了，現(xiàn)有的TARS-CLIENT由如下的功能模塊組成：

自動尋址：CLIENT再也無需關系服務地址

主調上報：調用情況會默認進行主調上報，服務情況一覽無遺

遠程日志：日志可以寫入遠程服務，再落地，降低文件IO的損耗

網(wǎng)絡能力：SOCKET、SWOOLE同步、SWOOLE協(xié)程

全新設計后的TARS-CLIENT，既可以滿足后臺系統(tǒng)的SOCKET請求需求，也能夠滿足在SWOOLE中進行同步和協(xié)程的兩種調用需求，用戶只需要靈活的按照配置各取所需。同時，全新集成的自動尋址、主調上報、遠程日志功能，會讓用戶在使用的時候，更加的無感知，更加的順暢。

下面即是現(xiàn)有TARS-CLIENT的使用demo：

可以清晰的看到，統(tǒng)一化的配置，層級更為清晰，而且調用者無需關心底層細節(jié)，尋址和主調上報已經悄然完成。

再從整體的角度來看一下TARS-CLIENT的方案：

從圖中可以更為清晰的看到底層實現(xiàn)的細節(jié)。對于自動尋址而言，實現(xiàn)自動并不完全解決問題。因為每次都去詢問服務的地址，會給主控服務帶來很大的壓力。因此結合了PHP本身的能力之后，選用了SWOOLE TABLE和本地文件作為緩存的方式。緩存時間由服務啟動時默認指定，那么在這個時間之內，便不會再次進行主控的請求。降低了主控壓力的同時，也降低了本地獲取服務地址的耗時。

而如下圖所示：主調上報的策略中，也能夠根據(jù)實際的網(wǎng)絡收發(fā)情況，進行耗時、失敗率、超時率、服務端異常的及時上報，方便業(yè)務盡快發(fā)現(xiàn)和定位問題。

TARS-EXT擴展
在TARS-CLIENT的底層，包含很多二進制協(xié)議的打包解包工作。而這些字符串的拼接和拷貝的操作恰恰是PHP的弱項，因此非常有必要將其抽象出來，作為獨立的PHP擴展模塊開發(fā)。

在現(xiàn)有擴展的體系中，主要包含了對高性能和穩(wěn)定性兩方面的考慮。高性能方面，字符串操作完全通過純C語言進行了實現(xiàn)。而同時通過合理設計接口，避免一次組包的多次操作，從而進一步提高效率。

而在擴展的穩(wěn)定性方面，通過引入phpt的擴展標準測試，以及Valgrind工具進行內存泄露測試。測試代碼覆蓋率達到了80%以上。同時每次進行內部版本代碼提交的時候，會自動觸發(fā)從PHP5.6~PHP7.2的主流版本自動構建測試，并在發(fā)生構建異常的時候，發(fā)送郵件。

下圖中可以清晰的看到，相比于原有的使用純PHP打包解包的方式，使用擴展的方式，在簡單協(xié)議的情況下，打包效率提升了16倍，解包效率提升了14倍。而在復雜協(xié)議的情況下，同樣效率的提升也達到了12和9倍之多。

TARS-SERVER
PHP作為SERVER走過了一段相對比較曲折的道路。最早時候，PHP是作為Apache的一個模塊，來提供HTTP-SERVER的服務的。后來在Nginx越來越盛行的情況下，PHP_FPM應運而生。它比Apache的預先申請所有進程的方式稍好一些，但是仍然受制于進程資源和接受請求的能力，因此效率并不是很高。在這種大背景之下，SWOOLE應運而生，它基于多進程的模型，常駐內存并且使用epoll的事件驅動模型來處理收到的請求。因此在IO能力上甩之前的解決方案好幾條街。而在去年，SWOOLE2.0的出現(xiàn)，內置協(xié)程，同步編程的同時享受異步IO，更是如虎添翼。

基于此，TARS-SERVER的解決方案也會以SWOOLE作為底層的運行環(huán)境，開發(fā)出了TARS-HTTP-SERVER、TARS-TIMER-SERVER和TARS-TCP-SERVER，并且三個框架合一，只需簡單配置，即可順暢使用。

上圖中，可以很清晰的看到強大的TARS-SERVER能力。除了提供最底層的三種基本SERVER類型之外。我們還提供了TARS-UTILS用來處理配置文件解析，TARS-Report用來進行服務保活的定時上報，TARS-Config用來拉取平臺下發(fā)的配置，TARS-Property用來進行特性上報，以及TARS-Deploy模塊進行業(yè)務代碼的打包。這一整套的體系，使得TARS-SERVER的使用者既能夠實現(xiàn)自己的業(yè)務邏輯，也能夠針對性的進行拓展。可謂一舉兩得。

總的來看，我們的TARS-SERVER，基于SWOOLE 1.x和2.x，同時能夠很順暢的支持靈活的配置，如SWOOLE的配置和用戶自己的配置。除此之外，TARS-SERVER通過自動生成的注解進行請求的路由，開發(fā)者完全不需要關心，只需要關注于實現(xiàn)自己的業(yè)務邏輯即可。而另一方面，TARS-SERVER還額外提供了一個管理端口，用來接收平臺下發(fā)的指令，如SHUTDOWN、配置下發(fā)等等。

TARS-HTTP-SERVER為了滿足邏輯層服務的需求，進行了專門設計。一期中包括了GET/POST基本支持、Cookie/Status標準支持、極簡的路由組件實現(xiàn)、FILE上傳功能模塊以及服務可用探測接口模塊。

而TARS-TIMER-SERVER的使用也非常方便，只需如下代碼：

時間可以靈活控制，同時所有定時服務放在一起也非常的方便管理。TIMER在服務啟動的時候，也會自動啟動，無需再次觸發(fā)。TIMER的數(shù)量，只受制于SWOOLE啟動時候的進程數(shù)量，開發(fā)者可以靈活的調配。

對于開發(fā)者非常關心的服務性能，我們也針對不同的接口、版本、CLIENT進行了壓測，結果如下：

從數(shù)據(jù)來看，還是非常的令人滿意。空跑的HTTP SERVER QPS最高達到了23萬。而使用了協(xié)程CLIENT之后，在混合RPC調用的情況下，仍有2萬1的QPS，相比于同步CLIENT，提升了50%左右。充分說明了協(xié)程CLIENT對于性能的提升作用明顯。

開發(fā)效率
在進行TARS-PHP設計的時候，一個必須要考慮的問題，就是開發(fā)效率。為了遵循TARS本身的設計理念，TARS2PHP工具也進行了全新的升級，通過配置文件的方式，同時兼容了客戶端代碼和服務端代碼的生成，配置文件中會包含服務信息、TARS文件信息、命名空間信息等等：

從下圖中，能夠更加明顯的看到整個開發(fā)的路徑：

由此，通過TARS文件、TARS2PHP工具，就能夠完全實現(xiàn)客戶端和服務端的代碼生成，并且兩端通過協(xié)議完全解耦，大大提高了開發(fā)效率。

TARS-PHP在閱文
TARS-PHP在閱文經過了一年多的驗證和使用，也逐步趨向成熟，越來越多的業(yè)務開始了解和使用TARS-PHP這套方案，并為他們在實際的開發(fā)和運維中帶來了收益。

從下圖中可以非常明顯的看到TARS與TARS-PHP在運維的使用情況：

模板拼接的Node HTTP服務有10+，邏輯API層PHP服務與定時服務 40+，后臺TCP服務100+，每日之間億級調用。

后續(xù)規(guī)劃
隨著TARS-PHP整套方案越來越成熟，希望更多的公司和開發(fā)者能夠加入進來，共同建設。考慮到不同公司使用的框架并不相同，因此我們的模塊化設計做得非常徹底，在對SWOFT框架進行接入的過程中，模塊化的方式體現(xiàn)了非常大的成效，只需要半天到一天的時間即可完成。后續(xù)TARS-PHP也會進一步豐富CLIENT能力，同時支持更多的現(xiàn)有框架，在提高穩(wěn)定性的同時，對SERVER本身的功能豐富性，再做提升。TARS-PHP，等你來！

問：一個中小型的公司如何使用TARS
答：其實tars本身并不是非常的重量級，它主要是包含了一個一體化的運維系統(tǒng)，以及專注于業(yè)務開發(fā)的一個rpc體系。閱文集團本身也有一塊新的業(yè)務在使用TARS。項目的機器規(guī)模也只是在幾十臺機左右，所以對于中小企業(yè)的公司來說，TARS也是一個可行的方案。

問：搭建一個TARS平臺成本比較高?如何解決這個問題
答：我們看到dockerhub?上面已經有了開發(fā)者?熱情的開發(fā)者，做出了一套包含環(huán)境的Docker容器，我們會考慮功能是否完善,把它合進來或者是制作官方的鏡像，這樣用戶在運行的時候就會非常方便了。

問：TARS-PHP對于不同通信和二進制協(xié)議本身的支持怎么樣
答：現(xiàn)在TARS-PHP?TCP服務支持的協(xié)議，僅限于TARS二進制協(xié)議本身?但同時我們也提供了一些配置方式和接口，供大家實現(xiàn)自己的協(xié)議。而使用HTTP?SERVER的話，協(xié)議都是可以自己選擇的，比如JSON等等。

問：對于將已有PHP+Swoole1.x的項目遷移至TARS上，需要注意什么問題以及有沒有比較合適的解決方案
答：閱文集團之前也是各個PHP項目分別獨立部署在服務器上，沒有接入TARS平臺，但在去年經過1個月左右的改造已經全部遷移至TARS平臺，將已有項目遷移至TARS平臺除了需要對項目做一些必要的改造之外還需要保證后端TCP服務也已經接入TARS，遷移可能會有一些成本，但是之后便能享受到TARS平臺帶來的一系列的紅利。

https://github.com/Tencent/Ta... php目錄內下載

對TARS使用還有任何問題，歡迎加入QQ交流群：
TARS交流群: 群號669339903 TARS-PHP交流群:群號:769531734