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

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

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

Soundcloud 开始是一个 Ruby on Rails 应用程序，6 年间它不断的扩展变得非常混乱。很多问题归咎于基础设施，一个使用 MySQL 和 Memcached 的大型 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