GOTO Berlin: 使用自己的公共 API 的问题

  • Jan Stenberg
  • 孙镜涛

2013 年 10 月 23 日

话题:SOARuby on Rails语言 & 开发架构

Soundcloud的工程总监Phil Calcado 在最近的GOTO Berlin 大会上分享自己管理和构建大型 Rails 应用程序的经验时提到:使用自己的公共API可能是一种挑战。

Soundcloud 发展非常迅速,在他的演讲中 Phil 着重介绍了他们在创建一个新的网站时(已于 1 年前发布)所遇到的一些问题。

Soundcloud 开始是一个 Ruby on Rails应用程序,6 年间它不断的扩展变得非常混乱。很多问题归咎于基础设施,一个使用MySQLMemcached的大型 Rails程序

2010 年他们开始考虑一个新的平台。其中的一个想法来源于 Twitter,在他们发布自己重新设计的架构的时候,该架构让 Soundcloud 团队确信他们要构建一个相似的应用程序;一个单独的页面 JavaScript 应用程序,使用一个公共的 API 与后端通信。最终他们开始构建一个新的网站,很多 JavaScript 技能娴熟但是缺少一些后端经验的前端开发者基于现在的公共 API 用了 6、7 个月的时间构建了一个新的 Web 网站。

他们最后构建了一个非常稳定的应用程序,但是在即将发布之前他们与 Twitter 进行了一次谈话,并且提到他们要发布一个新的网站,新网站受到了新的 Twitter 架构的启发,使用了和 Twitter 完全相同的想法。对于这个问题来自于 Twitter 的人员回答说,他们已经发现新的设计并不是一个好想法。实际上,之后 Twitter 已经决定将大部分实现退回到服务器端渲染。

Twitter 人员的回答将团队放到了一个非常有趣的位置,这是一个重要的集成,因此他们应该怎么做,继续还是取消?最后他们决定继续。因为了解 Rails,所以他们确信第一件要出问题的事情会是 Rails,所以他们预分配了很多节点。但是在新设计中一个页面的请求从 3 增长到了超过 100,第一件出问题的事情是他们的高可用性代理。在解决了这个问题之后,memcached 又出问题了,之后是 Rails 和 MySQL。他们现在认识到他们的基础架构有问题。

他们很早就意识到的一个问题是不能重写整个应用。要保留 Rails,因此他们需要一个快速 API,一个能够尽快处理大量请求的 API。他们将大型 Rails 应用程序分割成了更小的部分,并且引入了服务的思想。但是有一个惊喜是,他们依然拥有同样的整体性能,只是从数据库转移到 HTTP 上有性能瓶颈。结论便是他们需要更加快速的 Rails。

仔细看看代码他们发现了很多并发的空间。Rails 不喜欢并行或者并发,因此他们尽量使用Finagle 这样的工具保持同步并设法获得并行和并发性。他们大大降低了负载,并且让结果的返回更加快速。

他们现在能够更快地服务请求。但是每一个页面依然会产生很多请求,为了查找减少请求数量的方法,他们决定尽力实现一个自定义 API,通过一个请求返回几个页面的数据。为了实现这个目的,他们最终使用了三个专用的 API,分别用于移动、桌面和合作伙伴。

他们现在面对的最有趣的设计挑战是如何建模它们的 API。目前开发者喜欢将一个更加粗粒度的 API 用于移动,将一个更加有体验的 API 用于桌面,目前有两个分离的后端。

2013 年的 GOTO Berlin 大会是 GOTO 大会首次在 Berlin 举行,本次大会有超过 400 位参会者和大约 80 位讲师。

查看英文原文:GOTO Berlin: Problems Using Your Own Public API

SOARuby on Rails语言 & 开发架构