有哪些很好的资源来设计可以很好地扩展的基于 Web 服务的架构？ [关闭]

Question

我有一个 Web 应用程序，目前有大约 500,000 名用户，平均每小时大约 500 次页面浏览量，我们预计在明年内必须扩展到 20,000,000 名用户。

我们当前的系统无法处理这种规模，因此我们需要转向可以处理的系统。

我认为基于服务的架构会更加健壮，并允许组件服务相互独立并独立于主应用程序进行扩展。

但有人警告我，可以轻松设计出无法很好扩展的服务架构，而且由于我几乎没有设计此类系统的经验，因此浏览一些推荐的资源可能比“试一试”要好在它。”

那么，推荐哪些资源来构建可扩展的系统？该平台是 .Net，但我想同样的信息适用于任何基于服务的架构，无论平台如何。

Answer 1

我首先要回答 Gennady Shumakher 的评论 - “目前您认为不可扩展的系统瓶颈是什么？”。一旦你知道了这一点，你就可以具体地处理它，然后是你需要的整个应用程序。

Twitter 是一项有趣的研究。它开始时只有少量请求，但已迅速发展成为一个使用量很大的平台，拥有全球流量。 This 可能有用。这个blog on scalability 可能也很有趣。

Answer 2

我想在演示文稿中推荐 Ebay architectural principles presentation 和一个好的 writeup。实际上，Ebay 采用了典型的面向服务的方法。服务由函数提取，以便每个服务可以独立扩展。我认为有一些你可以学习的好点。

Answer 3

理论上它可以扩展，但您需要注意延迟。假设您将一个模块外部化，现在您可以拥有两个服务，代替一个服务，但是在发送、处理、回复外部服务上的一个请求所需的时间里，您可能已经处理了 100 个内部请求，所以除非您有100 台服务器实际上会降低吞吐量，但无论哪种方式，使用 100 台服务器与 1 台服务器相比，您在维护和空间方面付出的代价要高得多。根据经验，如果您需要发送大量数据，通常必须衡量延迟和处理之间的平衡数据，您最好不要将该步骤分离到服务中。幸运的是，您有一个正在运行的系统，您可以根据该系统进行测量，大多数人不得不仅根据规格来猜测这一点。

因此，请考虑您的数据流模式并偏爱局部性，将您的应用程序切入服务中是一门艺术，而不是反对它。

您可能有兴趣阅读并发模式，因为它归根结底。