Ruby社區應該去Rails化了

 轉自：http://robbinfan.com/blog/40/ruby-off-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萬個請求，測試結果如下：

Web框架	併發模型	吞吐量
Rails	多進程	531 request/s
Sinatra	多進程	576 request/s
Sinatra::Synchrony	纖程	1692 request/s
Goliath	纖程	1924 request/s
Cramp	Event IO	3516 request/s
node.js	Event IO	3100 request/s

纖程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實時推送

併發場景	業務邏輯	界面構造	數據格式	IO併發
Website	複雜，功能多	服務端組裝頁面	HTML頁面	很低
Web Service	簡單，功能少	客戶端組裝頁面	json/xml	高
real-time	單一，功能極少	客戶端實時響應	json/xml	極高

我們看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::Cache'   # 整頁緩存，用不上 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請求路由，渲染文本，返回結果的處理速度。

Web框架	處理速度
Rack	1570.43 request/s
Camping	1166.16 request/s
Sinatra	912.81 request/s
Padrino	648.68 request/s
Rails	291.27 request/s

Sinatra至少是Rails速度的3倍以上。

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應用單進程消耗的內存分別是：

Web框架	物理內存
Sinatra	45MB
Padrino	60MB
Rails	85MB

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

  Sinatra本身也是Ruby社區非常流行和著名的輕量級Web框架，核心源代碼不超過1000行，文檔只有1頁。對於Rails開發者來說，花了幾個小時，就可以快速使用Sinatra開發Web Service了。Sinatra對多線程支持的非常好，可以用rainbows來跑多線程Sinatra，IO併發處理能力很好。Github也是用它來提供開放API服務的。我自己寫了一個Sinatra的項目模版，如果你用Sinatra開發Web Service，可以參考。

• Padrino

  Padrino是一個基於Sinatra之上的輕量級Web框架，在Sinatra基礎之上提供了命名路由，模塊化項目組織，頁面helpers和generators等等。Padrino是一個高度模仿Rails的框架，API的命名和Rails很像，Rails開發者花1-2天看看文檔就可以快速上手開發了。Padrino相比Rails易學易用，多線程支持良好，性能比Rails好很多，開發Website推薦使用。我自己的網站也是用Padrino開發的，源代碼在：robbin_site

• Goliath

  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的類庫還是過於貧瘠了，用來開發項目還是需要自己寫很多東西的，感覺很不方便。