该技术堆栈可以扩展吗？
Can this technology stack scale?
我的客户要求我构建一个可以实时聊天、发送图像和视频的实时应用程序。他让我想出自己的技术栈，所以我做了很多研究，发现最容易构建的是使用下面的技术栈
1) Node.js 和群集以最大化一个服务器实例的 CPU 核心 - 语言
2) Socket.io - 实时框架
3) Redis - pub/sub 服务器的多个实例
4) Nginx - 反向代理和负载平衡多台服务器
5) Amazon EC2 - 到 运行 服务器
6) Amazon S3 和 CloudFront - 保存 images/videos 并交付
如果我对上面的堆栈有误，请纠正我。我真正的问题是，上面的技术堆栈可以每秒扩展 1,000,000 条消息（文本、图像、视频）吗？
任何使用过 node.js 和 socket.io 的人都可以给我一个见解或上述堆栈的替代方案。
此致，
SinusGob
My real question is, can the above tech stack scale 1,000,000 messages
per seconds (text, images, videos)?
当然可以。具有正确的设计和足够的硬件。你的客户应该问的问题实际上不是它是否可以做得那么大，而是可以以什么成本和实用性来完成，这些是最好的选择。
让我们看看你提到的每一件作品：
node.js - 对于以 I/O 为中心的应用程序，它是大规模应用的绝佳选择，它可以通过在集群中部署许多 CPU 进行扩展（每服务器多进程和多服务器）。这种规模的实用性在很大程度上取决于所有这些服务器进程需要访问什么样的共享数据。通常，数据存储最终会成为扩展中更难的瓶颈，因为在请求处理时很容易投入更多的服务器。将更多硬件投入集中式数据存储并不容易。有很多方法可以做到这一点，但这在很大程度上取决于应用程序对您的操作方式和难度的要求。
socket.io - 如果您需要有效的服务器推送小消息，那么 socket.io 可能是最好的方法，因为它在推送给客户端。不过，它并不适用于所有类型的交通工具。例如，我不会通过 socket.io 移动大图像或视频，因为有更多专门的方法可以做到这一点。因此，socket.io 的使用在很大程度上取决于应用程序想要使用它的确切目的。如果您想将视频推送给客户端，您也可以只推送一个 URL 并让客户端转身并使用众所周知的大规模技术通过常规 http URL 请求视频。
Redis - 同样，在某些方面很棒，但并非在所有方面都很棒。所以，这真的取决于你想做什么。我之前解释的是，您的数据存储的设计和通过它的交易数量可能是您真正的规模问题所在。如果我开始这份工作，我会首先了解服务器的数据存储需求、每秒各种类型的事务、缓存策略、冗余、故障转移、数据持久性等……并设计高首先扩展对数据的访问。我不完全确定 Redis 是首选。我可能会建议您在项目早期需要一名高级数据库人员作为顾问。
Nginx - 许多大型站点都在使用 nginx，因此它无疑是一个很好的工具。它是否是适合您的工具取决于您的设计。我可能会最后处理这部分，因为它似乎不是设计的核心，一旦系统的其余部分布置好，您就可以在这里考虑您需要什么。
Amazon EC2 - 几种可能的选择之一。这些选择很难在同类比较中直接进行比较。大型系统已经建立在 EC2 之外，因此那里有概念证明，一般架构似乎是合适的匹配。如果您想知道真正的 gremlins 在哪里，您需要一位在 EC2 上做过大规模工作的顾问。
Amazon S3 - 我个人知道一些非常高的存储和带宽站点使用 S3 来处理视频和图像。它适用于此。
所以......如果以正确的方式使用它们，这些通常可能是很好的工具。 Redis 将是一个问号，具体取决于实际应用程序的存储需求（您提供了零要求，并且不能选择零要求的数据库）。一个更合理的答案是基于将一组高级需求放在一起，分析系统需要做什么才能为 1,000,000 人提供服务。可以将这些要求与其中一些部分的已知功能进行比较，以开始扩展系统。然后，您必须将一些基准测试放在一起，以 运行 对系统的某些部分进行一些测试。成功与否在很大程度上取决于应用程序的构建方式、工具的使用方式以及选择的工具。您可以使用许多不同类型的工具来成功地进行缩放。哎呀，PHP 上的 Facebook 运行（好吧，高度修改、定制的 PHP 在 运行 时间根本不是典型的 PHP）。
我的客户要求我构建一个可以实时聊天、发送图像和视频的实时应用程序。他让我想出自己的技术栈，所以我做了很多研究，发现最容易构建的是使用下面的技术栈
1) Node.js 和群集以最大化一个服务器实例的 CPU 核心 - 语言
2) Socket.io - 实时框架
3) Redis - pub/sub 服务器的多个实例
4) Nginx - 反向代理和负载平衡多台服务器
5) Amazon EC2 - 到 运行 服务器
6) Amazon S3 和 CloudFront - 保存 images/videos 并交付
如果我对上面的堆栈有误，请纠正我。我真正的问题是，上面的技术堆栈可以每秒扩展 1,000,000 条消息（文本、图像、视频）吗？
任何使用过 node.js 和 socket.io 的人都可以给我一个见解或上述堆栈的替代方案。
此致，
SinusGob
My real question is, can the above tech stack scale 1,000,000 messages per seconds (text, images, videos)?
当然可以。具有正确的设计和足够的硬件。你的客户应该问的问题实际上不是它是否可以做得那么大，而是可以以什么成本和实用性来完成，这些是最好的选择。
让我们看看你提到的每一件作品：
node.js - 对于以 I/O 为中心的应用程序，它是大规模应用的绝佳选择，它可以通过在集群中部署许多 CPU 进行扩展（每服务器多进程和多服务器）。这种规模的实用性在很大程度上取决于所有这些服务器进程需要访问什么样的共享数据。通常，数据存储最终会成为扩展中更难的瓶颈，因为在请求处理时很容易投入更多的服务器。将更多硬件投入集中式数据存储并不容易。有很多方法可以做到这一点，但这在很大程度上取决于应用程序对您的操作方式和难度的要求。
socket.io - 如果您需要有效的服务器推送小消息，那么 socket.io 可能是最好的方法，因为它在推送给客户端。不过，它并不适用于所有类型的交通工具。例如，我不会通过 socket.io 移动大图像或视频，因为有更多专门的方法可以做到这一点。因此，socket.io 的使用在很大程度上取决于应用程序想要使用它的确切目的。如果您想将视频推送给客户端，您也可以只推送一个 URL 并让客户端转身并使用众所周知的大规模技术通过常规 http URL 请求视频。
Redis - 同样，在某些方面很棒，但并非在所有方面都很棒。所以，这真的取决于你想做什么。我之前解释的是，您的数据存储的设计和通过它的交易数量可能是您真正的规模问题所在。如果我开始这份工作，我会首先了解服务器的数据存储需求、每秒各种类型的事务、缓存策略、冗余、故障转移、数据持久性等……并设计高首先扩展对数据的访问。我不完全确定 Redis 是首选。我可能会建议您在项目早期需要一名高级数据库人员作为顾问。
Nginx - 许多大型站点都在使用 nginx，因此它无疑是一个很好的工具。它是否是适合您的工具取决于您的设计。我可能会最后处理这部分，因为它似乎不是设计的核心，一旦系统的其余部分布置好，您就可以在这里考虑您需要什么。
Amazon EC2 - 几种可能的选择之一。这些选择很难在同类比较中直接进行比较。大型系统已经建立在 EC2 之外，因此那里有概念证明，一般架构似乎是合适的匹配。如果您想知道真正的 gremlins 在哪里，您需要一位在 EC2 上做过大规模工作的顾问。
Amazon S3 - 我个人知道一些非常高的存储和带宽站点使用 S3 来处理视频和图像。它适用于此。
所以......如果以正确的方式使用它们，这些通常可能是很好的工具。 Redis 将是一个问号，具体取决于实际应用程序的存储需求（您提供了零要求，并且不能选择零要求的数据库）。一个更合理的答案是基于将一组高级需求放在一起，分析系统需要做什么才能为 1,000,000 人提供服务。可以将这些要求与其中一些部分的已知功能进行比较，以开始扩展系统。然后，您必须将一些基准测试放在一起，以 运行 对系统的某些部分进行一些测试。成功与否在很大程度上取决于应用程序的构建方式、工具的使用方式以及选择的工具。您可以使用许多不同类型的工具来成功地进行缩放。哎呀，PHP 上的 Facebook 运行（好吧，高度修改、定制的 PHP 在 运行 时间根本不是典型的 PHP）。