77.md

# 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术

> 原文： [http://highscalability.com/blog/2011/9/26/17-techniques-used-to-scale-turntablefm-and-labmeeting-to-mi.html](http://highscalability.com/blog/2011/9/26/17-techniques-used-to-scale-turntablefm-and-labmeeting-to-mi.html)

![](img/3f78e30a68add9fe1ac9979800d3adf4.png)

在[如何在一个月内启动并扩展到一百万用户](http://www.jperla.com/blog/post/how-to-launch-in-a-month-scale-to-a-million-users)，[前技术副总裁兼 Turntable.fm 的创始团队 Joseph Perla](http://twitter.com/jperla) 分享了他用来构建和快速扩展的技术 他的创业公司。 该帖子写得很好，必须阅读。 这里是要领：

1.  **保持简单。** 在制作网站或移动应用之前，请构建 API。 保持界面小巧，用途单一。
2.  **正确处理。** 从一开始就内置自动化测试。 创建功能测试，模块级别测试和完全集成测试。 对每个提交运行测试。 存在错误时，无需编写新代码。
3.  **不要隐藏力量。** 使用 [Pebbles](http://www.jperla.com/blog/post/write-bug-free-javascript-with-pebbles) 编写无错误的 Javascript，该库通过在代码中添加一些额外的 HTML 标记来编写 0 个 javascript，从而创建复杂的 AJAX 交互。
4.  **使用过程参数可提供接口的灵活性。** 通过函数而不是参数来支持复杂的场景。 例如，过滤器函数返回布尔值。
5.  **留给客户端。** 保持服务器简单，并将尽可能多的功能移至客户端。
6.  **连续性。** 保持接口稳定。 版本从一开始就是接口。
7.  **保守实现的秘密。** 保持服务实现完全独立，以提供最大的灵活性来处理需求更改，即使这意味着性能会略有下降。
8.  **再次使用一个好主意，而不是一概而论。** 复制和专用化类似代码而不是创建一个更通用的库是可以的。
9.  **通常分别处理正常情况和最坏情况。** 代码应该清楚地显示特殊情况，而不是使用更通用的算法来删除特殊情况。
10.  **如果有疑问，请以固定方式拆分资源。** 服务器应为单一用途。 例如，将数据库索引和搜索索引保留在单独的计算机上。 然后可以独立缩放它们，而不会彼此脚。
11.  **如果可以，请使用静态分析。** 在签入时运行对代码的堆栈分析工具，以查找错误和性能问题。
12.  **从方便的表示形式动态转换为可以快速解释的形式。** 例如，用于 tweet 过滤的 Python 特定于域的语言易于编程，可以直接转换为 python 字节码。
13.  **缓存可解决昂贵的计算问题。** 不言自明，，但请注意缓存失效问题。
14.  **如有疑问，请使用蛮力。** 最好使用简单的算法更快地完成功能，而不是延迟实现聪明的算法。
15.  **尽可能在后台计算。** 在 Web 服务器中做尽可能少的工作，将其排队到后台进程。
16.  **尽可能使用批处理。** 加载单个数据项的速度很慢，请大批量加载它们。
17.  **减少负载以控制需求。** 可以有限制。 选择使您的软件正常工作的限制，而无需经过巨大的努力或更改堆栈。

## 相关文章

*   [有关计算机系统设计的提示](http://research.microsoft.com/en-us/um/people/blampson/33-Hints/WebPage.html)，作者：Butler W. Lampson

如果说基于 JavaScript 构建一个 api，则不确定“将其交给客户端”始终是正确的方法。
如果该产品在紧凑型市场中，您将考虑使用一个简单的 api 来快速实施，并使用更复杂的服务器端

＃8 是最简单但经常被忽略的问题之一。 开发人员通常尝试在模式中寻找任何类型的通用性，以证明将抽象功能集成到单个通用组件中是合理的。 有时这是一个好主意，但有时它只会创建难以管理的代码，并且可能对性能产生负面影响。 做好一件事情，而不是少做一件事情。