3000人同时访问一个单纯的html文件（放在阿里云最低配的ECS下，apache），多少带宽足够？

一个邀请函之类的html文件，所有图片、视频，包括样式表都放在腾讯云COS了，文件自身大概28K左右，阿里云最低配的ECS。

3000人同时访问一个纯静态文件，静态文件大小28K，那瞬间请求流量最大理论值为：3000x28K≈82M 。但是此值仅仅是理论上的瞬间最大流量，因为你的站点不可能每时每秒都保持在3000人访问，而是一段时间内的访问人数。如果真是每秒都至少是3000人访问，那你的服务器上行带宽至少得在 82x8 = 656M（之所以乘以8，是因为我们说的速率和运营商说的速率不是一个概念，换算单位不同），这样看来费用是相当的高。

但实际情况下并不能这样计算，实际请求带宽要远远低于656M，原因主要有以下几点：

用户流量是分散的，并不是每秒都有3000人访问；
浏览器对于静态页是有缓存的，所以这3000人中有一部分用户发出请求后，其实是直接从本地缓存中加载的，而没有请求远程服务器。

要知道，服务器的上行带宽是很贵的，按上面计算方法，就算打个折，你的服务器固定带宽100M的话，那光带宽费用一个月就要近7000元。

所以一般中小型网站的服务器上行带宽100M都算很大了，鉴于你的访客量不固定，我给你的建议是：

前端走CDN缓存，如果静态文件长期不更新，可以把缓存时间设得很长，如一个月；
后端ECS选择低配即可，带宽不要选固定带宽（选择按使用流量来计费，带宽选择5M足够了）。

这种配置下，别说3000人同时访问了，更高的并发都能抗得住。因为CDN本身就充当了负载均衡的角度，而且CDN节点遍布全国，使得用户“就近读取”静态资源。

以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，欢迎关注我了解更多科技知识！

微服务架构为何需要搭配API网关？

微服务架构可以理解为一种架构风格，将一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。而API网关则是负责提供一套单一且统一的API入口点，其跨越一个或者多个内部API。其通常亦设定了层速率限制与安全性机制。

两者搭配有如下几点优势：

第一：可以隔离内部与外部的联系，保证内部服务和数据信息的安全，外部无法直接访问到内部数据和服务，隔绝了对内部服务和数据的窥探；
第二：API网关可以提供一层有利的保护罩，保证内部服务和数据不会受到攻击；
第三：API可以支持多种协议的适配，可以更好的协调微服务的协议形式，使内部的服务之间不必拘泥于一种协议的开发，提高了服务开发的灵活性；
第四：API网关可以进行协议适配、安全验证等，降低了对微服务开发对外部的适配，使之可以更贴近实际核心业务的开发。