Yar(yet another RPC framework, 教主問我為啥都是Ya打頭, 呵呵, 因為這樣名字好起)是我在3個多月前, 為了解決一個實際的問題, 而開發的一個PHP擴展的, RPC框架, 和現有的RPC框架(xml-rpc, soap)不同, 這是一個輕量級的框架, 支持多種打包協議(msgpack, json, php), 並且最重要的一個特點是, 它是可並行化的..
考慮如下的場景:
傳統的Web應用, 一個進程, 一個請求, 天經地義. 然而, 當一個請求的處理中, 涉及到多出數據源, 並且他們之間具有一定的不依賴性.
還是傳統的Web應用, 一個應用隨著業務快速增長, 開發人員的流轉, 就會慢慢的進入一個惡性循環, 代碼量上只有加法沒有了減法. 因為隨著系統變復雜, 牽一發就會動全局, 而新來的維護者, 對原有的體系並沒有那麼多時間給他讓他全面掌握. 即使有這麼多時間, 要想掌握以前那麼多的維護者的思維的結合, 也不是一件容易的事情…
那麼, 長次以往, 這個系統將會越來越不可維護…. 到一個大型應用進入這個惡性循環, 那麼等待他的只有重構了.
那麼, 能不能對這個系統做解耦呢?
我們已經做了很多解耦了, 數據, 中間件, 業務, 邏輯, 等等, 各種分層. 但到Web應用這塊, 還能怎麼分呢, MVC我們已經做過了….
基於此, Yar或許能解決你遇到的這倆個問題…
Yar是一個非常輕量級的RPC框架, 我在實現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類就可以對外提供服務了..
Yar為了方便開發, 把文檔和接口綁定到了一起, 對於上面的例子, 如果我們是簡單的GET請求這個接口地址的話, 我們就會看到如下的信息頁面:
