别再把图片存进数据库了！从全栈视角看 OSS 的架构本质
从全栈部署实战，聊聊 OSS 对象存储的本质
在进行全栈开发时，新手往往会遇到文件存储的痛点。很多同学在初次接触云服务器部署时，对 OSS（Object Storage Service，对象存储服务）的概念感到模糊。本文将通过一个具体的全栈部署场景，通俗地解释 OSS 的本质及其解决了什么问题。
一、 一个典型的全栈部署场景
假设我们开发了一个主要包含前端、后端和数据库的全栈项目。
当代码编写完成后，常规的部署流程是：
- 租用一台云服务器（ECS）。
- 将前后端代码上传至服务器。
- 配置数据库（以轻量级的 SQLite 为例，数据库本质就是一个
.db文件，也存储在云服务器的磁盘中）。
如果此时有用户（假设叫小明）注册了一个账号，他的文本信息（如用户名、密码哈希、手机号）会通过后端写入服务器上的数据库文件中。到目前为止，一切运行良好。
二、 痛点：当需求增加了“图片上传”
随着项目迭代，我们增加了“用户上传头像”或“发布带图动态”的功能。此时，系统面临一个新的问题：用户上传的图片存哪里？
无论是选择将图片转换成二进制直接存入数据库（方案 A），还是保存在服务器本地的文件系统文件夹中（方案 B），都会给我们的应用服务器带来巨大的压力和扩展瓶颈。
此时的架构可以用下图表示，你会发现所有的压力都集中在了这一台服务器内部：
如上图所示，应用服务器既要处理业务逻辑，又要扛住文件的 I/O 压力，这显然不是一个可持续的架构。
三、 解决方案：OSS 的登场
为了解决上述问题，OSS（对象存储服务）应运而生。
OSS 的本质，可以理解为一个独立于我们应用服务器之外的、专门用来存储海量文件的“超大云端硬盘”。
引入 OSS 后，我们的核心思路是**“存储分离”**：
- 文件存 OSS：用户上传的实体图片，直接存储到 OSS 的存储桶中。
- 数据库存引用：我们的数据库中只存储这张图片在 OSS 上的访问链接（URL），这是一段很短的文本。
引入 OSS 后的上传与读取流程，变得清晰且高效：
通过上面的时序图可以看到，在读取图片时（步骤 8），流量是直接在用户浏览器和 OSS 之间产生的，完全绕过了我们的应用服务器，极大地减轻了服务器的带宽压力。
四、 总结
对于程序员而言，OSS 并非什么高深莫测的技术。
从代码层面看，它就是一组配置（Endpoint、Bucket、AccessKey）和一个 SDK 调用。但从架构层面看，它实现了应用逻辑与静态资源的解耦。
它让应用服务器专注于处理业务逻辑（计算），让数据库专注于管理结构化数据（索引），而将笨重的文件存储和分发任务，交给了更专业、更廉价的 OSS。这就是为什么在现代 Web 开发中，OSS 几乎成为了标配。