做网站需要用到的符号语言网站建设的进度安排和人员安排

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