Soundcloud在重构过程中面临诸多挑战，包括使用自身公共API构建大型Rails应用程序的问题。在新设计阶段，团队遭遇基础设施难题，如高可用性代理及memcached问题等。最终，他们通过将大型Rails应用程序分解为更小的服务来解决这些问题。
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位讲师。
\
扫一扫
5181
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
