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

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

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

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

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

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

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

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

Groupon目前在全球共有兩套站點――美國網(wǎng)站和歐洲網(wǎng)站，其美國網(wǎng)站前端最初是一個單一的Rails（最流行的Ruby開發(fā)框架）代碼庫。對于為什么會選擇Rails來開發(fā)最初的網(wǎng)站，Groupon開發(fā)人員表示，Rails非常適合小型團隊快速開發(fā)，可以讓網(wǎng)站快速啟動并運行起來，這對于初期功能不斷變化的Groupon來說，是個非常不錯的選擇。

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

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

為什么選擇Node.js？

Groupon團隊評估了不同的軟件棧，想尋找一個能夠解決這些問題的方案――有效處理大量傳入的HTTP請求、使并行API請求服務于每一個HTTP請求、將結果渲染為HTML5，并可以有效實現(xiàn)監(jiān)控、部署和支持。

該團隊使用不同的軟件棧開發(fā)了原型，并測試了它們，總體來說，發(fā)現(xiàn)Node.js是個非常適合的解決方案。

如何遷移？

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

遷移帶來的好處

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

更詳細的信息可參閱 Groupon開發(fā)團隊的博客。

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

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

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

Twitter剛開始開發(fā)的時候不可能考慮到會有現(xiàn)在這樣大的訪問量，可以說現(xiàn)在的Twitter發(fā)展到當初在設計上的極限了。
一個網(wǎng)站在遇到設計極限的時候，有很多解決方法，比如重寫架構、換其他語言等等，他們的工程師想要挑戰(zhàn)一些新的東西，就提出要改用Scala，因為Scala是編譯型語言，性能也不錯，正好適合編寫新的架構，我覺得這樣也不錯。
在我看來，在網(wǎng)站所提供的服務還沒有完全成型的時候，最重要的是能夠對需求的變化做出快速的反應，這個時候就需要Ruby這樣靈活性比較高的語言；而在網(wǎng)站獲得成功之后，遇到了設計瓶頸，用一種新的語言，比如Scala，來編寫一個新的架構，以節(jié)約一定的資源，我認為這也是很好的一個結果。Twitter轉向Scala還只是在其核心部分，而在Web前端和一些內部工具上還有很多地方在用Ruby。

此外Twitter還將一些后端服務使用Java和 Clojure（基于JVM的Lisp方言）進行了重寫，其基礎設施也采用了一些開源項目。

遷移后，Twitter在美國總統(tǒng)競選期間沒有出現(xiàn)宕機。目前Twitter每秒處理約6000條消息，加起來每天處理超過5億或每周35億條消息。

3.  技術上更可控，規(guī)模上更易擴展――淘寶去IOE

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

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

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

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

詳細信息可參閱《 阿里周寶方談“去IOE”戰(zhàn)略及實施》。

4.  快速開發(fā)需要――PayPal使用Node.js重寫其支付系統(tǒng)

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

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

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

HTML5 是應用開發(fā)領域的未來趨勢，由于其跨平臺性，一些企業(yè)也開始將應用使用HTML5重寫。

比如Facebook和LinkedIn采用HTML5重寫其iOS客戶端。但是他們也付出了一定的代價――由于用戶的網(wǎng)絡環(huán)境并沒有預想的那么好，結果導致應用啟動、瀏覽信息流、打開圖片都比較慢，因此他們后來又放棄該技術，轉而使用蘋果的iOS SDK重新構建，由于是本地應用，速度提升非常明顯。

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

6.  成本考慮――選擇開源軟件

由于昂貴的成本，開源軟件往往是小型初創(chuàng)公司的首選。比如服務器方面：

• 單從系統(tǒng)的性能和吞吐量來講，Windows Server也不差，但是Windows在管理和部署方面沒有Linux方便；
• Windows服務器的授權費用使架構規(guī)模的橫向擴展成本偏高；
• 一些高端的服務器軟件只有UNIX/Linux版本
• 一些優(yōu)化、緩存、數(shù)據(jù)庫解決方案只針對Linux。

7.  更換技術團隊或CTO

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

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

8.  被迫選擇

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

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

二、大公司是如何做的

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

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

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

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

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

2.  優(yōu)化原有技術棧――Facebook

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

Facebook的前臺主要使用PHP編寫，盡管PHP編程效率高，能夠支持產品的快速迭代，但是與傳統(tǒng)的編譯語言相比，腳本語言在CPU和內存使用率上不夠好，隨著Ajax技術的廣泛采用，加上SNS對動態(tài)要求較高，這些缺點更顯得突出。

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

于是HipHop for PHP誕生了，該項目由一個PHP到C++的轉換程序、一個重新實現(xiàn)的PHP運行庫和許多常用PHP擴展的重寫版本構成，可大大加速和優(yōu)化PHP應用。據(jù)悉，由于HipHop，F(xiàn)acebook Web服務器上的CPU使用率平均減少了50%。

3.  也有失敗案例

當然，在技術棧遷移過程中，也有失敗的案例，比如5173網(wǎng)站從.NET轉向Java以失敗告終。詳細信息可見范凱 《對.NET系統(tǒng)架構改造的一點經(jīng)驗和教訓》。

三、如何選擇技術棧

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

• 產品預期上市時間
• 開發(fā)團隊和生產力情況
• 可維護性
• 可擴展性
• 使用環(huán)境
• 社區(qū)和許可情況（開源項目）

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

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

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

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

考慮效率

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

考慮實用

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

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

四、看頂尖互聯(lián)網(wǎng)企業(yè)的技術選型

下面來看看大型互聯(lián)網(wǎng)公司的產品是如何選擇技術棧的。該數(shù)據(jù)來自 維基百科，這是根據(jù)網(wǎng)站的HTTP頭信息和文件類型所統(tǒng)計的。

網(wǎng)站	前端	后端（服務端）	數(shù)據(jù)庫
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

五、寫在最后

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