程序员的自我救赎---11.4:FileSystem文件服务

《前言》

(一) Winner2.0 框架基础分析

(二)PLSQL报表系统

(三)SSO单点登录

(四) 短信中心与消息中心

(五)钱包系统

(六)GPU支付中心

(七)权限系统

(八)监控系统

(九)会员中心

(十) APP版本控制系统

(十一)Winner前端框架与RPC接口规范讲解

(十二)上层应用案例

(十三)总结

《FileSystem文件服务》

前面写了很多Winner2.0的文章,基本我都是以"首先,开始,最后" 这样的格式体去写,今天换种写法从根本需求上来写。

FileSystem文件服务,我想很多稍成熟一点互联网公司都有这么一个服务,专门用于上传文件尤其是图片,最常见的就是干商城的。

我们从需求的角度上来说是一个循循渐进的过程:

第一阶段单项目开发:

首先,我们开发一个“用户中心”的,用户需要上传身份证图片,银行卡图片,头像,这里就要开发上传图片。

再来,我们开发了一个“线上商城”,商家需要上传产品图片,这里不但要上传图片还要形成缩略图。

继续,为了提高性能我们给“用户中心”所在的A服务器开了CDN加速,于此同时我们也给“线上商城”所在的B服务器也开CDN。

最后,问题来了。我再增加第三个、第四个项目在文件管理这一块是否这样继续下去?是否每个项目自己去做缩略图?

如果可以共用的文件是否每个项目自己去存储?比如Logo、JS!

从用户角度来说,用户压根不会在乎这个商城是怎么实现的。但是程序员,架构师就要考虑了。所以我们开发了FileSystem文件服务

这里文件服务,和文件服务器是两个相似但不同的概念。

文件服务器:Windows的服务器自身可以直接配置成“文件服务器”,等于单拿一台服务器来做存储,期间可以通过各种Windows账户配置权限。

文件服务:只是一个应用,应用的功能有需求来转换成功能,比如根据调用方传入的Size生成缩略图等等。

一个是有是从物理硬件服务器的角度出发,一个是单纯的软件部署。

这时我们就来到了第二阶段:

FileSystem文件服务诞生了,主要包含功能有:

1,存储文件;

2,生成缩略图;

3,后台管理文件;

4,权限控制;

基本功能就这四样,但是解决了我们每个项目去建一个UpLoad文件夹,到头来每个项目目录都很庞大。

另外我还见过直接以流的方式将文件存出数据库的做法,当然这本身没有什么问题。只是在做数据搬迁等操作的时候就痛苦了。

其实应该应该直接进入第三阶段:

采购阿里云的文件服务OSS,阿里云也有文件服务器NAS。这里推荐使用OSS。我们公司虽然没有买文件服务器,但实质来说

单独拿出了一台1TB硬盘的服务器来做文件存储,这台服务器上就只部署了FileSystem这一个项目,其实本质来说就是做了文件服务器。

从成本考虑,买一台阿里云ECS的服务器稍微好一点的配置再加个大硬,价格就在八九千一年了。

直接买OSS或者NAS价格也便宜的多,关键提供的服务也很多,比如:精细化的权限控制、防盗链、容灾安全性,其实都比自建要好。

贴一张我们FileSystem的项目解决方案图:

这个项目是2013年开发的,所以是用Asp.net做的。这个项目由于功能简单,我们就一直没有去重构它,四五年这么下来一直停好用的。

这个项目我就不提供源码了,里面也没有太多思想、技术方面可以讲的。

有时间如果再架构大型项目的话,我还是偏向于直接使用阿里云的OSS来做存储服务。

写到这里吧,有兴趣一起探讨Winner框架的可以加我们QQ群:261083244。或者扫描左侧二维码加群。

时间: 2024-10-05 02:13:24

程序员的自我救赎---11.4:FileSystem文件服务的相关文章

程序员的自我救赎---11.3:WinService服务

<前言> (一) Winner2.0 框架基础分析 (二)PLSQL报表系统 (三)SSO单点登录 (四) 短信中心与消息中心 (五)钱包系统 (六)GPU支付中心 (七)权限系统 (八)监控系统 (九)会员中心 (十) APP版本控制系统 (十一)Winner前端框架与RPC接口规范讲解 (十二)上层应用案例 (十三)总结 <WinService服务> 说道Windows服务基本每个以.net为主要开发语言的技术团队都会用到这个,Winner2.0中对于WinServices也有

程序员的自我修养:(1)目标文件

程序员的自我修养:(1)目标文件 1.目标文件 1.1 编译与链接 在使用像Visual Studio或Qt Creator等IDE时,通常有一个叫做"构建"的按钮.当编辑完成要运行和测试时点一下它,程序就能跑起来了,所以我们很少关心编译和链接.其实,编译和链接合并在一起就称为 构建(Build).简单的一次按键,实际背后却是异常复杂的过程: 预编译(Preprocessing) 编译(Compilation) 扫描:算法类似有限状态机(FSM),将字符转换成Token. 语法分析:分

一个程序员的自我救赎

为了找一个能清晰表达我在2017年的状态词语,我搜索了不下百个词语还是未能找到一个贴切的形容,可想我这一年的状态该有多么的糟糕.既然无法汇总,只好通过文字来聚焦我的思绪把这混乱一层一层地剥离.观察和思考. 疲惫的身躯 我细数了一下2017到底有多少可以让我"精神抖擞"的日子,算下来可能也就只有那可怕的10天左右,如果用"智能手环"来表达的话,2017我可能只有10天左右的睡眠质量勉强能达到良好.这是一个往我焦虑感火上加油的数字,我觉得这个数字恰恰应该是一个"

程序员的自我救赎---1.4.2: 核心框架讲解(BLL&amp;Tool)

<前言> <目录> (一) Winner2.0 框架基础分析 (二) 短信中心 (三)SSO单点登录 (四)PLSQL报表系统 (五)钱包系统 (六)GPU支付中心 (七)权限系统 (八)监控系统 (九)会员中心 (十)消息中心 (十一)Winner前端框架与RPC接口规范讲解 (十二)上层应用案例 (十三)番外篇 <核心框架讲解> 之前想用一篇文章讲完核心框架的三四个程序集,后来写着写着就发现一篇文章写不完,这才想了一下用最少要用三篇. 上一篇讲了一下DAL,其实也没

程序员的自我救赎---1.2:代码生成器的使用

<前言> <目录> (一) Winner2.0 框架基础分析 (二) 短信中心 (三)SSO单点登录 (四)PLSQL报表系统 (五)钱包系统 (六)GPU支付中心 (七)权限系统 (八)监控系统 (九)会员中心 (十)消息中心 (十一)Winner前端框架与RPC接口规范讲解 (十二)上层应用案例 (十三)番外篇 <代码生成器的使用> 今天中午阿杰聊了会,阿杰说看了我写的博客后.发现一个问题,把Winner框架整理成文档,要把Winner框架的核心思想 给写出来,比如

程序员的自我救赎---1.1: 解决方案命分层规范

<目录> <Winner2.0框架解决方案命分层规范> 初学编程,难免要从Hello Word开始,学习Winner框架首先要知道如何建一个项目.有了第一个项目的框架结构就知道如何施展自己的"增删查改". Winner框架 依然遵从MVC模式,这里我就不去赘述什么是MVC. 数据层:以"项目名.DataAcces"命名,例如:  Shop.DataAccess: 实体层:以"项目名.Entities" 命名    例如:

程序员的自我救赎---1.4.1: 核心框架讲解(DAL)

<前言> <目录> (一) Winner2.0 框架基础分析 (二) 短信中心 (三)SSO单点登录 (四)PLSQL报表系统 (五)钱包系统 (六)GPU支付中心 (七)权限系统 (八)监控系统 (九)会员中心 (十)消息中心 (十一)Winner前端框架与RPC接口规范讲解 (十二)上层应用案例 (十三)番外篇 <核心框架讲解> 之前在<Winner2.0框架解决方案命分层规范> 有讲到过Winner框架最重要的三个程序集分别是: Winner.Fram

程序员的自我救赎---3.1:理解Oauth2.0

<前言> (一) Winner2.0 框架基础分析 (二)PLSQL报表系统 (三)SSO单点登录 (四) 短信中心与消息中心 (五)钱包系统 (六)GPU支付中心 (七)权限系统 (八)监控系统 (九)会员中心 (十) APP版本控制系统 (十一)Winner前端框架与RPC接口规范讲解 (十二)上层应用案例 (十三)总结 <理解Oauth2.0> 关于SSO分两个篇章来讲,先讲讲Oauth2.0,之前还特地百度了一下Oauth怎么读,我们每次交流的时候都直接读字母O·A·U·T

程序员的自我救赎---2.1:报表系统项目分析

<前言> <目录> (一) Winner2.0 框架基础分析 (二)PLSQL报表系统 (三)SSO单点登录 (四) 短信中心 (五)钱包系统 (六)GPU支付中心 (七)权限系统 (八)监控系统 (九)会员中心 (十)消息中心 (十一)Winner前端框架与RPC接口规范讲解 (十二)上层应用案例 (十三)番外篇 <报表系统项目分析> “报表系统”顾名思义是用来做报表用的,但是在Winner当中报表系统经常被我们用来当作网页版的PL/SQL来使用. 不用Oralce的