这项技术能比例尺吗？

Question

我的客户要求我建立一个实时应用程序，可以聊天，发送图像和视频所有的实时。他让我想出我自己的技术栈，所以我做了很多研究，发现最容易构建的技术栈是使用下面的技术栈。

1) Node.js和集群将服务器语言的一个实例的CPU核心最大化。

2) Socket.io -实时框架

3) Redis - pub/sub多个服务器实例

4) Nginx -反向代理和负载平衡多台服务器

5) EC2 -运行服务器

6)亚马逊S3和CloudFront -保存图像/视频并交付

如果我错了上面的堆栈，请纠正我。我真正的问题是，上面的技术堆栈是否能以每秒1,000,000条消息(文本、图像、视频)为尺度？

任何有过node.js和socket.io经验的人，都可以给我提供上述堆栈的见解或替代方案。

致以敬意，

SinusGob

Answer 1

我真正的问题是，上面的技术堆栈是否能以每秒1,000,000条消息(文本、图像、视频)为尺度？

当然可以。有正确的设计和足够的硬件。你的客户应该问的问题并不是它是否能变得那么大，而是它能以什么样的成本和实用性去做，这些都是最好的选择。

让我们看看你提到的每一段：

node.js -对于以I/O为中心的应用程序来说，它是一个高规模的极好的选择，它可以通过在集群中部署多个CPU进行扩展(每个服务器和多个服务器都有多个进程)。这种规模的实用性在很大程度上取决于所有这些服务器进程都需要访问何种类型的共享数据。通常，数据存储最终会成为扩展的更困难的瓶颈，因为在请求处理过程中很容易抛出更多的服务器。在集中式数据存储中抛出更多的硬件并非易事。有很多方法可以做到这一点，但这在很大程度上取决于应用程序对你如何做到和它有多难的要求。

socket.io --如果您需要高效的服务器推送小消息，那么socket.io可能是最好的方法，因为它对客户端最有效。但并不是所有类型的交通都很好。例如，我不会在socket.io中移动大的图像或视频，因为有更多的目的构建的方法可以做到这一点。因此，socket.io的使用在很大程度上取决于应用程序想要使用它做什么。如果您想要将视频推送到客户端，您还可以只按一个URL，让客户转过来，并使用众所周知的高比例尺技术通过常规的http URL请求视频。

Redis --再一次，对于某些事情来说很棒，而不是所有事情都很棒。所以，这真的取决于你想做什么。我前面解释的是，数据存储的设计和通过数据存储的事务数量可能是真正的规模问题所在。如果我要开始这项工作，我将首先了解服务器的数据存储需求、各种类型的每秒事务、缓存策略、冗余、故障转移、数据持久性等.并设计了对数据的高比例尺访问。我不能完全确定红葡萄酒是首选。我可能会建议你需要一个高规模的数据库家伙作为一个顾问在项目初期。

nginx -很多使用nginx的高规模站点，所以它确实是一个很好的工具。它是否是正确的工具取决于你的设计。我可能会在最后完成这个部分，因为它似乎没有设计的那么重要，一旦系统的其余部分被布置好，您就可以在这里考虑您需要什么。

EC2 --几种可能的选择之一。这些选择很难在苹果中直接与苹果进行比较。大规模的系统已经建立在EC2上，所以这里有概念的证明，一般的体系结构看起来是合适的。如果你想知道真正的小妖精在哪里，你需要一位在EC2上做过大量工作的顾问。

Amazon S3 --我个人知道一些非常高的存储和带宽站点使用S3来处理视频和图像。它对此很有效。

所以..。如果正确使用这些工具，通常都是很好的工具。Redis将是一个问号，取决于实际应用程序的存储需求(您已经提供了零需求，并且不能选择零需求的数据库)。一个更合理的答案将基于收集一组高层次的需求，分析系统需要做些什么才能为100万人提供任何服务。这些需求可以与一些已知的功能进行比较，以便在扩展系统时启动大致的功能。然后，您必须将一些基准测试放在一起，以便在系统的某些部分上运行一些测试。失败的成功在很大程度上取决于应用程序的构建方式和工具的使用方式，就像选择了哪些工具一样。您可以使用许多不同类型的工具进行成功的扩展。见鬼，Facebook是在PHP上运行的(嗯，一个经过高度修改的定制PHP，在运行时根本不是典型的PHP )。