构建高度可扩展的Web服务

Question

我和我的团队正在开发一个需要能够处理相当繁忙流量的应用程序。不是Facebook级别，但在未来我希望能够在没有大量代码重写的情况下扩展到它。

我的想法是通过自己的界面将所有内容模块化为单独的服务。因此，例如，消息传递将具有可能具有send和getMessages（）作为方法的消息传递接口，然后PHP Web应用程序将通过soap或curl或类似的东西简单地查询该接口。然后，消息传递应用程序可以是任何类型的应用程序，因此Java应用程序或Python或其他任何适用于具有其自己的单独数据库分片的特定功能。

这是一个好方法吗？

Answer 1

Modularise

  

我的想法是模块化   一切都进入单独的服务   他们自己的接口。所以举个例子   消息传递将有消息传递   可能有发送和的接口   getMessages（）作为方法，然后是   PHP Web应用程序只会查询这个   通过肥皂或卷曲或   类似的东西

我喜欢将每个服务模块分开的想法（良好的编码原则）。我不喜欢关于SOAP的部分:(。我认为这是复杂的方式。我会选择像JSON-RPC之类的东西。

一些快速提示：

  

我的团队和我在一起   开发需要的应用程序   能够处理相当沉重的   交通。不是facebook级别，而是在   未来我希望能够   在没有大量代码的情况下扩展到   重新写入。

• 和其他人一样，也暗示我会建议你看看High Scalability blog。
• 首先使用YSlow / google page speed关注前端。这种优化很容易实现，可以为您带来显着的提升。来自Yslow网页的引用：

  

最终用户响应时间的80％是   花在了前端。其中大部分   下载所有的时间都被束缚了   页面中的组件：图像，   样式表，脚本，Flash等   减少中的组件数量   转减了HTTP的数量   呈现页面所需的请求。   这是加快页面的关键。

• 我还建议你看看HipHop的php，它将你的PHP代码转换为C代码，这对facebook来说是一个巨大的推动力。引文来自文章：

  

使用HipHop我们减少了CPU   在我们的Web服务器上平均使用   大约百分之五十，取决于   页。 CPU越少意味着服务器越少   这意味着更少的开销

• 我想如果还没有设置的另一个重大/简单的改进是使用APC（操作码缓存）来缓存已编译的代码。这将为您带来巨大的推动力（转换为HipHop的部件不需要）。

• 如果您希望您的网站扩展，您必须遵循口头禅：

    

  RAM is the new Disk

  ！缓存，缓存，缓存！，例如APC，memcached，redis。

• 首先分析您的PHP代码，然后优化低挂水果。我发现Rasmus Lerdorf的这个audio文件非常有用。阅读博客文章时，您会发现很多提高性能的好方法。
• 另外，我会考虑离开关系数据库，转而使用例如Cassandra。这是我最近看到很多大牌玩家的举动（例如twitter，digg，facebook，reddit）。你必须以这种方式采取完全不同的心态，但我敢打赌，这将是值得的。
• Queue everything and delight every one，例如beanstalkd，gearman或Google App引擎的taskqueue。

Answer 2

这听起来很合理作为第一步，请记住PHP层和消息传递层之间的流量会增加一些延迟。您可能还会考虑：

• 使用（例如）memcached缓存PHP层上的数据。您还可以考虑使用Web代理缓存，例如squid

• 通过将会话数据存储在数据库中，将Web服务器扩展到多台计算机。一旦你可以支持2个Web服务器，添加第三个（第四个，第五个等）应该很简单。请记住，您最终可能还需要将消息传递层扩展到多台计算机。

• 使用PHP e-Accelerator等工具缓存已编译的脚本;应该有助于提高网络层的性能

High Scalability上也有一些很棒的文章，您可能会觉得有帮助。

最后，请记住，过度设计解决方案很容易。您最好的选择是在整个过程中持续测量负载，性能，资源利用率等 - 然后根据需要使用此数据进行调整。

Answer 3

缓存，缓存和更多缓存。 SQL查询缓存，操作码缓存，避免多次查询相同的事情。然后在跑步时使用分析器来跟踪慢点的位置。

Answer 4

围绕一组模块设置高级设计是管理复杂性和结构开发的一种好方法（更是如此，在微观层面）

  

PHP Web应用程序只需通过soap或curl查询此界面

这会在应用程序中引入大量延迟。我建议定义API，但对于任何同步处理的请求，尽可能在单个线程中运行代码。

当然，如果你必须处理多种开发语言，使用通过HTTP运行的接口是一个非常实用的解决方案 - 但如果你正在用PHP开发前端，那么通过编程到一个抽象的PHP API（可能会调用它） Soap，Corba或其他东西），你仍然可以选择以后以不同的方式重新实现后端。

我不确定你的消息是什么意思。如果您正在谈论异步请求处理，那么您需要考虑如何在PHP中实现订阅者。这是一个完整的蠕虫病毒 - 我没有看到用PHP编写的良好的消息处理系统 - 但我还没有看到用Java编写的一个很好的可扩展解决方案 - 其中包括高端一些主要参与者的产品系统。也许有一天我会写一个;）在此期间，你真的希望保持你的复杂（并且可能不太可靠）的业务逻辑在任何类型的订阅者守护程序的单独线程中运行 - 所以一个明显的方法是将目标公开为网页，让订阅者作为守护进程运行，只需获取消息并调用基于Web的API。

如果您完全关心性能/可靠性/可扩展性，那么真的不希望基于消息传递建立同步系统。

HTH

下进行。