Whitepages的架构变迁：从Ruby到响应性更好的Scala和Akka

最新推荐文章于 2024-05-29 00:00:00 发布

最新推荐文章于 2024-05-29 00:00:00 发布

阅读量226

点赞数

来看我的自定义版权011702

本文链接：https://blog.csdn.net/cpongo2ppp1/article/details/89018534

版权

Whitepages是位于美国的一家公司，主要负责提供个人和企业的联系信息，供用户搜索。其业务每个月要服务5000万独立用户，每天要完成3500万次搜索。其移动产品每个月也有超过1800万的活跃用户。

\u0026#xD;\u0026#xD;

随着业务的增长，Whitepages的架构出现了瓶颈。经过评估，开发人员将出现瓶颈及代价较高的部分从原来的Ruby语言实现迁移到了更为现代、响应性更好的Scala语言和Akka框架。Whitepages的开发人员John Nestor和Dragos Manolescu分享了他们的经验。

\u0026#xD;\u0026#xD;

在介绍了公司要应对的业务规模之后，他们提到了Ruby遗留系统存在的问题：

\u0026#xD;\u0026#xD;

较高的延迟\u0026#xD;\t
较高的资源消耗，包括内存和处理器两个方面\u0026#xD;\t
对于上游服务的降级支持较差\u0026#xD;\t
- 并发能力有限\u0026#xD;\t\t
- 当阻塞在较慢的上游服务上时，工作线程会饥饿\u0026#xD;\t\t
- 连接管理和恢复能力不佳\u0026#xD;\t
\u0026#xD;

之所以选择Scala，是因为这门语言具有如下优点：

\u0026#xD;\u0026#xD;

优雅地结合了函数式编程范型和面向对象编程范型\u0026#xD;\t
静态类型系统\u0026#xD;\t
- 类型推导可以避免编写大量的Java样板代码\u0026#xD;\t\t
- 编译器可以捕获很多错误\u0026#xD;\t
\u0026#xD;\t
运行在JVM上\u0026#xD;\t
- 速度快\u0026#xD;\t\t
- 几乎可以无缝地与JVM库互操作\u0026#xD;\t\t
- 相当成熟的工具支持\u0026#xD;\t
\u0026#xD;\t
基于Actor的并发框架——Akka\u0026#xD;

Whitepages的响应式服务的特点：

\u0026#xD;\u0026#xD;

在使用Scala和Akka迁移了服务之后，改进非常明显。

\u0026#xD;\u0026#xD;

\u0026#xD;\t\t\t Service \u0026#xD;\t\t\t	\u0026#xD;\t\t\t p50 ms \u0026#xD;\t\t\t	\u0026#xD;\t\t\t p99 ms \u0026#xD;\t\t\t	\u0026#xD;\t\t\t throught RPS/core \u0026#xD;\t\t\t
\u0026#xD;\t\t\t DirSvc - Scala \u0026#xD;\t\t\t	\u0026#xD;\t\t\t 25 \u0026#xD;\t\t\t	\u0026#xD;\t\t\t 300 \u0026#xD;\t\t\t	\u0026#xD;\t\t\t 80 \u0026#xD;\t\t\t
\u0026#xD;\t\t\t DirSvc - Ruby \u0026#xD;\t\t\t	\u0026#xD;\t\t\t 140 \u0026#xD;\t\t\t	\u0026#xD;\t\t\t 1200 \u0026#xD;\t\t\t	\u0026#xD;\t\t\t 7 \u0026#xD;\t\t\t

他们先从1个单一的后台服务入手，现在已经完成了4个服务的迁移；还有6个服务尚在开发之中。Scala开发人员也从最初的6个增加到20个。未来他们还将迁移更多服务。

\u0026#xD;\u0026#xD;

他们总结的成功经验主要有以下几点：

\u0026#xD;\u0026#xD;

当然，迁移过程中也遇到了不少问题，比如：

\u0026#xD;\u0026#xD;

差劲的文档，SBT就是个典型，很多时候还不得不阅读Scala和Akka库的源代码。\u0026#xD;\t
API不稳定，升级步子太大。\u0026#xD;\t
缺乏好用的并发构件分析工具：尝试过Typesafe Console，但是一直没有完整地跑起来，最后放弃；虽然有些新工具，但没有时间一一评测。\u0026#xD;\t
生态系统不如Java，缺乏一些所需的组件；有时候选择太多，比如Json库就有10多款；GitHub上存在大量的Scala项目，但质量参差不齐。\u0026#xD;\t
难以调试，尤其是异步代码和Actor。\u0026#xD;\t
语言和库的问题：类型擦除是一个主要缺陷；Actor缺乏类型检查；某些Scala代码看上去简单直观，但是要了解其背后的机制也非常困难。\u0026#xD;

不过整体而言还是利大于弊，Scala/Akka非常适合构建响应式系统。

\u0026#xD;\u0026#xD;

最后，他们讲到了开发人员这个关键因素。有经验的Scala开发人员还不够多。所以他们一方面招聘Scala开发人员，一方面培训现有的Ruby开发人员，促其转型。

\u0026#xD;\u0026#xD;

更多细节，可以观看讲座视频或下载讲稿。

\u0026#xD;\u0026#xD;

Whitepages并不是第一家尝试从Ruby向其他开发语言迁移的公司。Twitter早在2011年就开始从Ruby向Scala和Java迁移。Iron.io从Ruby迁移到Go，服务器从30台减少到2台。LinkedIn从Rails迁移到Node，服务器减少了27台，速度提升高达20倍。

\u0026#xD;\u0026#xD;

项目创建初期，开发效率往往是首先要考虑的，以保证产品尽快推向市场。而随着业务规模的扩大，性能、可伸缩性方面的需求又会凸现出来，上述几家公司都选择了切换编程语言。亲爱的读者，您对此有何见解呢？欢迎和我们分享。

\u0026#xD;\u0026#xD;

感谢郭蕾对本文的审校。

\u0026#xD;\u0026#xD;