高并发视频网站适合用计算型ECS还是共享型ECS？

先说结论：高并发视频网站，绝对不能用共享型 ECS，必须上计算型（或更高级的通用型/内存型），且核心瓶颈往往不在单台服务器的 CPU，而在网络带宽和存储架构。

如果你还在考虑用共享型实例来扛高并发视频业务，那基本是在“裸奔”且注定要翻车。下面从几个维度给你拆解清楚为什么，以及正确的架构思路应该是怎样的。

1. 为什么共享型 ECS 是“自杀式”选择？

共享型实例（如阿里云的 t5/t6，或者早期的一些突发性能实例）的设计初衷是低负载、间歇性任务。它的核心机制是“积分制”：平时攒 CPU 积分，用时扣积分。一旦你的应用持续占用 CPU 超过一定阈值（通常是基线性能的 10%-20%），就会触发限流，CPU 频率被强行拉低，延迟飙升甚至直接卡死。

对于视频网站这种场景：

• 用户行为不可预测：高峰期可能瞬间涌入大量请求，共享型的“突发”能力撑不过几秒就会耗尽积分，进入饥饿状态。
• 视频处理本身吃资源：无论是转码、截图、还是简单的鉴权校验，都是 CPU 密集型操作。
• 用户体验零容忍：视频加载卡顿 1 秒，用户就划走了。共享型带来的不可控延迟，会让你的 DAU（日活跃用户）直线下降。

2. 计算型 vs 通用型 vs 内存型：怎么选？

既然排除了共享型，剩下的选择取决于你具体在 ECS 上跑什么服务。视频网站的架构通常分为几层，不同层级对实例类型的需求不同：

A. 应用服务器层（Web/API 服务）

• 推荐：通用型（G 系列）或 计算型（C 系列）
• 理由：这里主要跑 Nginx、Java/Go/Python 后端逻辑、用户鉴权、订单系统等。
  • 通用型（如 g7/g8）：CPU 与内存比例均衡（1:4），适合大多数微服务架构。如果你的业务逻辑复杂，涉及大量对象创建和 GC，通用型更稳妥。
  • 计算型（如 c7/c8）：CPU 与内存比例更高（1:2），适合纯计算密集型的后端逻辑。如果你们的服务主要是轻量级 API 调用，没有重型数据库交互，计算型性价比更高，单位算力更强。
• 注意：不要为了省那点钱去选内存型（r 系列），除非你的应用有巨大的缓存需求（比如本地缓存热点数据）。

B. 媒体处理层（转码、截图、水印）

• 推荐：高性能计算型（HPC）或 弹性裸金属服务器
• 理由：视频转码是典型的 CPU 密集型任务。FFmpeg 等工具在多核并行下才能发挥最大效能。
  • 普通计算型虽然能用，但在大规模并发转码时，单节点吞吐量有限。
  • 建议直接使用云厂商提供的媒体处理服务（MPS），而不是自己搭 ECS 集群去转码。因为 MPS 是按量付费、自动伸缩、专业优化的，比自己维护一堆 ECS 便宜且稳定得多。

C. 静态资源分发（视频文件存储）

• 关键点：不要用 ECS 存视频！
• 正确做法：使用 OSS（对象存储） + CDN。
  • 视频文件体积大、IO 密集，ECS 的本地磁盘 IOPS 远远比不上 OSS。
  • 通过 CDN 将视频节点下沉到边缘，用户就近访问，极大降低源站压力。
  • 如果非要问 ECS 的角色，它只负责生成上传签名、管理元数据（数据库）、调度下载任务，而不直接承载视频流的传输。

3. 真正的高并发视频网站架构真相

很多新手容易陷入一个误区：“我只要买够贵的 ECS，就能扛住高并发”。这是错的。

在高并发视频场景下，ECS 只是计算单元，真正的瓶颈通常在：

1. 公网带宽：视频流量巨大，如果按固定带宽购买，极易被打满；如果按流量计费，成本会爆炸。解决方案是使用 CDN 提速，并配置合理的带宽上限策略。
2. 连接数限制：Nginx 或网关层的 worker_connections 需要调优，否则还没到 CPU 瓶颈，TCP 连接就先满了。
3. 数据库 IO：用户信息、播放记录、评论等高并发读写，必须上 Redis 缓存集群 和 分库分表的 MySQL/PolarDB，不能让所有请求都打到一台 ECS 上的 MySQL 实例。
4. 负载均衡（SLB/ALB）：前端必须挂 SLB，实现流量分发和健康检查。单点 ECS 再强也是单点故障。

4. 实操建议

1. 起步阶段：

   • Web 服务：通用型 g7 实例（4C8G 或 8C16G）。
   • 存储：OSS + CDN。
   • 缓存：Redis 主从版。
   • 数据库：PolarDB 或 RDS MySQL 高可用版。

2. 高并发优化：

   • 水平扩展：不要试图用单机 ECS 扛所有流量。通过 SLB + Auto Scaling（弹性伸缩）组，根据 CPU 使用率或 QPS 自动增加 ECS 实例数量。这才是云计算的意义。
   • 动静分离：确保 HTML/CSS/JS 和图片走 CDN，视频流走 CDN 回源 OSS，只有登录、支付、评论等动态接口才落到 ECS。
   • 监控告警：部署 Prometheus + Grafana，监控 CPU、内存、网络吞吐、磁盘 IO。设置阈值告警，避免问题发生后才后知后觉。

3. 避坑指南：

   • 不要在生产环境使用共享型实例。
   • 不要直接在 ECS 本地磁盘存储用户上传的视频文件。
   • 不要忽略安全组规则，开放不必要的端口会导致被扫描甚至入侵。
   • 不要低估 CDN 的重要性。对于视频网站，CDN 能解决 80% 的带宽和并发问题。

总结：放弃共享型，选用通用型或计算型 ECS，配合 OSS+CDN 做存储和分发，通过弹性伸缩应对流量波动，才是高并发视频网站的正道。