SoundCloud 架构的演变：第一部分

这就引出了一个问题，当前的架构如何能够并发处理请求？

当 SoundCloud 的架构最初开发时（2008 年），Rails 中的并发请求处理仍被认为不成熟。

工程团队决定保留现有模型，而不是投入更多时间审核依赖关系：

1. 每个应用服务器进程单次并发。

2. 每个主机有多个进程。

尽管每个主机有多个进程，但 SoundCloud 的流量已经很高。几个长时间运行的请求很容易重新产生 HoL 阻塞问题。

例如，如果有 5 个进程而不是 1 个进程，系统理论上将能够处理平均 5 倍的慢速请求。

再次想象一下你在邮局的情景。你正在排队等待有空的工作人员帮你处理包裹。人越多，延误的可能性就越大（有人带着多个包裹）。

这个 HoL 问题该如何解决呢？

工程团队意识到了这一点。他们想要的是一个永不排队的系统。或者至少是一个等待时间最短的排队系统。

为了实现这一点，他们必须确保每个 Rails 应用服务器每次不会收到超过一个请求。

他们做出了以下改变：

1. 确保服务器是无状态的。

2. 添加 HAProxy 基础设施

3. 配置的后端最大连接数为 1。

再次，简单的设计选择。

这些新的变化可能已经解决了 HoL 问题，但长时间运行的请求本身仍然是一个问题。

其中一个例子就是用户通知。

当用户将新曲目上传到 SoundCloud 时，用户的关注者会收到通知。对于关注者较少的用户来说，这可能没什么问题，但对于更受欢迎的用户来说，延迟会非常大。

事实上， 扇出 通知的持续时间经常会超过几十秒。这些长时间运行的请求需要改为作业（队列）。

还记得在这个架构下一切仍然是同步的吗？

由于声音和图像的存储空间也在快速增长，团队决定将资产转移到 Amazon S3。存储扩展性很好，同时 转码 计算留在 Amazon EC2 中。

“一个经纪人负责将所有订单排队。”

根据工作时间，工作主要分为两类：

1. 交互 – 工作时间小于 250ms

2. 批次 – 其余一切

此时，SoundCloud 的用户数已达数十万。

为了使架构继续发展，工程团队知道他们需要分离读写路径。

然后可以单独优化读写路径。

其中一个重点领域是小部件。

事实证明，SoundCloud 的最大请求量是单个端点为小部件提供数据。

1. 整頁

2. DOM 片段

3. 部分呈现的模板

4. 只读 API 响应

这些性能改进解决了应用程序层的 CPU 问题（渲染引擎和运行时）。

另一个重点领域是仪表板，这是用户个性化的活动视图。

当仪表板收到更新时，所有设备和第三方应用程序上的相应用户都会收到通知。

需要优化读取路径，以便每个用户在一定时间范围内进行顺序访问。

写入路径需要针对随机访问进行优化，其中一个事件可能会影响数百万用户的索引。

为了实现这些优化， 卡桑德拉 被选为存储系统， Elasticsearch 被选中来增强搜索功能。这些解决方案提供了持久性和可扩展性。

最终的整体架构如下所示：