程序员的自我救赎---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。或者扫描左侧二维码加群。