Whitepages 是位于美国的一家公司,主要负责提供个人和企业的联系信息,供用户搜索。其业务每个月要服务 5000 万独立用户,每天要完成 3500 万次搜索。其移动产品每个月也有超过 1800 万的活跃用户。
随着业务的增长,Whitepages 的架构出现了瓶颈。经过评估,开发人员将出现瓶颈及代价较高的部分从原来的 Ruby 语言实现迁移到了更为现代、响应性更好的 Scala 语言和 Akka 框架。Whitepages 的开发人员 John Nestor 和 Dragos Manolescu分享了他们的经验。
在介绍了公司要应对的业务规模之后,他们提到了 Ruby 遗留系统存在的问题:
- 较高的延迟
- 较高的资源消耗,包括内存和处理器两个方面
- 对于上游服务的降级支持较差
- 并发能力有限
- 当阻塞在较慢的上游服务上时,工作线程会饥饿
- 连接管理和恢复能力不佳
之所以选择 Scala,是因为这门语言具有如下优点:
- 优雅地结合了函数式编程范型和面向对象编程范型
- 静态类型系统
- 类型推导可以避免编写大量的 Java 样板代码
- 编译器可以捕获很多错误
- 运行在 JVM 上
- 速度快
- 几乎可以无缝地与 JVM 库互操作
- 相当成熟的工具支持
- 基于 Actor 的并发框架——Akka
Whitepages 的响应式服务的特点:
- 面向服务的架构:通信采用 Thrift 或 HTTP 上的 Json
- 延迟和吞吐量非常重要
- 对日志和监控有很高的要求
- 敏捷的开发、测试、构建和部署流程
在使用 Scala 和 Akka 迁移了服务之后,改进非常明显。
Service
p50 ms
p99 ms
throught RPS/core
DirSvc - Scala
25
300
80
DirSvc - Ruby
140
1200
7
他们先从 1 个单一的后台服务入手,现在已经完成了 4 个服务的迁移;还有 6 个服务尚在开发之中。Scala 开发人员也从最初的 6 个增加到 20 个。未来他们还将迁移更多服务。
他们总结的成功经验主要有以下几点:
- Scala 简洁的语法提高了开发效率。
- 异步代码提高了性能。
- 不可变集合和函数式编程减少了 bug。
- 强类型检查也有助于减少 bug,并使代码的可维护性更好(不过元编程变困难了)。
- 并发能力提高。
- Spray 具有极好的性能,而且提供了一个异步 API。
- SBT 能够根据需求轻松定制,尽管学习曲线有些陡峭。
- IntelliJ IDEA 对 Scala 的支持非常好。
- Typesafe 的开发者支持合约非常不错,Typesafe 反馈非常快,对复杂的问题也可以给出很好的答案。
当然,迁移过程中也遇到了不少问题,比如:
- 差劲的文档,SBT 就是个典型,很多时候还不得不阅读 Scala 和 Akka 库的源代码。
- API 不稳定,升级步子太大。
- 缺乏好用的并发构件分析工具:尝试过 Typesafe Console,但是一直没有完整地跑起来,最后放弃;虽然有些新工具,但没有时间一一评测。
- 生态系统不如 Java,缺乏一些所需的组件;有时候选择太多,比如 Json 库就有 10 多款;GitHub 上存在大量的 Scala 项目,但质量参差不齐。
- 难以调试,尤其是异步代码和 Actor。
- 语言和库的问题:类型擦除是一个主要缺陷;Actor 缺乏类型检查;某些 Scala 代码看上去简单直观,但是要了解其背后的机制也非常困难。
不过整体而言还是利大于弊,Scala/Akka 非常适合构建响应式系统。
最后,他们讲到了开发人员这个关键因素。有经验的 Scala 开发人员还不够多。所以他们一方面招聘 Scala 开发人员,一方面培训现有的 Ruby 开发人员,促其转型。
Whitepages 并不是第一家尝试从 Ruby 向其他开发语言迁移的公司。Twitter 早在 2011 年就开始从Ruby 向Scala 和Java 迁移。 Iron.io 从 Ruby 迁移到 Go ,服务器从 30 台减少到 2 台。 LinkedIn 从 Rails 迁移到 Node ,服务器减少了 27 台,速度提升高达 20 倍。
项目创建初期,开发效率往往是首先要考虑的,以保证产品尽快推向市场。而随着业务规模的扩大,性能、可伸缩性方面的需求又会凸现出来,上述几家公司都选择了切换编程语言。亲爱的读者,您对此有何见解呢?欢迎和我们分享。
感谢郭蕾对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。
评论