闪购网站Gilt从Rails迁移到Scala

闪购网站Gilt.com是一个新生的电子商务模式,其特点是在几秒钟内流量爆棚100倍,每天大概持续15分钟,这家网站的首席架构师Eric Bowman谈了如何从Ruby On Rails迁移到Scala的感受,大意如下:

flash-sales这种闪存销售模式决定了必须建立一个能够支持这种突然爆发的系统。我们的解决方案是基于分布式架构开发数百个Scala微服务。

我们不会认为开始使用Rails是范了一个错误,毕竟Rails是非常棒的,使我们能够灵活地快速发展,但是后来我们又不得不使用Play框架再做一遍,因为Play框架更易于扩展伸缩。

从 2009到2011 Gilt增长得非常快速,因此我们不得不扩展我们的系统,开始使用Java,但是它逐步增长成铁板一块的整体式(monolithic)系统,我们的代码越来越难于维护和扩展,从性能和可扩展性两个方面看我们还是必须工作在JVM上,2011年采取了Scala,我们不断从其灵活简单中受益,也得益于Typesafe的Reactive平台如Play Framework, Akka 和 sbt.

微服务在很多方面对Gilt产生了好处,起初的Rails应用也是一种铁板一块整体式monolithic系统,这种系统架构引入了复杂的依赖,意味着很长的测试循环和不可预期的性能影响,而使用微服务,我们能在不相干的服务之间实现隔离,保持我们的尽可能简单快速.它也开创了团队内部端对端的品质开发质量,这不仅能够更加明确责任(一个微服务一个人开发),而且让开发者更加轻松开心,他们看得到他们的工作成果,会很有成就感(整体式系统则是自己开发的一个功能需要和别人协调确认,不能立即会有成就感)。

最后,Eric Bowman谈到了从RoR等开源项目上受益匪浅。
[该贴被banq于2014-05-18 10:09修改过]

从Gilt这种迁移我认为原因有两个:
1. Node.js和Play框架倡导的微服务。
微服务这种架构使得维护拓展方便,打破了原来Java和Rails的铁板一块的整体式系统,这种微服务架构特点是RESTful接口+微服务。而传统Java和Rails是一种MVC+服务,为什么MVC+服务容易导致铁板一块的系统呢?MVC是一种面向前端的模式,当你使用这种组合时,你的重点就不免放在MVC的实现上,“服务”变成一种附加的次要的为MVC服务的架构,而轻量的RESTful接口使得我们重点又回到“服务”上,我们可以专注将我们的服务设计成一种微服务。

2. Node.js和Play框架倡导的异步Reactive编程。
异步编程最大的特点是吞吐量大,延迟小,因为没有堵塞,这就容易挖掘现有硬件和操作系统等底层系统的潜力,同样的成本投入,异步系统要比传统铁板一块的同步系统更能应付爆发式涌潮的瞬间大流量。

异步编程完全颠覆了传统Rails和Java Spring的顺序编程模型,具体可参考:http://www.jdon.com/46372,这个贴虽然使用了Node.JS作为异步编程案例说明,同样也适合Scala的Play框架和Akka的异步Reactive编程。


[该贴被banq于2014-05-19 09:19修改过]