我应该怎么做才能扩展高流量的网站？

14

对于需要“横向扩展”以处理容量的网站应采取什么最佳实践？既然人们正在考虑使用云，但是这一点尤其重要，但是可能会在基础知识上有所遗漏。

我有兴趣听到有关您认为的最佳实践的一切信息，从开发级任务到基础结构再到管理。

— goodguys_activate
source

1

查看：highscalability.com

— Casebash 2010年

知道Windows Server App Fabric和缓存的人可以在这里发布一些东西吗？我不是该领域的专家，并且想了解更多。

— goodguys_activate

您想了解什么AppFabric？

— 亨里克

有关于如何缩放网页，看看其中的一些技巧：前端级服务器脚本级模型和数据库设计级服务器横向扩展，分片查看更多：olivetit.blogspot.com/2013/05/...

16

并发设计

也就是说，在编写代码时，请计划有多个线程在运行。计划共享状态（通常只是数据库）。规划多个流程。规划物流。

这使您可以通过负载平衡将系统分布在多台计算机和多个进程之间。它使您可以在发生故障的情况下运行冗余进程，并且在需要就地修改系统的情况下，不必杀死所有服务即可这样做。

— 鱼烤面包机
source

13

您可能会考虑的几件事：

分离数据存储的读取侧和写入侧。
- CQRS /事件来源
- CQS
- 消息传递/演员
避免共享进程和线程状态
- 因此避免锁定
- 您可以通过类型系统来避免这种情况，方法是将类，结构和其他数据类型创建为不可变的，即在构造后保持不变。特别是对于复杂的抽象数据类型，它的工作异常出色（例如jQuery的实现）
不阻止IO上的Web服务器线程。如果您使用的是ASP.Net，请使用带有APM模式/任务并行库（TPL）的异步页面/动作
不将状态负载保存在用户会话字典中
- 当IIS中发生线程迁移时，必须跨线程移动它。
- 具有智能路由，使得不安全/静态资源无法与增加开销的相同应用程序框架（例如ASP.Net）一起使用。例如，看看有不同的Web服务器。
使用异步工作流模式编写连续传递代码（例如，bind（haskell）/callcc/Tasks.ContinueWith/F#的异步）
使用排队论来计算瓶颈可能发生的位置
使用基于推送而不是基于请求的更新来读取模型和其他应用程序状态。例如通过RabbitMQ / nServiceBus
使用功能最少的适用“ http处理程序”
对于静态文件，请提供电子标签和缓存过期策略，以使Web基础结构能够正常运行（例如，使用鱿鱼代理）
（请雇用我解决您的扩展问题并获得现场教程；）

— 亨里克
source

4

分享Nothing体系结构。

考虑到这一点，与您可能会想到的相反，请不要立即跳转到横向扩展解决方案。系统外开销与系统内调用之间的权衡不容小under。例如，通过任何网络接口建立数据库连接所花费的时间比进行本地呼叫所花费的时间更长。预算横向扩展所需的管理，电源和调整工作量，而不是真正的大型系统需要多少美元。

无论如何，“无共享”架构仍然具有巨大的价值，您可以在需要时分层和扩展系统。

— JéQueue
source

0

并行处理多个主机名的请求

HTTP标准的一部分是说Web客户端将为每个DNS主机最多请求2个会话。这是一个解决方案，您可以使用它和您的www.domain.com别名并获得更高的请求并发性，从而使页面加载速度更快：

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

基本上，它涉及到编辑ASP.NET HTTP处理程序，以替换将客户端发送到的目标主机，每个主机都是“ www”的CNAME。

— goodguys_activate
source

1

这个答案更多地与客户端性能有关，与在服务器端进行横向扩展无关。

— 刘坚

我在考虑通过HTTP聚合其他数据源的中间层。Azure Table，OData只是一些示例...到目前为止，仍然是服务器告诉浏览器（javascript）做什么。

— goodguys_activate 2011年

0

安全，快速，可靠的DNS

我发现有一些使用注册商的DNS服务器的大容量网站，该服务器不具有正常运行时间或性能的SLA。此外，他们的服务器位于印度，仅延迟就增加了DNS欺骗者可能毒害您客户或中间ISP缓存的机会。这甚至会导致您的SSL保护流量在没有任何人知道的情况下被重定向。

在缓存记录之前，DNS速度还会影响服务器的初始加载时间。

我对大多数客户使用DynDNS或Neustar，因为他们的DNS基础结构非常可靠（尽管价格昂贵，而且我与这些公司没有其他隶属关系）。

— goodguys_activate
source

2

错误... DNS真的对您来说是一个严重的瓶颈吗？我认为这将是要优化的最后一件事。

— Fishtoaster

@Fishtoaster-刚以粗体编辑过的部分。我本来是系统管理员，DNS安全在SSL验证中起着重要作用。确实会出现DNS连接和性能问题，例如：到SOA的BGP路由问题，与CDN有关的Anycasting问题，延迟问题，缓存中毒等。我写了一个DNS最佳做法扫描工具（有线级别），我将很快将其放在互联网上。随意尝试一下，因为它涵盖了我提到的许多连接问题。（或向我发送电子邮件，我会详细说明）

— goodguys_activate

2

我并不是说没有与您列出的DNS相关的性能问题。在我看来，将出现更多基本问题（数据库访问，页面缓存，简单的代码循环复杂性，服务器进程负载平衡，硬件分发点选择等），并在几个数量级上得到解决，同时在DNS之前进行扩展相关的问题将是一个问题。

— Fishtoaster

...我完全同意，正如您提到的，还有更多重要的事情要担心。也许这就是为什么这个想法的评分为零:) ..但是，到目前为止，我是唯一回答这个问题的人。

— goodguys_activate

1

DNS性能无疑是一个巨大的瓶颈-好的与坏之间可能不会存在很多毫秒的差异，但是由于DNS会在每次调用（或几乎每次调用）时受到影响，因此可以迅速累积。尤其是当您接触现代CDN特技时。

— Wyatt Barnett

0

我认为关键很简单：

有简单的代码。这意味着您要了解和理解。在扩展和更改服务器时，您需要了解正在发生的事情。您可能还需要添加需要快速了解的编码人员。调用不明显的随机代码的Hook和XML文件非常糟糕。

然后，您可以测试并查找问题。

在这里查看：http : //blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

我们在stellarbuild尝试确保我们的网站在不停机的情况下进行扩展。这意味着您需要能够知道您的代码做什么以及在哪里执行。即使您正在测试其他机器，也不会花太长时间进行扩展。可悲的是，大多数人只有在为时已晚时才开始。在我看来，您只能进行一次优化。

— msj121
source