Ruby 社區應該去 Rails 化了
從Linkedin和Iron.io拋棄ruby說起
最近半年關于Ruby編程語言最負面的兩條新聞莫過于2012年10月的報導：Linkedin從ruby遷移到node.js，30臺服務器減到3臺，以及2013年3月的報導：Iron.io從ruby遷移到Go，30臺服務器減到2臺
node.js和Go都是最近兩年服務器端高并發編程的熱門語言，Linkedin和Iron.io拋棄Ruby遷移之后，都獲得10倍以上的系統 性能提升，效果非常好。當然這兩篇新聞報導引發的爭議也非常大，最大的爭議在于：原有Ruby編寫的應用是隨著業務經過長時間代碼演化而成的，代碼可維護 性和架構都已經存在嚴重的問題，即使沿用Ruby on rails重寫，也會獲得巨大的性能提升，非編程語言遷移之功。
誠然，繼續沿用Ruby on rails重寫或者重構應用，性能可能會有一兩倍的提升，但無法彌合10倍以上的性能差距，難道說ruby真的如此不堪嗎？注定要被node.js或者Go所取代嗎？
Ruby的性能真的如此不堪嗎？
JGW Maxwell在2011年底做了一個Ruby Web框架的并發處理能力測試，還做了node.js的對比測試。用250個并發去做壓力測試，后端使用MongoDB數據庫，總共跑完10萬個請求，測試結果如下：
纖程IO模型的性能是傳統多進程模型的3-4倍，而Event IO則是多進程的6-7倍。值得一提的是Ruby的Event IO框架Cramp甚至性能超過了node.js。看來并發性能差的原因并不在Ruby。
如果說這僅僅只是測試，不能說明問題，那么我再舉一個真實的應用數據。去年年底我和@黃志敏交流，得知他為公司最近開發的一個API Server使用了Ruby的纖程框架Goliath，線上數據：
·VPS上總共使用了16個CPU內核，跑了16個單進程實例
·每個進程實例穩定消耗50MB內存
·Web框架使用Goliath, URL分發是grape，數據庫訪問使用ActiveRecord，緩存使用Redis
·應用吞吐量達到了1800 request/s
這個數據意味著一臺配備了4顆4核CPU，2G內存的服務器，每天可以處理 1.5億次 web請求。由此可見，Ruby完全可以做到高并發IO的應用。問題主要不在ruby解釋器上，而在Rails框架上。更準確的說就是， ruby on rails作為一個full-stack的web開發框架，并不適合用來開發Linkedin和Iron.io的后臺web服務，從某種意義上來說，屬于rails的時代已經過去了
移動時代，Web服務將取代Web網站
隨著最近幾年智能手機的迅速普及，如今來自智能手機和移動設備的總體Web訪問和服務請求量已經超過了傳統的PC，這意味著Web時代主流的 Browser/Server的架構重新回到了Mobile Client/Server的架構。在B/S架構下，在服務器端生成完整的HTML頁面，我們需要開發一個完整的Website；但在移動時代，服務器端 的功能大大簡化了，退化成了Web API調用接口提供者，而復雜的界面構造、交互和運算都是在移動客戶端完成的。
傳統的Website將越來越讓位于Web Service，移動客戶端無論是iOS，Android還是HTML5都通過API調用獲取服務器端的json/xml格式的數據，無需服務器端生成 HTML頁面了。這種B/S架構重新往C/S架構的遷移，也意味著full-stack Web框架將越來越沒有用武之地了。
Web服務器端并發常見的三種應用場景：
·Website：傳統Web網站
·Web Service：Web服務端提供API調用接口
·real-time：Web實時推送
我們看Linkedin和Iron.io的案例，都是非常典型的Web Service的應用場景：Linkedin使用Rails開發了移動服務器的API網關，而Iron.io用Rails開發了搜集客戶設備數據的后臺服 務，這些都不是Rails最擅長的開發website的場景，所以最終Rails被拋棄，并不是一個很意外的結果。
Rails為何不適合做Web Service?
我發現了一個有意思的現象，最早的一批用Ruby開發Web Service服務的網站，都選擇了用Rails開發，而在最近幾年又不約而同拋棄Rails重寫Web服務框架。當初用Rails的原因很簡單，因為產 品早期起步，不確定性很高，使用Rails快速開發，可以最大限度節約開發成本和時間。但為何當請求量變大以后，Rails不再適合了呢？
這主要是因為Rails本身是一個full-stack的Web框架，所有的設計目標就是為了開發Website，所以Rails框架封裝過于厚重，對于需要更高性能更輕薄的Web Service應用場景來說，暴露出來了很多缺陷：
Rails調用堆棧過深，URL請求處理性能很差
Rails的設計目標是提供Web開發的 最佳實踐 ，所以無論你需要不需要，Rails默認提供了開發Website所有可能的組件，但其中絕大部分你可能一輩子都用不上。例如Rails項目默認添加了20個middleware，但其中10個都是可以去掉的，我們自己的項目當中手工刪除了這些middleware：
- config.middleware.delete 'Rack::Lock' # 多線程加鎖，多進程模式下無意義
- config.middleware.delete 'Rack::Runtime' # 記錄X-Runtime（方便客戶端查看執行時間）
- config.middleware.delete 'ActionDispatch::RequestId' # 記錄X-Request-Id（方便查看請求在群集中的哪臺執行）
- config.middleware.delete 'ActionDispatch::RemoteIp' # IP SpoofAttack
- config.middleware.delete 'ActionDispatch::Callbacks' # 在請求前后設置callback
- config.middleware.delete 'ActionDispatch::Head' # 如果是HEAD請求，按照GET請求執行，但是不返回body
- config.middleware.delete 'Rack::ConditionalGet' # HTTP客戶端緩存才會使用
- config.middleware.delete 'Rack::ETag' # HTTP客戶端緩存才會使用
- config.middleware.delete 'ActionDispatch::BestStandardsSupport' # 設置X-UA-Compatible, 在nginx上設置
其中最夸張的是ActionDispatch::RequestIdmiddleware，只有在大型應用部署在群集環境下進行線上調試才可能用到的功能，有什么必要做成默認的功能呢？ Rails的哲學是：提供最全的功能集給你，如果你用不到，你自己手工一個一個關閉掉 ，但是這樣帶來的結果就是默認帶了太多不必要的冗余功能，造成性能損耗極大。
我們看一個Ruby web框架請求處理性能評測 ，這個評測不訪問數據庫，也不測試并發性能，主要是測試框架處理URL請求路由，渲染文本，返回結果的處理速度。
Sinatra至少是Rails速度的3倍以上。
#p#
Rails加載的框架和依賴庫過多，內存消耗過度
Rails自身依賴庫非常多，造成的結果就是Rails應用持續運行以后內存消耗非常高。舉個例子：如果你用到了Rails的asset pipeline功能，那么項目需要依賴一個JS引擎來編譯JS和CSS，默認會使用libv8這個庫。盡管只是編譯階段使用libv8，運行期并不需要 它，但是仍然會加載libv8，這意味著你的每個ruby進程會多占20MB內存。在我們其中一個大項目上，總共開了40個ruby進程，直接浪費了 800MB內存。于是我們不得不在生產服務器上安裝了node.js，替換了libv8。
此外，一旦其中某個依賴庫有內存泄露，整個應用也可能出現內存泄露，這種內存泄露是很討厭的事情，Rails如此肆無忌憚不加限制的使用第三方依賴庫也是一個潛在的隱患。
最后，Rails的Restful路由也是內存消耗大戶，它默認會生成全套的URL路由helpers，無論你實際是否使用到，造成的結果就是內存會消耗很多，而且URL路由請求的處理速度會很慢，以致于有第三方專門開發了插件去關閉無用的路由。
我做了一個稍完整的案例比較，分別使用Sinatra, Padrino和Rails框架開發一個簡單的數據庫CRUD應用，數據庫訪問都是用ActiveRecord，在我的iMac電腦上，3個ruby應用單進程消耗的內存分別是：
Rails傳統多進程模型的IO并發能力很低
Rails的多進程并發模型的IO并發能力很低，開多少個進程，就只能同時響應多少個并發請求，但Ruby進程的內存消耗是很大的，多進程調度的 CPU開銷也很高，這決定了單臺服務器上能開的進程數是非常有限的，一般不會超過30個。但是對于Web Service類型的應用，需要很高的IO并發處理能力，傳統Rails多進程很容易就會出現負載的瓶頸。
提高Web應用的IO并發能力，必須拋棄多進程模型，改用多線程模型，纖程模型或者事件驅動的并發編程模型。關于這個話題，我寫過一個ppt，請參考：Web并發編程模型的粗淺探討 ，這篇文章不展開了。總之，我個人更推薦使用Sinatra/Padrino編寫多線程的Web服務端應用，或者為了追求更高的并發性能，可以使用Goliath的纖程并發。
從Rails4.0開始，默認也開啟了多線程模式，也可以支持多線程方式運行Rails應用。但就目前來說，Rails使用多線程，還面臨一些兼容 性問題：大量的Rails插件和代碼不是線程安全的，在多線程模型下運行，會出現意想不到的bug；另外Rails的多線程應用尚未得到廣泛應用，可能會 有潛在的bug：
我們嘗試在一個實際的生產系統上打開Rails3.2的多線程模式運行，對代碼和插件都進行了兼容性修改和仔細的代碼審查。但實際跑下來發現，應用 系統出現了隱蔽的內存泄露問題，Ruby進程內存會一直增長下去，直到服務器內存占滿，進程失去響應，這個bug至今未能找到原因。
總之Rails適合開發Website，但不太適合Web Service，而移動時代的發展趨勢就是：未來服務器端會更多的使用Web Service而不是Website，這也意味著Rails將越來越不適合時代的發展
我們應該用什么Ruby框架？
我一直覺得Ruby社區的很多開發者長期以來待在Rails的舒適區里面，完全喪失了探索和嘗試其他東西的勇氣，其實在Rails的世界之 外，Ruby社區的好東西還有很多很多。這里簡單介紹3個Ruby輕量級框架，性能都遠遠超過Rails，很適合做Web Service：
Sinatra本身也是Ruby社區非常流行和著名的輕量級Web框架，核心源代碼不超過1000行，文檔只有1頁。對于Rails開發者來說，花了幾個小時，就可以快速使用Sinatra開發Web Service了。Sinatra對多線程支持的非常好，可以用rainbows來跑多線程Sinatra，IO并發處理能力很好。Github也是用它來提供開放API服務的。我自己寫了一個Sinatra的項目模版，如果你用Sinatra開發Web Service，可以參考。
Padrino是一個基于Sinatra之上的輕量級Web框架，在Sinatra基礎之上提供了命名路由，模塊化項目組織，頁面helpers和 generators等等。Padrino是一個高度模仿Rails的框架，API的命名和Rails很像，Rails開發者花1-2天看看文檔就可以快 速上手開發了。Padrino相比Rails易學易用，多線程支持良好，性能比Rails好很多，開發Website推薦使用。我自己的網站也是用 Padrino開發的，源代碼在：robbin_site
Goliath是一個Ruby的纖程開發框架，性能非常好，作者本身是在開發PostRank產品過程中開發的Goliath。PostRank是 一個用戶社交行為實時跟蹤工具，需要很高的性能來支撐，PostRank被Google收購了，作者現在在Google工作。Goliath適合用來開發 對性能非常敏感的Web Service或者real-time的應用，但使用Goliath有一些門檻，你不能使用普通的阻塞IO庫，必須使用作者封裝的一些纖程的庫。
總之，無論是Linkedin的移動API網關還是Iron.io的后臺任務系統，用Ruby來編寫，本身并不是問題，實踐也有大量案例證明使用Goliath或者Sinatra編寫高性能Web Service都是可行的。問題只是在于我們應該： Ruby off rails 了。
如何去Rails化
掌握一門編程語言實際上包括兩部分：
·編程語言語法以及核心類庫
無論你用不用Rails，是否開發Web應用，這些都是必須牢固掌握的，即使你不用Rails了，這些知識和技能也不會過時。
·開發特定領域應用所需要的第三方類庫
當你用Rails開發一個項目的時候，仍然需要依賴大量的第三方類庫，每當你在Gemfile里面require一個類庫的時候，都意味著你付出了 一定的學習成本。而Rails本身也不過就是幾個核心Gem包而已，具體來說最核心的就是ActiveRecord和ActionPack這兩個庫。
學習Rails無非意味著你花了時間熟悉ActiveRecord和ActionPack以及相關庫的功能而已，所謂去Rails化也僅僅只是放棄 使用ActionPack，換一個更輕量級更簡單的URL路由處理器，例如換成Grape，Sinatra，Padrino或者Camping而已。這對 一個長期使用Rails的Ruby開發者來說，應該是舉手之勞的事情。所以自己動手，根據實際應用場景挑選最合適的組件。例如ActionPack不太適 合寫Web Service，那我換成Sinatra就行了，但是ActiveRecord照常用，這并不需要你付出多少學習成本，更不需要你放棄什么。
為何不用node.js和Go？
有一點是毫無疑問的，node.js的V8引擎，Go的靜態編譯進去的GC，性能遠遠好于Ruby的虛擬機，盡管在實際的應用中，未必會表現出來這么明顯的差距。那么，一個隨之而來的問題就是：為何不用node.js和Go呢？
每個程序員都有自己的傾向性，答案可能都不同。我在去年底花了很多時間了解node.js和Go，最終還是覺得用Ruby對我來說最合適：
·用Sinatra或者Goliath這樣的輕量級框架寫Web Service，性能已經足夠好了，特別是@黃志敏的案例證明，16核已經可以支撐每天1.5億次請求了，對我來說已經不太可能遇到超過這個負載量的應用了。而Ruby的開發效率，代碼表達能力和可維護性對我來說還是很重要的。
·node.js的Event IO編程風格在我看來是“反人類”的，極其變態的。用來寫代碼上規模的應用，代碼的可讀性和可維護性都很差。Event IO是很底層的技術，我很難理解為何不封裝成coroutine來使用。node.js只適合用來開發real-time類型的應用。
·Go的主要問題在于現階段還不成熟：一方面Go自身還在演進當中；另一方面Go的類庫還是過于貧瘠了，用來開發項目還是需要自己寫很多東西的，感覺很不方便。加上Go是編譯型語言，開發過程當中反復編譯也是挺麻煩的事情。
