日期:2014-05-16  浏览次数:20421 次

技术栈的选择:从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 当时的开发技术也已经无法满足快速开发的需求,因