技术栈的选择：从Groupon转向Node.js、淘宝去IOE谈起

资讯频道 → 研发管理

35顶
1踩

2014-01-02 09:59 by 副主编 wangguo 评论(8) 有20959人浏览

技术栈 Groupon 淘宝 Node.js Rails

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

在本文开始之前，先来看看一些案例。

今年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

五、写在最后

技术栈是产品的根基，是产品功能和用户体验的保障。每种编程语言和技术都有存在的理由，且这些技术栈都经过了时间和大型项目的验证，但这并不代表别人能用你就也能用，还需要根据产品、团队、市场等因素选择最适合的技术栈。所以，在技术栈的选择上，可以说没有最好，只有最适合。希望本文列举的这些公司的案例能够为你带来一些参考。