作者: Laruence( ) 本文地址: http://www.laruence.com/2012/09/15/2779.html 轉(zhuǎn)載請注明出處 Yar(yet another RPC framework, 教主問我為啥都是Ya打頭, 呵呵, 因為這樣名字好起)是我在3個多月前, 為了解決一個實際的問題, 而開發(fā)的一個PHP擴(kuò)展的, RPC框架,

Yar(yet another RPC framework, 教主問我為啥都是Ya打頭, 呵呵, 因為這樣名字好起)是我在3個多月前, 為了解決一個實際的問題, 而開發(fā)的一個PHP擴(kuò)展的, RPC框架, 和現(xiàn)有的RPC框架(xml-rpc, soap)不同, 這是一個輕量級的框架, 支持多種打包協(xié)議(msgpack, json, php), ?并且最重要的一個特點是, 它是可并行化的..

考慮如下的場景:

傳統(tǒng)的Web應(yīng)用, 一個進(jìn)程, 一個請求, 天經(jīng)地義. ?然而, 當(dāng)一個請求的處理中, ?涉及到多出數(shù)據(jù)源, 并且他們之間具有一定的不依賴性.

還是傳統(tǒng)的Web應(yīng)用, 一個應(yīng)用隨著業(yè)務(wù)快速增長, 開發(fā)人員的流轉(zhuǎn), 就會慢慢的進(jìn)入一個惡性循環(huán), ?代碼量上只有加法沒有了減法. ?因為隨著系統(tǒng)變復(fù)雜, 牽一發(fā)就會動全局, ?而新來的維護(hù)者, 對原有的體系并沒有那么多時間給他讓他全面掌握. 即使有這么多時間, 要想掌握以前那么多的維護(hù)者的思維的結(jié)合, 也不是一件容易的事情…

那么, 長次以往, 這個系統(tǒng)將會越來越不可維護(hù)…. ?到一個大型應(yīng)用進(jìn)入這個惡性循環(huán), 那么等待他的只有重構(gòu)了.

那么, 能不能對這個系統(tǒng)做解耦呢?

我們已經(jīng)做了很多解耦了, 數(shù)據(jù), 中間件, 業(yè)務(wù), 邏輯, 等等, 各種分層. 但到Web應(yīng)用這塊, 還能怎么分呢, MVC我們已經(jīng)做過了….

基于此, Yar或許能解決你遇到的這倆個問題…

Yar是一個非常輕量級的RPC框架, 我在實現(xiàn)Yar的時候, 追求了極致的輕量級, 它使用非常簡單, 對于Server端:

<?php
class API {
    /**
     * the doc info will be generated automatically into service info page.
     * @params
     * @return
     */
    public function api($parameter, $option = "foo") {
    }

    protected function client_can_not_see() {
    }
}

$service = new Yar_Server(new API());
$service->handle();
?>

和Soap使用方法很相像吧? 是的, 就這樣, 你的API類就可以對外提供服務(wù)了..

Yar為了方便開發(fā), 把文檔和接口綁定到了一起, 對于上面的例子, 如果我們是簡單的GET請求這個接口地址的話, 我們就會看到如下的信息頁面:

這樣, 我們可以在注釋中,把接口的信息標(biāo)注好, 就可以讓文檔和接口在一起了.

而對于Client端來說, 簡單的串行調(diào)用, 會非常之簡單:

<?php
$client = new Yar_Client("http://host/api/");
$result = $client->api("parameter);
?>

這樣一來, 如果你有多個服務(wù), 你只需要一個client.

那么, 最激動人心的并行化調(diào)用呢?

<?php
function callback($retval, $callinfo) {
     var_dump($retval);
}

Yar_Concurrent_Client::call("http://host/api/", "api", array("parameters"), "callback");
Yar_Concurrent_Client::call("http://host/api/", "api", array("parameters"), "callback");
Yar_Concurrent_Client::call("http://host/api/", "api", array("parameters"), "callback");
Yar_Concurrent_Client::call("http://host/api/", "api", array("parameters"), "callback");
Yar_Concurrent_Client::loop(); //send
?>

這樣, 所有的請求會一次發(fā)出, 只要有任何一個請求完成, 回調(diào)函數(shù)”callback”就會被立即調(diào)用.

這里還有一個細(xì)節(jié), Yar見縫插針的不會浪費(fèi)任何時間, 在這些請求發(fā)送完成以后, Yar會調(diào)用一次callback, 和普通的請求返回回調(diào)不同, 這次的調(diào)用的$callinfo參數(shù)為空.

這樣一來, 我們就可以先發(fā)送請求, 然后再第一次回調(diào), 繼續(xù)做我們當(dāng)前進(jìn)程的工作, 等所有工作結(jié)束以后, 再交給Yar去獲取并行RPC的響應(yīng).

<?php
function callback($retval, $callinfo) {
    if ($callinfo == NULL) {
       //做本地的邏輯
       return TRUE;
    }

     //RPC請求返回, 返回值在$retval
}

有了這些, 我們就可以把一個Web應(yīng)用中, 多個數(shù)據(jù)源并行處理, 從而也能把這些邏輯解耦, 分開部署…

當(dāng)然Yar目前還在試用階段, 所以還沒有發(fā)布任何一個包(Yar at PECL), ?但是有興趣的同學(xué)可以現(xiàn)在就把代碼clone下去試用哦(雖然沒有正式投入試用, 不過已經(jīng)經(jīng)過了驗證).

Yar: Yar at Github

PS, 如果要使用Msgpack(一個高效的二進(jìn)制打包協(xié)議)做為打包協(xié)議, 需要單獨安裝Msgpack擴(kuò)展(Msgpack), 這個擴(kuò)展目前也是我在維護(hù), 我會在近幾天把他在PECL上發(fā)布, 盡請期待.