程序员的自我救赎---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的项目解决方案图:

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

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

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

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

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

上一篇:从浏览器启动应用程序 - Application URL


下一篇:Python 异常处理