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

标签: 技术 选择 groupon | 发表时间:2014-01-03 08:30 | 作者:frank1998819
出处:http://www.iteye.com

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

  • 今年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了。

庄表伟认为想要兼得鱼和熊掌的确困难,但是并非没有可能,我们可以找到一些优秀的、可选的技术集合,对于技术选型的判断,需要考虑理论情况与实际情况:

考虑效率

  • 技术复杂度(复用性):学习并掌握一组技术栈,需要了解多复杂的技术;相应的,当我们掌握了这门技术,它可以在多少地方复用?
  • 技术友好度(优雅性):在开发的过程中,会不会有各种莫名其妙的陷阱,会不会让我纠缠于各种莫名其妙的细节?

考虑实用

  • 业务复杂度(组织性):随着业务的复杂,我们的代码会不会最终无法驾驭?无法维护?无人能懂?
  • 性能提升度(潜力):随着业务的增长,压力的提升,我们会不会最终被迫放弃现有的技术架构,重头开始?


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [技术 选择 groupon] 推荐:

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

- - 互联网 - ITeye博客
在本文开始之前,先来看看一些案例. 今年10月份,知名团购网站Groupon宣布完成了为期1年的工作——将Groupon美国站点从Ruby on Rails全面迁移到了Node.js. 2010~2013期间,阿里巴巴逐步完成了“去IOE”运动,将“IBM小型机+Oracle数据库+ EMC2存储”架构逐步转向了“MySQL+PC Server”.

解密Groupon

- Felix - 月光博客
  编者注:本文节选自Nicholas Carlson的文章《INSIDE GROUPON: The Truth About The World’s Most Controversial Company》,有删节.   Groupon是一个全球性的团购网站,于2008年创立,每日提供不同的优惠券供客户选购.

移动应用开发技术选择六要素

- - 技术改变世界 创新驱动中国 - 《程序员》官网
作者从平台环境、操作系统、设备能力、云端、应用类型、跨平台开发六大方面分享了其在移动应用开发中的技术选择经验. 这是一个新的时代、新的机会. 自从2007 年1月乔布斯揭开iPhone的面纱以来,移动时代的大潮滚滚向前,已经走过近5个年头. 这个产业正在从新生走向成熟阶段. 在这样的产业时代背景下,各种不同的系统平台,不同的技术路线,自然是层出不穷、迅猛发展.

中大型移动互联网公司技术架构选择

- - 五四陈科学院
以下内容由 [五四陈科学院]提供. 总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:. 可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问). 天然可扩展(业务层无状态,尽可能全部放到最后). 自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可).

中小企业的大数据技术路线选择

- - CSDN博客研发管理推荐文章
中小企业的大数据技术路线选择.        目前,大数据主要应用在互联网、电商领域,电信、电力行业也在逐步使用. 对广大的中小企业来说,大数据也听得太多了. 然而,大数据的技术门槛还是很高的. 从技术路线上来说,选择大公司使用的技术方案可能是不能承受之重.        笔者所在的公司,选择的是行业通用的Hadoop方案.

程序员如何选择编程技术书?

- - 外刊IT评论
即使是棵枯树也同样可以成为优秀资源,教你学习如何写代码或者磨练你如何成为一名好的开发者. 真正的问题是,你如何选择你真正需要的合适你的书. 幸运的是,有几个要点可以帮助你将市场上琳琅满目的书进行整理. 有一些经典的巨著,我建议凡是任何对计算机编程和软件开发感兴趣的人都可以去看一看的. (译注:比如 Stack Overflow 上有个《哪本最具影响力的书,是每个程序员都应该读的.

技术干货分享:如何选择 HTML5 游戏引擎

- - 开源中国社区最新新闻
原生手游市场已是红海,腾讯、网易等寡头独霸天下,H5游戏市场或将成为下一个风口. 据笔者所知,很多H5游戏开发团队由于选择引擎不慎导致项目甚至团队夭折. 如何选择适合团队和项目的引擎,笔者通过学习和项目实践,总结微薄经验,供大家参考,非技术人员也可以将本篇内容作为引擎选择的重要关注点. 选择H5游戏引擎的思考维度.

Groupon:小企业的大平台

- Shell Wang - SocialBeta
最近,New Yorker专栏作家James Surowiecki如此表达了自己对Groupon的看法:“Groupon不会成为一个与YouTube、Facebook、Twitter和Google一样具有革命性的公司,相反其理念属于守旧派,既没有明显的技术优势,用户只不过点以下购买按钮,而且其业务需要依靠大量的注意力…”.

Google Offers 能比 Groupon 强在哪儿?

- cow - 谷奥——探寻谷歌的奥秘
尽管Google Offers已经在波特兰率先上线,但这只属于小试牛刀,与Groupon真正的对决还要看马上即将发布的旧金山和纽约两座城市,那么Google Offers击败Groupon的杀手锏有哪些呢. 付款条件更优厚:Google Offers可在4天内返还商户80%的销售收入,剩下的20%将在余下的90天里支付完毕.

Groupon 进入中国的部分细节

- zxsky1 - 爱范儿 · Beats of Bits
昨天我们独家披露了 Groupon 的中国计划,其他媒体动作也不慢,Techcrunch 从很特别的途径得到了这个计划的一部分细节(大学的工作招聘网站). 几天前 Groupon 刚刚结束了 9.5 亿美元的新一轮募资,而这笔钱的很大一部分将会砸在中国市场上,这意味着大量的资金跟很有竞争力的薪水;.