开发经验：已经有对象储存，为什么我们还要开发一个图片接口？

现在阿里云，腾讯云等等云服务商都已经提供对象储存服务，我们可以使用对象储存来存放文件或者图片。通过云服务商提供的 SDK，一行代码就可以把文件或者图片上传到对象储存，并获得文件的地址。

我的博客图片就使用腾讯云的对象储存作为图床，所以如果你查看图片的地址，会发现他们的网址是这样的：

https://kingname-1257411235.file.myqcloud.com/IMG_5551.JPEG

其中的https://kingname-1257411235.file.myqcloud.com/就是我的对象储存的域名。

然而，在公司的项目中，虽然我们也是用云服务商提供的对象储存来存放图片，但是我们会额外开发一个图片服务接口。所以，公司项目网站的图片，使用的地址类似于：https://img.kingname.info/xxx.png。当你访问这个地址的时候，这个图片服务会从域名拿到图片的名字xxx.png，然后访问对象储存拿到这张图片，最后再把这种图片以数据流的形式返回给你。

你可能会觉得，这不是多此一举吗？为什么不能让用户直接访问对象储存获得图片呢？单独做一个图片接口不仅增加了开发时间，而且还需要服务器单独再发一次请求到对象储存拿数据，白白增加了访问延迟，怎么看都是得不偿失啊。

这是因为，工程上的问题，有时候不仅仅是一个行与不行的问题。它需要考虑很多额外的因素。

迁移的成本

首先要考虑的一个问题是未来是否会更换云服务商。现在我用腾讯云的对象储存，我有一张图片的地址是https://kingname-1257411235.file.myqcloud.com/IMG_5551.JPEG，未来我要换到七牛云去了。图片文件我可以写个 Python 脚本，一键同步到新的对象储存里面去。但是我的图片地址应该怎么改？

对于新闻类网站或者 App 来说，新闻里面的图片一般都跟正文一起，以 HTML 代码的形式存放到数据库中了。如果我要迁移对象储存，岂不是要扫描一次数据库，把所有图片地址的前半截批量更新为新的地址？对整个数据库进行这样的更新是非常危险的，很容易导致数据损坏或者服务长时间停机。

但如果我们在对象储存上层有一个自己的图片服务，那么只需要更新图片服务内部的访问原始图片的逻辑就可以了。已有的新闻原始数据不需要做任何改动就能直接使用。

安全性考虑

如果使用对像储存，那么所有拿到图片地址的人都能够访问这张图片。假设我们有一篇新闻因为某种原因被删除了，用户已经不能访问这篇新闻了。但是之前拿到了这篇新闻图片的人，还可以通过对象储存对应的图片地址访问这张图片。这可能会被别有用心的人拿来利用，通过发送一篇不和谐的文章配上不和谐的图片，然后举报文章，发现文章被删除以后，再举报图片没有删除。

那可不可以删除新闻的同时把对应的原始图片也删除了呢？其实也不行。因为新闻一般是假删除。也就是在数据库中设置一个标注，让网站不再显示这篇新闻。例如一篇有版权争议的文章，收到原作者投诉以后，我们需要先把这篇文章撤下，然后商务会跟原作者沟通，获得授权以后再把文章重新打开。可是对象储存没有这样临时冻结图片的功能，删了就真的没有了。

但如果我们在对象储存上层加一个图片服务。用户访问图片的时候，我们先检查这张图片对应的新闻是否能够访问，如果能够访问，再去对象储存拉取图片返回给用户。这样就能降低被有心人利用的风险。

功能扩展性

对象储存提供文件存取功能外，还会提供一些简单的文件处理功能。但有时候我们需要一些自定义的功能，此时不得不再包装一层图片服务。

例如我们想在图片上加水印。对象储存提供的水印服务功能是在图片上传的时候直接修改原始图片文件，一旦添加就再也不能修改了。如果后面我想修改水印的内容，那么只能让新的图片使用新的水印，老的图片还是老的水印。

而如果我们有一个图片服务，那么可以在对象储存中直接存放原始图片。而图片服务拿到图片原文件以后，动态添加水印，再返回给调用者。这样一来，当我们要修改水印内容的时候，只需要修改图片服务接口就可以同步更新所有历史图片。

又比如，大家都知道最近因为棉花的事情，很多综艺节目突然出现了大面积的马赛克。因为有些赞助商的标志不能播放了。这可累死了这些节目的后期剪辑人员。新闻图片其实也会面临这种问题。但我们网站上有几千万篇新闻，显然我们不可能有人力去筛选每一篇新闻的图片。这个时候，我们只需要在图片服务中加上图片识别的功能，发现图片含有这些公司的商标，自动给图片加上高斯模糊。轻松解决问题。

总结

有一句话说得好，在计算机领域，没有什么问题是不能通过增加若干个中间层搞定的。在一些可能发生变故的地方，提前设置一些中间层，那么一开始可能仅仅只是简单的数据转发。但等到后面要对功能进行增强的时候，这些中间层往往能起到意想不到的作用。