摘要：引言作為由騰訊公司開源的優(yōu)秀框架與服務(wù)部署運(yùn)維解決方案，被閱文集團(tuán)引入了實(shí)際實(shí)踐中，同時閱文集團(tuán)對在語言層面進(jìn)行了能力的補(bǔ)全，令如虎添翼。作為騰訊公司的優(yōu)秀框架與服務(wù)部署運(yùn)維解決方案，可以滿足上述的所有需求。

梁晨(Ted)，任職閱文集團(tuán)技術(shù)中心，負(fù)責(zé)起點(diǎn)中文網(wǎng)的WEB后臺開發(fā)工作。曾負(fù)責(zé)騰訊上海企業(yè)產(chǎn)品部營銷QQWeb后臺開發(fā)、QQ公眾號Web后臺開發(fā)，對大型網(wǎng)站技術(shù)架構(gòu)，有自己的經(jīng)驗(yàn)和見解。騰訊開源項(xiàng)目TSF2.0框架開發(fā)者，騰訊開源組件Tars-PHP開發(fā)者，也曾是騰訊公司多個PHP擴(kuò)展組件的開發(fā)者與維護(hù)者。

TARS作為由騰訊公司開源的優(yōu)秀RPC框架與服務(wù)部署運(yùn)維解決方案，被閱文集團(tuán)引入了實(shí)際實(shí)踐中，同時閱文集團(tuán)對TARS在PHP語言層面進(jìn)行了能力的補(bǔ)全，令TARS如虎添翼。TARS-PHP的解決方案兼具簡單高效、接口維護(hù)方便容易擴(kuò)展、代碼自動生成，以及集成尋址、服務(wù)發(fā)現(xiàn)、監(jiān)控、上報(bào)等功能。經(jīng)歷了閱文集團(tuán)線上業(yè)務(wù)的考驗(yàn)與洗禮，充分證明了該解決方案的優(yōu)勢。

項(xiàng)目地址：https://github.com/Tencent/Ta...

眾所周知，在PHP誕生之初，就是WEB站點(diǎn)的開發(fā)而生。但是一直以來，都無法擺脫弱類型、腳本語言的性能之殤的帽子。隨著互聯(lián)網(wǎng)行業(yè)的不斷發(fā)展，以及用戶需求和基礎(chǔ)架構(gòu)的不斷變化，PHP語言本身也一直在發(fā)展。無論是SWOOLE的出現(xiàn)，還是PHP7對性能的提升，都豐富和助力了PHP本身的應(yīng)用。

相信大家在開發(fā)中也會發(fā)現(xiàn)，作為經(jīng)常處在WEB中間層的PHP，其實(shí)有很多的痛點(diǎn)。既要接收前端的HTTP請求，又要調(diào)用各式各樣的后臺服務(wù)與存儲服務(wù)，常常成為一個站點(diǎn)的性能瓶頸。其中HTTP協(xié)議的過分冗余以及上層封裝帶來的損耗，就是一個比較突出的問題。

開發(fā)者不但要應(yīng)對使用同步的HTTP的調(diào)用庫所帶來的吞吐量的下降，還要忍受HTTP協(xié)議本身，以及JSON、XML協(xié)議在信息傳輸上的低效率。為了解決這一問題，一套在TCP協(xié)議層的，使用簡單的二進(jìn)制協(xié)議。才能保證業(yè)務(wù)用更少的傳輸帶寬，承載更多的傳輸內(nèi)容，從而提高吞吐量和WEB服務(wù)伺服能力。

同時，在實(shí)際開發(fā)的層面上，PHP邏輯層與后臺服務(wù)之間通信協(xié)議的維護(hù)成本較高。同時，后臺服務(wù)側(cè)新增或修改接口字段，往往調(diào)用側(cè)也要配合修改，很多時候無法保證接口的完全兼容而引發(fā)線上的運(yùn)營問題。因此，這種二進(jìn)制協(xié)議又要做到接口方便維護(hù)，同時又容易擴(kuò)展。

除此之外，從開發(fā)效率上而言，原本的開發(fā)中總是包含大量的重復(fù)的，但又不得不去做的工作內(nèi)容。因?yàn)槊恳淮涡聟f(xié)議的開發(fā)，代碼很難復(fù)用，JSON和XML也并不允許你共用部分?jǐn)?shù)據(jù)。同時一個很現(xiàn)實(shí)的問題是，不同HTTP接口的提供方，往往會視自己的心情和習(xí)慣來定義接口。

一個常見的例子就是對返回碼的定義，有些人叫ret，有些人叫code，還有些人就叫r，簡直是無所不包。因此這類重復(fù)無趣的開發(fā)工作，給調(diào)用方的開發(fā)同學(xué)帶來了極大的生理和心理負(fù)擔(dān)。基于這種需求，一種服務(wù)端和客戶端都能夠根據(jù)協(xié)議和接口自動生成調(diào)用代碼，保證聯(lián)調(diào)通暢的解決方案必不可少。

再者，調(diào)用方對后端服務(wù)的發(fā)現(xiàn)和調(diào)用的上報(bào)與監(jiān)控，也是一個老生常談的問題。后端服務(wù)如何被發(fā)現(xiàn)，后端的接口如何被發(fā)現(xiàn)，這都是調(diào)用方真真切切想知道的。同時，調(diào)用方非常有必要對后端服務(wù)的調(diào)用情況進(jìn)行上報(bào)到中央服務(wù)器，中央服務(wù)器再根據(jù)收集上來的信息，對后端服務(wù)的負(fù)載進(jìn)行動態(tài)的調(diào)整，保證服務(wù)的高可用。要實(shí)現(xiàn)這樣的需求，必須引入一種集成了監(jiān)控、主控尋址、上報(bào)通道、負(fù)載均衡功能的解決方案。

Tars作為騰訊公司的優(yōu)秀RPC框架與服務(wù)部署運(yùn)維解決方案，可以滿足上述的所有需求。通過引入Tars-PHP的全套解決方案，開發(fā)者既可以使用二進(jìn)制的Tars協(xié)議，大大壓縮了服務(wù)請求的流量。同時也能夠借助Tars協(xié)議解析的PHP擴(kuò)展，提高了打包解包的性能進(jìn)而提升了單進(jìn)程的任務(wù)處理能力。再次，自動生成代碼的工具也能夠提升開發(fā)者的效率。

Tars-PHP的開源方案，首先從二進(jìn)制的協(xié)議說起：

HTTP協(xié)議可能是在應(yīng)用層上使用最為廣泛的協(xié)議了?，F(xiàn)有HTTP的版本主要是1.0和1.1版本。它在TCP協(xié)議的基礎(chǔ)上做了十分簡潔的應(yīng)用層協(xié)議封裝，純文本的內(nèi)容，以及Header和Body的區(qū)分。都使得這種協(xié)議的使用和理解十分的方便。但是不可避免的，使用和閱讀的簡單意味著信息的冗余，為了傳輸少量的內(nèi)容，往往需要耗費(fèi)大量的流量。

另外兩個比較熟知的協(xié)議，就是JSON和XML了，這兩位在API交互常用的協(xié)議中不分上下，可讀性強(qiáng)、容易理解、語言客戶端支持豐富、協(xié)議表述能力突出，都是兩者的優(yōu)勢所在。先看看同樣一段信息，兩者需要的數(shù)據(jù)量。

假定有一所學(xué)校，一個學(xué)生，如果用JSON標(biāo)識的話，如下所示：

{
    "school":
    {
        "student":{
            "name":"ted",
            "age":18,
            "degree":"master"
        }
    }
}

很簡單的結(jié)構(gòu)，共需要65個字符來表述。而如果換成XML：

        
            ted
            18
            master
        

則一共需要92個字符。從信息學(xué)的角度而言，信息熵明顯就是太低了。所以為了實(shí)現(xiàn)通信的更高性能和更少帶寬的使用，二進(jìn)制協(xié)議的引入勢在必行。

Tars協(xié)議作為一個二進(jìn)制的協(xié)議，相比于上述兩個協(xié)議的優(yōu)勢不言自明。從上文中的JSON和XML中發(fā)現(xiàn)其靈活性，也就是沒有指定字段的類型。但是不可避免的，這種靈活帶來了性能的大損失。因此Tars定義了八種基本的數(shù)據(jù)類型，通過對不同的數(shù)據(jù)類型進(jìn)行編碼優(yōu)化：

bool、byte、short、int、long、float、double 、string

而同時為了滿足業(yè)務(wù)需求，擴(kuò)展出了struct（包含任意字段）、vector（數(shù)組）、map（key-value結(jié)構(gòu)）這三種可以嵌套數(shù)據(jù)，豐富協(xié)議表現(xiàn)力的復(fù)雜類型。

按照上文的表現(xiàn)結(jié)構(gòu)，幾個struct就可以完成。
首先是student結(jié)構(gòu)體：

struct student {
    0 required string name; // tag為0，type為string，實(shí)際數(shù)據(jù)為ted，共5個字節(jié)
    1 required byte age; // tag為1，type為short，實(shí)際數(shù)據(jù)為18, 共2個字節(jié)
    2 required string degree; // tag為2，type為string，實(shí)際數(shù)據(jù)為master，共7個字節(jié)
}

從注釋中可以看到，三個字段需要的字節(jié)數(shù)為14，再加上結(jié)構(gòu)體的開始和結(jié)構(gòu)體結(jié)束的標(biāo)識共2個字節(jié)，一共只需要16個字節(jié)而已。相比之下，這僅僅是JSON的1/4，是XML協(xié)議標(biāo)識同樣信息的1/5，高下立判. 巧妙地用協(xié)議強(qiáng)約定換傳輸可讀性，這就是高信息熵的二進(jìn)制協(xié)議的訣竅。

為了使得PHP能夠充分與Tars結(jié)合，必須使其具備作為客戶端和作為服務(wù)端兩個方面的能力。

作為客戶端而言，要能夠滿足快速開發(fā)的需求，也要能夠與PHP現(xiàn)有的常見使用方式相結(jié)合，同時還要給出遠(yuǎn)程調(diào)用的實(shí)例。基于這些需求，客戶端方案中實(shí)現(xiàn)了如下的特性：

實(shí)現(xiàn)了用TUP協(xié)議進(jìn)行打包解包、編碼解碼的PHP擴(kuò)展及相應(yīng)的測試用例；

實(shí)現(xiàn)了從Tars協(xié)議文件生成對應(yīng)PHP類文件的tars2php工具；

實(shí)現(xiàn)了包含網(wǎng)絡(luò)庫的二次封裝，以及遠(yuǎn)程調(diào)用的代碼示例；

作為客戶端實(shí)現(xiàn)的最核心一步，就是對TUP協(xié)議的支持。TUP協(xié)議是在Tars協(xié)議的上層，通過固定的數(shù)據(jù)結(jié)構(gòu)封裝一些收發(fā)包必須的信息，如返回值、輸入輸出參數(shù)、包本身的狀態(tài)、包計(jì)數(shù)等，來給非Tars原生客戶端與Tars服務(wù)端進(jìn)行通信的協(xié)議。Tars-PHP在支持TUP協(xié)議的方案中，選擇了使用PHP擴(kuò)展作為實(shí)現(xiàn)方式。

PHP語言本身被詬病最多的，就是針對CPU密集型的運(yùn)算的低效率。由于并不十分高效的ZEND虛擬機(jī)、松散的數(shù)據(jù)結(jié)構(gòu)和弱類型的存在，使得打包、解包這類CPU密集型的效率低下。因此，PHP擴(kuò)展應(yīng)運(yùn)而生。通過引入高性能的C/C++類庫和一些原生的C/C++實(shí)現(xiàn)，使得PHP在性能處理方面迎頭趕上。這也就是以擴(kuò)展的方式實(shí)現(xiàn)打包解包主邏輯的初衷。

首先來看看PHP5x語言的結(jié)構(gòu)：

最底層的Server API用來PHP與Webserver通信，這個主要是之前與APACHE配合需要使用的。在其左上的PHPCORE層，是為了提供最基本的文件和網(wǎng)絡(luò)操作的能力。而右上的ZEND，則是用來把PHP的腳本語言編譯成機(jī)器碼的工具。最上面就是擴(kuò)展層了，這層會充分利用ZEND的API和PHPCORE的能力，直接寫出ZEND能夠高效執(zhí)行和理解的代碼，省去了PHP腳本編譯為機(jī)器碼的過程，從而大大的提高執(zhí)行的效率。

如果要設(shè)計(jì)這個擴(kuò)展，必須要將上文中Tars的數(shù)據(jù)結(jié)構(gòu)通過C語言的方式加以表達(dá)，同時設(shè)計(jì)出基于這套數(shù)據(jù)結(jié)構(gòu)的編碼器與解碼器。另一個需要考慮的方面是，必須要使得在PHP層面盡可能的簡單、易用，這就對擴(kuò)展的設(shè)計(jì)提出了比較高的挑戰(zhàn)。一方面要兼顧性能，另一方面，要將Tars協(xié)議中的Struct，進(jìn)行了PHP中的Class的表達(dá)：

從圖中可以清晰的看到，結(jié)構(gòu)體SimpleStruct被分解成了三個部分：

TAG部分

成員變量部分

變量描述的fields

TAG部分至關(guān)重要，這部分用來代表Struct中每個元素的TAG值。這也是實(shí)際進(jìn)行TUP編碼和解碼的時候，二進(jìn)制包里面最終包含的內(nèi)容。為什么要有TAG？這是因?yàn)橄啾扔贘SON里面對字段的文本性質(zhì)的描述，TAG本身更節(jié)省空間。

第二部分則是類的成員變量，這部分成員變量和Tars協(xié)議的Struct中的變量一一對應(yīng)。這是為了承載對應(yīng)變量的實(shí)際值而存在的。借此才能對真正的數(shù)據(jù)進(jìn)行打包和解包。

為了在TAG和變量之間搭起一座橋梁，就有了第三部分：Fields部分。這部分是TAG與其對應(yīng)的變量屬性的一個映射。包含了變量的名稱、變量是否必填以及變量的類型。通過這些信息，一方面實(shí)現(xiàn)了對Tars協(xié)議的二進(jìn)制編碼，也實(shí)現(xiàn)了解碼時候的映射。可謂一舉兩得。

那么經(jīng)過復(fù)雜的擴(kuò)展設(shè)計(jì)與實(shí)現(xiàn)，有必要將擴(kuò)展實(shí)現(xiàn)的打包解包性能和原生PHP實(shí)現(xiàn)的打包解包性能進(jìn)行比對。從下面的表格中可以非常明顯的看出擴(kuò)展實(shí)現(xiàn)擁有性能上面的絕對優(yōu)勢：

從這個表格中可以非常清晰的看到，無論是簡單的Tars協(xié)議，還是復(fù)雜的Tars協(xié)議，使用擴(kuò)展進(jìn)行打包解包都比原生PHP的性能提高十倍以上。當(dāng)遇到復(fù)雜的業(yè)務(wù)邏輯，需要調(diào)用大量的使用Tars協(xié)議的后臺服務(wù)的時候，這種效率的提升會讓服務(wù)的吞吐量上一個數(shù)量級。

開發(fā)者在完成擴(kuò)展的編譯工作之后，就可以非常方便的使用TUP協(xié)議進(jìn)行打包，解包與編碼解碼的工作了。

// 針對基本類型的打包和解包的方法,輸出二進(jìn)制buf
$buf = TASAPI::put*($name, $value);
$value = TUPAPI::get*($name, $buf);

// 針對Struct,傳輸對象,返回結(jié)果的時候,以數(shù)組的方式返回,其元素與類的成員變量一一對應(yīng)
$buf = TUPAPI::putStruct($name, $clazz);
$result = TUPAPI::getStruct($name, $clazz, $buf);

// 針對Vector,傳入完成pushBack的Vector
$buf = TUPAPI::putVector($name, TARS_Vector $clazz);
$value = TUPAPI::getVector($name, TARS_Vector $clazz, $buf);

// 針對Map,傳入完成pushBack的Map
$buf = TUPAPI::putMap($name, TARS_Map $clazz);
$value = TUPAPI::getMap($name, TARS_Map $clazz, $buf);

// 需要將上述打好包的數(shù)據(jù)放在一起用來編碼
$inbuf_arr[$name] = $buf;
// 進(jìn)行tup協(xié)議的編碼,返回結(jié)果可以用來傳輸、持久化
$reqBuffer = TUPAPI::encode(
                         $iVersion=3,
                         $iRequestId,
                         $servantName,
                         $funcName,
                         $cPacketType=0,
                         $iMessageType=0,
                         $iTimeout,
                         $context=[],
                         $statuses=[],
                         $inbuf_arr);
// 進(jìn)行tup協(xié)議的解碼
$ret = TUPAPI::decode($respBuffer);
$code = $ret["code"];
$msg = $ret["msg"];
$buf = $ret["sBuffer"];

為了方便開發(fā)者擴(kuò)展使用中經(jīng)常遇到的無法找到具體函數(shù)和參數(shù)的問題，同時提供了tars-ide-helper：

以PHPSTORM為例，只需要導(dǎo)入到相應(yīng)的INCLUDE路徑中，就可以實(shí)現(xiàn)自動提示了：

除了打包解包的能力，Tars-PHP同時也提供了網(wǎng)絡(luò)收發(fā)的能力，網(wǎng)絡(luò)收發(fā)主要實(shí)現(xiàn)了以下幾個點(diǎn)：

TarsAssistant.php文件：通過COMPOSER加載，底層內(nèi)置SOCKET原生網(wǎng)絡(luò)層收發(fā)包實(shí)現(xiàn)；

根據(jù)Interface自動生成PHP的Class，與TarsAssistant無縫結(jié)合

提供Exception等容錯處理；

一旦完成了代碼的自動生成之后，使用者即可通過如下代碼，方便的進(jìn)行遠(yuǎn)程Tars服務(wù)調(diào)用：

    require_once "./vendor/autoload.php";

    $ip = "";// taf服務(wù)ip
    $port = 0;// taf服務(wù)端口
    $servant = new AppServerServantservant($ip,$port);

    $in1 = "test";
    $ss1 = new SimpleStruct();
    $ss1->id = 1;
    $ss1->count = 2;
    $ss1->page = 3;

    try {
        $intVal = $servant->singleParam($in1,$ss1,$out1);
    }
    catch(phptarsTarsException $e) {
        // 錯誤處理
    }

除了建設(shè)Tars-PHP作為客戶端的能力之外，服務(wù)端的能力同樣是必不可少的。為了能夠滿足不同業(yè)務(wù)場景下的需求，Tars-PHP在服務(wù)端主要會關(guān)注兩類服務(wù)。

第一類是HTTP的服務(wù)，會以SWOOLE2.0為網(wǎng)絡(luò)收發(fā)的基礎(chǔ)，實(shí)現(xiàn)一套高性能、簡潔好用的面向WEB服務(wù)的框架。這套框架會支持基本的 路由、中間件、MVC架構(gòu)等常見的WEB框架特性。同時也會集成Redis、Mysql、Http、Multicall、Tars等常見的客戶端，方便WEB服務(wù)再去調(diào)用后臺服務(wù)。更重要的是，接入到Tars平臺中，使得服務(wù)可監(jiān)控，可重啟，享受Tars運(yùn)維平臺帶來的一站式便利?，F(xiàn)在框架的第一個版本已經(jīng)實(shí)現(xiàn)，并在閱文集團(tuán)內(nèi)部上線使用，測試成熟后，會及時進(jìn)行開源。

第二類則是TCP的服務(wù)，同樣底層依賴于SWOOLE2.0，但是協(xié)議從HTTP換成了對TUP和Tars的支持?？蚣軐?shí)現(xiàn)上而言，會與JAVA、C++的服務(wù)端保持一致，底層集成網(wǎng)絡(luò)能力，使用者只需關(guān)心服務(wù)名稱以及接口參數(shù)和自己的業(yè)務(wù)處理邏輯而已。當(dāng)然，這個服務(wù)肯定也是要與Tars運(yùn)維平臺相結(jié)合的?，F(xiàn)在框架對TUP協(xié)議支持的第一個版本已經(jīng)完成，后續(xù)也會在完成Tars協(xié)議的底層支持之后，在業(yè)務(wù)上進(jìn)行使用和驗(yàn)證。

閱文集團(tuán)在進(jìn)行后臺服務(wù)治理與改造的過程中，使用了Tars-PHP的解決方案。一方面，所有WEB后臺與后臺服務(wù)的接口，全部從原有的HTTP接口，切換為了基于Tars協(xié)議的TCP網(wǎng)絡(luò)傳輸。依賴于Tars-PHP的自動代碼生成，開發(fā)效率提升巨大，保證了項(xiàng)目的順利按時上線。同時，這套基于PHP擴(kuò)展的方案，也保證了代碼執(zhí)行效率的高效，單個請求的處理時間，相比于原有的HTTP接口調(diào)用，得到了顯著的縮短。

另一方面，由于使用的WEB后臺服務(wù)是常駐內(nèi)存的，基于SWOOLE的實(shí)現(xiàn)。所以在發(fā)布、啟動、監(jiān)控等方面與原有PHP中固有的Apache和PHP-FPM的方式都不相同。因此，正如上文中所說，服務(wù)接入Tars平臺，享受其監(jiān)控、保活、日志等一系列的功能，會大大提高服務(wù)本身的運(yùn)維和擴(kuò)容的便利性。如今在其線上服務(wù)中，超過十個服務(wù)已經(jīng)切入并穩(wěn)定運(yùn)行了接入到Tars平臺的HTTP服務(wù)。這些服務(wù)的發(fā)布、擴(kuò)容和運(yùn)維完全依賴Tars平臺，十分便利。

除去對Tars平臺運(yùn)維的使用，閱文WEB后臺側(cè)同樣在服務(wù)發(fā)現(xiàn)上，有一套方案。

對于遠(yuǎn)程服務(wù)的地址管理，最差的方案就是將其寫入本地文件中。這種方案無法應(yīng)對快速縮擴(kuò)容以及服務(wù)器下線的需求，會給后續(xù)的運(yùn)維帶來很大的工作量。

稍微好一些的方案是本地存儲虛擬IP，那么每次只需要調(diào)整虛擬IP，就可以實(shí)現(xiàn)服務(wù)地址的自動映射和變化。但是這意味著對要調(diào)用的每一個后臺服務(wù)，都需要存儲其對應(yīng)的虛擬IP、HOST信息、接口信息等一系列的信息，同樣維護(hù)成本很高。

而更加通用的方案，則是提供服務(wù)的統(tǒng)一配置中心，每次需要調(diào)用后臺服務(wù)的時候，就從配置中心根據(jù)唯一的標(biāo)識拉取出服務(wù)最新的地址。這樣一方面能夠做到縮擴(kuò)容對業(yè)務(wù)的無感知，另一方面配置中心也能夠通過服務(wù)的尋址情況，給每個客戶端分配最適合它的服務(wù)機(jī)器地址，比如機(jī)房或者SET就近分配等等。本地的服務(wù)只需要提供兩個能力，第一個是能夠調(diào)用定期的尋址服務(wù)，并存入本機(jī)的存儲中，保證尋址的速度。第二個則是能夠接收配置中心下發(fā)的命令，更新特定服務(wù)的地址。能做到這兩點(diǎn)，就能夠?qū)崿F(xiàn)高效的尋址和可靠的尋址了。

在實(shí)際使用中，結(jié)合實(shí)際業(yè)務(wù)情況，一方面每分鐘向主控請求一次服務(wù)的地址，通過輪詢的方式獲取一個可用的服務(wù)地址，再放入本地的高速共享內(nèi)存，方便在這一分鐘之內(nèi)重復(fù)的讀取。另一方面在每次服務(wù)調(diào)用的時候，都自動在底層集成對服務(wù)調(diào)用情況的耗時、成功率的上報(bào)。在雙管齊下的作用之下，對遠(yuǎn)程服務(wù)的調(diào)用不再像過去那樣難以維護(hù)、難以開發(fā)、難以監(jiān)控，而是清晰可見高效的被管理。

從開發(fā)效率上而言，使用Tars-PHP擺脫了過分冗余的業(yè)務(wù)代碼，以自動生成的方式提高代碼開發(fā)自動化程度。

從性能方面而言，Tars-PHP方案通過引入擴(kuò)展，做到了性能的大幅度提升，讓性能不再成為PHP“之殤”。

從易用性而言，通過提供TarsAssistant的網(wǎng)絡(luò)收發(fā)組件，使得收發(fā)包無需多帶帶實(shí)現(xiàn)。后面也會引入更高性能的Swoole作為socket收發(fā)的利器，進(jìn)一步提高網(wǎng)絡(luò)性能。

后續(xù)，Tars-PHP的SERVER側(cè)方案也會盡快開源，從而能夠提供一套包含客戶端與服務(wù)端的完整解決方案。這一整套的WEB后臺的Tars-PHP開發(fā)體系，能夠真正做到了高性能、高效率與高可用。而閱文集團(tuán)也會繼續(xù)與騰訊在Tars-PHP技術(shù)方案上深度合作與實(shí)踐。歡迎開發(fā)者試用！