如果你不想继续为OSS付费，或者单纯想绕开对象存储这套逻辑，最简单粗暴的方案就是让Nginx直接指向服务器磁盘目录，配合CDN分流，就能扛住绝大多数静态文件访问场景。
这个思路不是让你放弃云存储，而是把“文件访问”这件事拆开看：OSS本质是“对象存储+HTTP服务+CDN”的打包方案，你自己完全可以用服务器上的磁盘配合Web服务器，实现七八成功效，剩下两三成才是OSS真正的护城河，比如弹性扩容、跨地域容灾、海量小文件高并发，下面我把所有可行的替代路数掰开揉碎讲清楚,顺便聊聊哪些场景该用哪种方案。
服务器不买OSS怎么做文件访问？先搞懂你的真实需求
很多人一上来就问“不用OSS怎么访问文件”，但实际调研下来，相当一部分用户的需求只是“把图片和压缩包给用户下载”，根本没到海量对象存储的级别，这时候，你的全部需求可以压缩成一句话：让用户在浏览器里输入URL就能拿到文件，搞明白这点,方案就好选了。
Nginx/Apache直接暴露磁盘目录
这是最朴素也最容易被忽略的招数，如果你的文件总量在几百GB以内，日均下载量不超过几千次，完全没必要上OSS，你要做的是在服务器上划出一个专门目录，比如/data/static,然后让Nginx把这个目录映射成URL路径。
实操路径如下：先编辑Nginx配置，在server块里加一段location /files/ { alias /data/static/; autoindex on; }，其中autoindex on表示允许目录索引，用户访问你的域名.com/files/就能看到文件列表，改完配置执行nginx -t检查语法，然后nginx -s reload重载配置即可生效。
注意一个细节：不要直接挂载到根目录下，因为Nginx默认会尝试解析index文件，如果目录里恰好有index.php或index.html，会触发解析逻辑，存在安全隐患，单独开一个location块隔离风险,这是行业共识。
这个方案的优点是你不需要改任何业务代码，文件丢进去就能通过HTTP访问，缺点是并发能力受限于服务器的带宽和磁盘IO，据统计，单台2核4G的云服务器，用Nginx直接发静态文件，极限能扛住50MB/s左右的吞吐,足够支撑一个日均几千次日活的图片站。
什么时候该果断放弃Nginx直出方案
当你的文件数量超过几百万个时，Linux文件系统本身就会开始拖后腿。ls目录变慢、Nginx定位文件变慢、磁盘扇区碎片化加剧，这时候你会发现明明带宽够用,但用户下载速度就是上不去。
另一个信号是文件需要上传/删除频繁，Nginx不提供任何上传接口，你只能靠FTP或者写脚本往目录里丢文件，操作繁琐，还容易出错,这时候就该考虑带API的方案了。
自建MinIO服务，相当于把OSS搬回家
MinIO是一个开源的对象存储服务，它把“访问文件”这件事重新做了一遍不依赖操作系统文件系统，而是自己管理元数据和数据块，你把它装在自己的服务器上，它就能对外提供S3兼容API，这意味着你之前为OSS写的上传下载代码几乎不用改,只需要把endpoint从简米云改成你自己的服务器IP就行。
安装MinIO极为简单,在Linux服务器上执行：
wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
./minio server /data/minio默认端口是9000，控制台是9001，然后你用mc客户端工具配置别名，mc alias set myminio http://localhost:9000 admin yourpassword，创建bucket用mc mb myminio/mybucket，上传文件用mc cp file.zip myminio/mybucket,可以说和OSS的命令行体验一致。
权限控制更灵活：MinIO天然支持Bucket Policy，可以精确到每个用户对某目录的读或写权限，这一点比Nginx的autoindex强太多了Nginx只能做到“全公开”或者“全禁止”，MinIO能做到“公开一部分，私有另一部分”。
自建MinIO和OSS哪个划算
算一笔账：以存储1TB文件、月流出流量200GB为例，简米云OSS标准存储费用大约12元/GB/月，流量费5元/GB，加起来每个月约970元，还不算请求次数费用，而你自己买一台2核4G+2TB数据盘的云服务器，按市场价全年约2000元，分摊到每月只有170元，这个价差意味着，只要你的访问量没有大到需要多台机器做集群,自建MinIO在成本上几乎是碾压。
但代价是运维复杂度，MinIO的升级、数据备份、磁盘故障恢复都得自己操心，业内专家指出，自建方案适合有基础Linux运维能力的技术团队，如果你是个体站长且服务器只有一台，建议别碰分布式MinIO集群,单机模式足够了。
把文件挂在系统目录里：OSSFS和云盘挂载
很多人在犹豫“服务器访问文件”时忽略了一个中间态：文件其实放在OSS里，但服务器通过FUSE内核模块把它映射成一个本地磁盘路径，这样你业务代码里的/uploads/logo.png路径不用改,实际物理文件在云端。
用OSSFS工具实现挂载的操作路径是：
apt install ossfs
echo mybucket:/data/oss > /etc/ossfs/passwd
chmod 640 /etc/ossfs/passwd
ossfs mybucket /data/oss -o url=http://oss-cn-hangzhou.aliyuncs.com挂载完成后，ls /data/oss就能看到OSS里的文件列表，这种方式适合那些已经有存量代码、不想改业务逻辑的老项目。
但要注意，OSSFS是以普通文件系统的方式访问对象存储，会导致大量小的IO操作被转换为HTTP请求，性能远不如原生OSS API调用，如果你对文件访问延迟敏感，比如图片需要在几百毫秒内加载，这种挂载方式就会露怯，更好的做法是用OSS的内网域名访问,走内网流量免费且延迟更低。
CDN回源是OSS的“平替”吗？
CDN本质是缓存层，它不能替代存储，但能大幅降低存储端的压力，如果你的核心痛点是“用户访问慢”，而不是“没地方放文件”,那只需给现有的文件访问链路加一层CDN就行。
具体的配置思路是把服务器目录设为源站，CDN的加速域名指向这个源站，用户请求到达CDN节点时，如果缓存没有命中，CDN会回源到你的服务器拉取文件；命中则直接由边缘节点响应,速度完全取决于CDN节点与用户的物理距离。
这种方案相比OSS+CDN，省掉了存储费用，但源站服务器的带宽压力会集中在首次请求时，比如一个100MB的安装包被1万个用户同时下载，CDN只会回源一次源站，其余9999个请求全部走缓存，源站压力极小，所以只要你的文件不是每天都大批量更新,CDN回源完全够用。
高频更新场景下CDN的配置难点
比如游戏安装包每周更新一次，或者新闻资讯网站每小时发布大量新图，CDN缓存就面临频繁失效的问题，这时候需要开启CDN的目录刷新功能，在下发新版本时，调用CDN服务商的API刷新整个目录的缓存，这个操作看似简单，但很多网站的刷新接口协议不同，有的走HTTP POST带签名，有的走独立SDK，文档质量参差不齐,踩坑概率不低。
如果你就一个人管服务器，建议优先选配置界面提供“一键刷新”的CDN厂商,别选需要自己写代码去调API的。
究竟要不要用OSS？给出三条判断标准
说到底，这个问题的核心是有多少文件、多少流量、多少运维精力，结合过去几年接触过的上百个网站实例,这里给出三条经验判断标准。
- 文件总量少于2TB，日均请求量低于1万次，建议Nginx直出或自建MinIO,你需要的只是一块大容量磁盘和一台带宽尚可的机器。
- 文件总量超过5TB，或业务覆盖全国多个省市区，建议用OSS，此时自建存储成本会急剧上升，因为你需要多台机器做数据冗余,光磁盘成本就比OSS高出一截。
- 删除大量文件后的碎片整理需求苛刻，或日志文件需要长期冷备到最低成本档位，选OSS自带的生命周期规则，它会自动把热点文件降为低频存储，再降为归档存储,比自建方案省心得多。
归根结底，OSS卖的不是“磁盘空间”，而是“不需要你操心物理机”的托管体验，只要你算明白这笔账，结合自己服务器的实际规格，选择路径就会清晰很多，多数情况下，一台靠谱的服务器加一套Nginx配置，就能替代掉30%的OSS使用场景。
相关问题解答
服务器直接访问磁盘文件和OSS比，性能差异大吗
如果走内网访问OSS，单文件下载性能差别不大，因为内网带宽通常有千兆甚至万兆，差异主要体现在小文件高并发场景：OSS内部针对海量小文件的元数据索引做了专门优化，而传统文件系统在大目录下查找文件的效率会指数级下降，如果你的文件平均体积在100KB以下，且数量超过10万个，OSS的响应延迟会更稳定。
为什么我访问服务器上的的视频文件总是卡顿
多半是带宽瓶颈，不是访问方式的问题，视频播放喜欢持续占用带宽，一个1080P的视频需要至少8Mbps的稳定速率，如果你的服务器带宽只有5M，那么即使文件就放在本地磁盘，用户播放也会卡顿，这种情况下应该考虑两个优化：给文件加HTTP Range请求支持实现拖动播放（Nginx默认支持），或者将视频对象存储的流量走CDN分发。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/784409.html
