oss项目服务器，云免服务器对接

我司是个初创小公司（产品比较单一，且，用户量只有3w+），还没有达到需要使用微服务架构的时候 (也没有足够的资源去支撑微服务架构)，但为了我司的技术团队走得更远，便在我到任后逐步步入功能模块拆分时代。

对接oss系统对于我司自营系统来说具有跨时代意义，毕竟是从外包手里将祖师爷级别的项目接手过来后“一步一个脚印”开始维护的。而今天分享的这篇“落地对接方案”文章是该服务包在我司小规模（三个自营系统）运用之后得到的一些经验积累，主要讲解的是整个对接方案流程以及几次方案更新迭代，但不涉及该服务包的日志存储与调用情况的分析、优化内容。(我司用的是阿里云oss产品，此文章中的一些配置、调用规则也来源于此，但不会涉及太多该产品的信息，如果您正在使用其他运营商的，可以只取思想精髓去整合市面上不同类型的资源存储系统)

不管是从技术意识还是资源成本上考虑，初创公司一般都不会专门抽出人力去落地统一的对外接洽第三方功能的服务包（而是采用“做一个项目、耦合一次第三方服务”的方式），主要原因不外乎三个字“用不着”，即“快速产生项目并部署上线是第一要务”。那么，为何我执意制定并落地这套oss对接方案呢？原因如下：

1. 我司已经从外包手里接过项目并且已经组建技术团队，可以预见的是：不久的将来，项目的可用性与稳定性逐渐替代“从0变为1”的需求，此时，技术团队应该开始展现其技术实力；另外，在行业中摸爬滚打了这么多年之后，慢慢意识到：要做好一个系统，必须考虑到以下几方面：便捷、安全、成本、扩展。其中，便捷性和扩展性更多涉及的是：公司内部技术架构设计上是否能做到统一管理服务模块。

说到统一管理，那么传统的上传到服务器的方式或将第三方存储系统直接耦合到应用系统的方案就必须淘汰出局—因为无法做到统一管理，必将导致许多让人抓狂的重复性开发、更新、测试等“吃力不讨好”的无用功，且一旦有更新，应用系统稳定性影响面大。如果采用“统一进出口”方案，不仅可以统一进行安全性检查、记录日志、访问统计等，减轻维护文件资源管理代码的难度，对用户的请求更好地进行控制，程序可读性更高、更容易维护，相对产生更少的bug和安全漏洞，更可以将功能“分而治之”，开发、更新、测试比较集中，理论上，只要确保进出口参数没有任何改动，当这个对接第三方的服务包进行更新迭代或新功能扩展后，其他应用系统都不会有任何感知；（特别是该服务包的依赖有更新且不得不升级时，统一管理的优势就会十分明显）

同时，我司在未来的规划里有很多想法需要去建立不同的系统来支撑，那么从技术上来说，能节省一次重复开发是再好不过的事情了；

2. 确保自营应用系统稳定、可用，即“应用服务器一般只用于执行操作而不做资源存储容器”。

不管你的服务器磁盘容量多大，不管你如何控制用户上传资源的大小、也不管你会不会记得定时扩容，总有一天磁盘容量会被使用完、应用系统因此崩溃（我司最近就出了这么一个事故：系统原来采用的资源上传路径是“前端->后端（中转且将内容存储下来）->oss服务器”，由于该路径中一直把资源存储在服务器上，一年下来，就把几百G的磁盘容量塞满了，而后用户先是感知到无法发布作品，接着因无法写入系统文件日志而至整站崩溃）；

再者，为了可用性，从业务需求上来说，技术人员也会被促使着去发掘更有前景、稳定的技术来实现一些功能，毕竟无论公司规模多大、公司是否有钱、技术实力如何，产品经理都会产出一些对标市场的业务需求，而我们身为技术打工人，怎么能说“不”？！在我的职业生涯里，上传资源经历了三个阶段：

1. 前端->后端（应用服务器）：该方案一般出现在单系统中，“被开发人员广泛熟知&开发便捷性”是其优势，毕竟几乎每一本“从入门到放弃”书籍的都会有那么一个uploadFile函数，初入行业的技术人员首先都会写这个函数，就像都会“hello world”一样；当然，其劣势也比较明显：上传能力受到应用服务器配置的限制&应用服务器磁盘被占满后导致应用服务不可用；
2. 前端->后端->资源服务器/资源存储系统（比如oss）：该方案出现契机一般为，技术人员意识到了“服务器不能做资源存储容器”，但碍于“前后端未分离，或，整个技术团队没有负责人设计方案”等原因并没有彻底优化该功能模块，最终导致：虽然去除了应用服务器磁盘被占满带来的隐患，却依然对资源服务器的带宽成本提出着高要求；
3. 前端->资源服务器/资源存储系统（比如oss）&资源服务器/资源存储系统（比如oss）与后端进行数据交互：直接将应用服务器的限制去除（由于1、2两种方案中上传路径经过了后端应用服务器，在确保能上传且前端等待时间不那么长的情况下，单个服务器下，5M真的是一个很友好的数字，但产品经理开口就要200M、甚至有领导开口就是500M）

小tips，那么什么场景下的资源可以直接存储在服务器呢？答案是：可以定时删除的资源，比如我在工作中遇到过的一个场景：活动（定时开始、定时结束）需要生成海报的，从oss上实时拉取较大图片资源并绘图会耗时间（之所以用后端绘图，是因为海报在PC、小程序、公众号都要进行使用，如果让前端绘制会需要三端开发成本），所以将用户头像、活动banner等图片在服务器本地多备份了一份，之后再使用脚本定时将到期/下架活动的资源进行删除

3. 降低云服务器负载和成本，实现动静分离、成本可控，即“将网站的一些静态资源的海量文件存储在更低单价、实时扩容的存储类型上，并借助第三方的加速传输、CDN、图片处理、媒体转码等数据处理方案快速地实现一些比较费时费力的功能”（比如，视频截帧），毕竟，“大幅度节省研发、运维成本”是很多小公司去选择第三方服务运维公司的最大理由；

4. 借助第三方力量来维护公司资源安全，市面上成熟的oss系统，整合了防盗链、加密、灾备等托底安全机制，只要你按照文档正确完成配置即可轻松防止静态资源泄漏（很多时候，应用系统会需要用户传一些敏感信息的图片内容，那么加密存储就变得很有必要，毕竟谁都不想毁在“数据泄漏”上）；

小tips：关于视频截帧，真的是我使用了资源存储系统之后得到的最大便利。我司有个功能是在用户上传视频后在页面上展示出视频第一帧的图像，（因为当时缺人手，我也写vue前端）我用了很多前端的代码都没有兼容好我们部门的所有手机，直到我翻了翻oss的资源处理文档，真的是几分钟搞定了（在数据信息返回时把第一帧图像地址也返回来即可）

以上便是身处在迷你小公司的我极力将oss服务模块分离出来的原因，接下来的一篇文章中，我将阐述“前端->资源服务器/资源存储系统（比如oss）&资源服务器/资源存储系统（比如oss）与后端进行数据交互”方案的制定与优化版本。