从Linkedin和Iron.io抛弃ruby说起
最近半年关于Ruby编程语言最负面的两条新闻莫过于2012年10月的报导：Linkedin从ruby迁移到node.js，30台服务器减到3台，以及2013年3月的报导：Iron.io从ruby迁移到Go，30台服务器减到2台
node.js和Go都是最近两年服务器端高并发编程的热门语言，Linkedin和Iron.io抛弃Ruby迁移之后，都获得10倍以上的系统性能提升，效果非常好。当然这两篇新闻报导引发的争议也非常大，最大的争议在于：原有Ruby编写的应用是随着业务经过长时间代码演化而成的，代码可维护性和架构都已经存在严重的问题，即使沿用Ruby on rails重写，也会获得巨大的性能提升，非编程语言迁移之功。
诚然，继续沿用Ruby on rails重写或者重构应用，性能可能会有一两倍的提升，但无法弥合10倍以上的性能差距，难道说ruby真的如此不堪吗？注定要被node.js或者Go所取代吗？
Ruby的性能真的如此不堪吗？
JGW Maxwell在2011年底做了一个Ruby Web框架的并发处理能力测试，还做了node.js的对比测试。用250个并发去做压力测试，后端使用MongoDB数据库，总共跑完10万个请求，测试结果如下：
Web框架并发模型吞吐量
Rails多进程531 request/s
Sinatra多进程576 request/s
Sinatra::Synchrony线程1692 request/s
Goliath线程1924 request/s
CrampEvent IO3516 request/s
node.jsEvent IO3100 request/s
纤程IO模型的性能是传统多进程模型的3-4倍，而Event IO则是多进程的6-7倍。值得一提的是Ruby的Event IO框架Cramp甚至性能超过了node.js。看来并发性能差的原因并不在Ruby。
如果说这仅仅只是测试，不能说明问题，那么我再举一个真实的应用数据。去年年底我和@黄志敏交流，得知他为公司最近开发的一个API Server使用了Ruby的纤程框架Goliath，线上数据：
这个数据意味着一台配备了4颗4核CPU，2G内存的服务器，每天可以处理1.5亿次web请求。由此可见，Ruby完全可以做到高并发IO的应用。问题主要不在ruby解释器上，而在Rails框架上。更准确的说就是，ruby on rails作为一个full-stack的web开发框架，并不适合用来开发Linkedin和Iron.io的后台web服务，从某种意义上来说，属于rails的时代已经过去了
移动时代，Web服务将取代Web网站
随着最近几年智能手机的迅速普及，如今来自智能手机和移动设备的总体Web访问和服务请求量已经超过了传统的PC，这意味着Web时代主流的Browser/Server的架构重新回到了Mobile Client/Server的架构。在B/S架构下，在服务器端生成完整的HTML页面，我们需要开发一个完整的Website；但在移动时代，服务器端的功能大大简化了，退化成了Web API调用接口提供者，而复杂的界面构造、交互和运算都是在移动客户端完成的。
传统的Website将越来越让位于Web Service，移动客户端无论是iOS，Android还是HTML5都通过API调用获取服务器端的json/xml格式的数据，无需服务器端生成HTML页面了。这种B/S架构重新往C/S架构的迁移，也意味着full-stack Web框架将越来越没有用武之地了。
Web服务器端并发常见的三种应用场景：
并发场景业务逻辑界面构造数据格式IO并发
Website复杂，功能多服务端组装页面HTML页面很低
Web Service简单，功能少客户端组装页面json/xml高
real-time单一，功能极少客户端实时响应json/xml极高
我们看Linkedin和Iron.io的案例，都是非常典型的Web Service的应用场景：Linkedin使用Rails开发了移动服务器的API网关，而Iron.io用Rails开发了搜集客户设备数据的后台服务，这些都不是Rails最擅长的开发website的场景，所以最终Rails被抛弃，并不是一个很意外的结果。
Rails为何不适合做Web Service?
我发现了一个有意思的现象，最早的一批用Ruby开发Web Service服务的网站，都选择了用Rails开发，而在最近几年又不约而同抛弃Rails重写Web服务框架。当初用Rails的原因很简单，因为产品早期起步，不确定性很高，使用Rails快速开发，可以最大限度节约开发成本和时间。但为何当请求量变大以后，Rails不再适合了呢？
这主要是因为Rails本身是一个full-stack的Web框架，所有的设计目标就是为了开发Website，所以Rails框架封装过于厚重，对于需要更高性能更轻薄的Web Service应用场景来说，暴露出来了很多缺陷：
Rails调用堆栈过深，URL请求处理性能很差
Rails的设计目标是提供Web开发的最佳实践，所以无论你需要不需要，Rails默认提供了开发Website所有可能的组件，但其中绝大部分你可能一辈子都用不上。例如Rails项目默认添加了20个middleware，但其中10个都是可以去掉的，我们自己的项目当中手工删除了这些middleware：
config.middleware.delete ‘Rack::Cache’# 整页缓存，用不上config.middleware.delete ‘Rack::Lock’# 多线程加锁，多进程模式下无意义config.middleware.delete ‘Rack::Runtime’ # 记录X-Runtime（方便客户端查看执行时间）config.middleware.delete ‘ActionDispatch::RequestId’ # 记录X-Request-Id（方便查看请求在群集中的哪台执行）config.middleware.delete ‘ActionDispatch::RemoteIp’# IP SpoofAttackconfig.middleware.delete ‘ActionDispatch::Callbacks’ # 在请求前后设置callbackconfig.middleware.delete ‘ActionDispatch::Head’# 如果是HEAD请求，按照GET请求执行，但是不返回bodyconfig.middleware.delete ‘Rack::ConditionalGet’# HTTP客户端缓存才会使用config.middleware.delete ‘Rack::ETag’# HTTP客户端缓存才会使用config.middleware.delete ‘ActionDispatch::BestStandardsSupport’ # 设置X-UA-Compatible, 在nginx上设置
其中最夸张的是ActionDispatch::RequestIdmiddleware，只有在大型应用部署在群集环境下进行线上调试才可能用到的功能，有什么必要做成默认的功能呢？Rails的哲学是：提供最全的功能集给你，如果你用不到，你自己手工一个一个关闭掉，但是这样带来的结果就是默认带了太多不必要的冗余功能，造成性能损耗极大。
我们看一个Ruby web框架请求处理性能评测，这个评测不访问数据库，也不测试并发性能，主要是测试框架处理URL请求路由，渲染文本，返回结果的处理速度。
Web框架处理速度
Rack1570.43 request/s
Camping1166.16 request/s
Sinatra912.81 request/s
Padrino648.68 request/s
Rails291.27 request/s
Sinatra至少是Rails速度的3倍以上。
12下一页
查看其它分页：
背着背包的路上，看过许多人，
