技術棧的選擇：從Groupon轉向Node.js、淘寶去IOE談起

　　在本文開始之前，先來看看一些案例。

• 今年10月份，知名團購網站Groupon宣佈完成了為期1年的工作——將Groupon美國站點從Ruby on Rails全面遷移到了Node.js。
• 2010~2013期間，阿里巴巴逐步完成了“去IOE”運動，將“IBM小型機+Oracle資料庫+ EMC2儲存”架構逐步轉向了“MySQL+PC Server”。
• Twitter將其一些後端服務從Ruby on Rails遷移到了JVM上。
• 京東商場後臺拋棄.NET，使用Java重寫。
• Facebook iOS客戶端使用HTML5重寫，後又換回原生應用。
• ……

　　一、這些公司為什麼要如此“折騰”

　　關於技術棧的選擇和遷移，並不是幾個簡單的原因就能說清楚的，也並不是說新的技術棧就比老的技術棧要優秀很多，其實每種技術都有存在的理由，並在特定領域內有其強大的優勢的，當然也有缺點，比如 C的效能很高，但是開發效率較低；Java的功能強大，但是沒有Ruby簡單靈活。

　　那麼這些公司為什麼要如此折騰呢？下面以一些公司的實際案例，僅列出一些主要、常見的原因。

　　1.  速度、可維護性——Groupon從Rails轉向Node.js

　　為什麼要放棄原有技術棧？

　　Groupon目前在全球共有兩套站點——美國網站和歐洲網站，其美國網站前端最初是一個單一的Rails（最流行的Ruby開發框架）程式碼庫。對於為什麼會選擇Rails來開發最初的網站，Groupon開發人員表示，Rails非常適合小型團隊快速開發，可以讓網站快速啟動並執行起來，這對於初期功能不斷變化的Groupon來說，是個非常不錯的選擇。

　　隨著Groupon的發展和新產品不斷推出，這個程式碼庫越來越大，有太多的開發者在同一個程式碼庫工作，他們很難在本地執行並測試產品，如果有問題需要回滾，那麼每個人的工作都前功盡棄了。

　　Groupon團隊決定將原有的單一Rails庫分割成小的、獨立的、更易於管理的庫。

　　為什麼選擇Node.js？

　　Groupon團隊評估了不同的軟體棧，想尋找一個能夠解決這些問題的方案——有效處理大量傳入的HTTP請求、使並行API請求服務於每一個HTTP請求、將結果渲染為HTML5，並可以有效實現監控、部署和支援。

　　該團隊使用不同的軟體棧開發了原型，並測試了它們，總體來說，發現Node.js是個非常適合的解決方案。

　　如何遷移？

　　Groupon團隊使用Node.js重建了網站頁面的每個主要部分，將它們作為一個獨立的Node.js應用程式，然後重建了基礎設施，使所有獨立的應用程式可以一起工作。遷移之後，Groupon成為了全球最大的Node.js部署產品之一。

　　遷移帶來的好處

• 之前單個Rails前端程式碼庫被分割成了20個獨立的應用程式，其帶來了如下的好處：
• 頁面載入更快——快了50%
• 與之前相比，處理相同的流量所使用的硬體資源更少
• 團隊可以獨立地更改、部署各自負責的模組
• 網站功能和設計實現可以快速迭代

　　更詳細的資訊可參閱 Groupon開發團隊的部落格。

　　2.  原有技術棧已無法滿足如今的規模——Twitter部分服務從Rails遷移到了JVM

　　Twitter在2006建立初期也是基於Ruby on Rails開發的，其架構設計也是完全可以應付當時的訪問量。但是隨著Twitter的快速發展，在每秒上萬訪問量的處理上，原有架構開始出現各種效能問題，比如Twitter開源負責人Chris Aniszczyk稱，在2010年世界盃期間，球員進了一個球或者得到紅黃牌，網站就當機了。

　　為了解決這個問題，Twitter急需開發一個全新的架構，以應付現在越來越大的訪問量。對於Twitter為什麼從Rails轉向JVM語言，來看看Ruby創始人松本行弘是如何說的。

Twitter剛開始開發的時候不可能考慮到會有現在這樣大的訪問量，可以說現在的Twitter發展到當初在設計上的極限了。

一個網站在遇到設計極限的時候，有很多解決方法，比如重寫架構、換其他語言等等，他們的工程師想要挑戰一些新的東西，就提出要改用Scala，因為Scala是編譯型語言，效能也不錯，正好適合編寫新的架構，我覺得這樣也不錯。

在我看來，在網站所提供的服務還沒有完全成型的時候，最重要的是能夠對需求的變化做出快速的反應，這個時候就需要Ruby這樣靈活性比較高的語言；而在網站獲得成功之後，遇到了設計瓶頸，用一種新的語言，比如Scala，來編寫一個新的架構，以節約一定的資源，我認為這也是很好的一個結果。Twitter轉向Scala還只是在其核心部分，而在Web前端和一些內部工具上還有很多地方在用Ruby。

　　此外Twitter還將一些後端服務使用Java和 Clojure（基於JVM的Lisp方言）進行了重寫，其基礎設施也採用了一些開源專案。

　　遷移後，Twitter在美國總統競選期間沒有出現當機。目前Twitter每秒處理約6000條訊息，加起來每天處理超過5億或每週35億條訊息。

　　3.  技術上更可控，規模上更易擴充套件——淘寶去IOE

　　2010~2013期間，阿里巴巴逐步完成了“去IOE”運動，將“IBM小型機+Oracle資料庫+EMC2儲存”架構逐步轉向了“MySQL+PC Server”。

　　至於阿里巴巴為什麼要“去IOE”，阿里技術保障部DBA負責人周寶方表示主要從以下幾個因素考慮：

• 集中式的嚴重製約：集中式強大單點遠遠滿足不了阿里特別是當時淘寶爆炸式業務增長應用的模式，這裡可分為三個方面，穩定性、跨IDC容災切換、快速擴容；
• 技術面臨失控，創新潛力受限；
• 專用裝置規模化場景下諸多限制；
• 成本（這應該是整體最次的因素）；
• 安全

　　“去IOE”之後，阿里的技術架構非常靈活，支撐了業務的快速發展，比如在雙十一，阿里可以很淡定地做業務擴充套件；其次是阿里掌握了技術自主可控操作；另外還包括基礎工程技術和人才的積累、技術的沉澱、成本、安全性的提升等等。

　　詳細資訊可參閱《 阿里周寶方談“去IOE”戰略及實施》。

　　4.  快速開發需要——PayPal使用Node.js重寫其支付系統

　　PayPal 公司長期存在著“ 非我所創 ”的文化，這導致 PayPal 採用新技術的態度很消極，專案開發進度也極其緩慢。正是由於 PayPal 行動緩慢，其他支付服務商 Stripe 和 Square 趁機成長，逐漸撼動 PayPal 的市場地位。同時，PayPal 當時的開發技術也已經無法滿足快速開發的需求，因為當時的開發基本全是 Java，不需要用 Java 來實現的也會用 Java 完成。

　　2012年4月，David Marcuss成為 PayPal 的總裁後，任命工程師團隊重寫支付系統，最終，工程師團隊用了8周時間完成了該項任務，他們選擇了Node.js和一些開源專案對系統進行重新開發，最終他們將這一技術棧整合成了一個 快速開發框架——Kraken，以實現公司其他產品的快速開發。

　　5.  追隨潮流，但這是有代價的——轉向HTML5

　　HTML5 是應用開發領域的未來趨勢，由於其跨平臺性，一些企業也開始將應用使用HTML5重寫。

　　比如Facebook和LinkedIn採用HTML5重寫其iOS客戶端。但是他們也付出了一定的代價——由於使用者的網路環境並沒有預想的那麼好，結果導致應用啟動、瀏覽資訊流、開啟圖片都比較慢，因此他們後來又放棄該技術，轉而使用蘋果的iOS SDK重新構建，由於是本地應用，速度提升非常明顯。

　　當然，這並不是說HTML5不好，而是時機還未成熟。

　　6.  成本考慮——選擇開源軟體

　　由於昂貴的成本，開源軟體往往是小型初創公司的首選。比如伺服器方面：

• 單從系統的效能和吞吐量來講，Windows Server也不差，但是Windows在管理和部署方面沒有Linux方便；
• Windows伺服器的授權費用使架構規模的橫向擴充套件成本偏高；
• 一些高階的伺服器軟體只有UNIX/Linux版本
• 一些優化、快取、資料庫解決方案只針對Linux。

　　7.  更換技術團隊或CTO

　　有這樣一種情況存在，比如原有程式碼庫相關開發者大部分都離職了，且相關工作沒有交接好，文件又不全，導致現有的開發人員難以維護，或者現有開發人員認為原有程式碼“壞味道”太多，不願意維護，所以團隊一拍即合，重寫架構。

　　也有可能公司更換CTO後，公司的原有架構不是新CTO所熟悉的，而且他認為原有架構有一定的問題。

　　8.  被迫選擇

　　如果公司正使用的某些產品的原開發者不再提供支援，那麼只能尋找其他替代品。

　　還有就是在特定平臺上，你只能選擇某個技術棧，比如iOS開發，你只能選擇Objective-C（當然也可以選擇其他跨平臺開發工具，但是效能上比不上原生應用）。

　　二、大公司是如何做的

　　在技術棧的選擇和遷移上，大公司會非常慎重，不僅要考慮新的技術棧是否能解決現有的問題，還需要從公司戰略（比如發展方向）、技術發展局勢（比如移動化、雲端化）方面考慮。

　　1.  不斷嘗試新技術棧——Groupon

　　遷移現有架構或技術棧，需要大量的人力和其他資源，此外，為一個線上產品更換底層設施需要非常高的技術，比如有人將淘寶去IOE比喻成在公路上為一個高速行駛的汽車更換輪胎。

　　一些公司的開發團隊會嘗試不同的技術棧，製作出原型並進行測試，以此來看是否滿足需求。

　　除了做好預備工作外，開發團隊還會選擇先遷移部分應用或服務，小步前進，並在此過程中，快速驗證新技術棧的適用性，並及時反饋，以便能夠發現問題後快速回滾。

　　2.  優化原有技術棧——Facebook

　　當然，也有一些公司不願放棄原有的技術棧，比如 Facebook，轉而在原有技術棧的基礎上進行優化。

　　Facebook的前臺主要使用PHP編寫，儘管PHP程式設計效率高，能夠支援產品的快速迭代，但是與傳統的編譯語言相比，指令碼語言在CPU和記憶體使用率上不夠好，隨著Ajax技術的廣泛採用，加上SNS對動態要求較高，這些缺點更顯得突出。

　　自2007年以來，Facebook嘗試使用多種不同方法解決這一問題，比如使用另一種語言重寫Facebook、重寫PHP的核心部分Zend引擎，但最終還是沒有獲得所需的效能。

　　於是HipHop for PHP誕生了，該專案由一個PHP到C++的轉換程式、一個重新實現的PHP執行庫和許多常用PHP擴充套件的重寫版本構成，可大大加速和優化PHP應用。據悉，由於HipHop，Facebook Web伺服器上的CPU使用率平均減少了50%。

　　3.  也有失敗案例

　　當然，在技術棧遷移過程中，也有失敗的案例，比如5173網站從.NET轉向Java以失敗告終。詳細資訊可見範凱 《對.NET系統架構改造的一點經驗和教訓》。

　　三、如何選擇技術棧

　　選擇技術棧需要參考的因素有很多，一些基本因素如下：

• 產品預期上市時間
• 開發團隊和生產力情況
• 可維護性
• 可擴充套件性
• 使用環境
• 社群和許可情況（開源專案）

　　對於實際上該如何選擇，華為開源支援平臺專家莊表偉給出了他的建議。莊表偉認為：

　　在快速原型的階段，就可以選擇快速開發的語言，而在實用的階段，就應該選擇更加實用的語言。而在一些極端的領域，效率至上與實用至上可以毫不相干，各自有所追求，前期追求效率的開發產品，由於成本極低，大多是可以隨時拋棄的。而真正的困難在於想要兼得。常見的與架構相關的兩種痛苦：

• 一種是，剛開始為了追求快速開發，在技術選型上怎麼快怎麼來，結果系統越來越大，越來越複雜，等到想要考慮架 構優化，想要重構的時候，卻已經積重難返，改起架構來傷筋動骨；
• 另一種是一開始想得太多，架構做得太複雜，殺雞用牛刀的技術用得太多，往往還沒有等到系統開發完成，就已經Game Over了。

　　莊表偉認為想要兼得魚和熊掌的確困難，但是並非沒有可能，我們可以找到一些優秀的、可選的技術集合，對於技術選型的判斷，需要考慮理論情況與實際情況：

　　考慮效率

• 技術複雜度（複用性）：學習並掌握一組技術棧，需要了解多複雜的技術；相應的，當我們掌握了這門技術，它可以在多少地方複用？
• 技術友好度（優雅性）：在開發的過程中，會不會有各種莫名其妙的陷阱，會不會讓我糾纏於各種莫名其妙的細節？

　　考慮實用

• 業務複雜度（組織性）：隨著業務的複雜，我們的程式碼會不會最終無法駕馭？無法維護？無人能懂？
• 效能提升度（潛力）：隨著業務的增長，壓力的提升，我們會不會最終被迫放棄現有的技術架構，重頭開始？

　　詳細資訊可參閱《 技術選型：效率至上與實用至上》。

　　四、看頂尖網際網路企業的技術選型

　　下面來看看大型網際網路公司的產品是如何選擇技術棧的。該資料來自 維基百科，這是根據網站的HTTP頭資訊和檔案型別所統計的。

 

Google.com	JavaScript	C、C++、Go、Java、Python、PHP	BigTable
Facebook.com	JavaScript	PHP、C++、Java、Python、FBML,Ajax,Erlang、D、Xhp	MySQL
YouTube.com	Flash、JavaScript	C、Python、Java	MySQL
Yahoo	JavaScript	PHP	MySQL
Live.com	JavaScript	ASP.NET	Microsoft SQL Server
MSN.com	JavaScript	ASP.NET	Microsoft SQL Server
Wikipedia.org	JavaScript	PHP	MySQL,MariaDB
Blogger	JavaScript	Python	BigTable
Bing	JavaScript	ASP.NET	Microsoft SQL Server
Twitter.com	JavaScript	C++、Java、Scala
Wordpress.com	JavaScript	PHP	MySQL
Amazon.com	JavaScript	Java、J2EE、C++、Perl
eBay.com	JavaScript	Java	Oracle Database
Linkedin.com	JavaScript	Java、Scala
網站	前端	後端（服務端）	資料庫

　　五、寫在最後

　　技術棧是產品的根基，是產品功能和使用者體驗的保障。每種程式語言和技術都有存在的理由，且這些技術棧都經過了時間和大型專案的驗證，但這並不代表別人能用你就也能用，還需要根據產品、團隊、市場等因素選擇最適合的技術棧。所以，在技術棧的選擇上，可以說沒有最好，只有最適合。希望本文列舉的這些公司的案例能夠為你帶來一些參考。