浅谈摄影作品站的架构

背景

2011 年的时候拥有了人生第一部相机，喜欢上了摄影，坚持摄影拍片也有好几年了，积累了一些作品。

在 360 做图搜的时候萌生了要开发一个自己的摄影作品站的念头，开始动工是在 2015 年加入美团的时候，当时并不急着把网站做出来，光是在产品和技术设计上就花了不少时间，断断续续的开发直到 2018 年初网站才上线。

上线时整理这几年的摄影作品时才感觉能拿得出手的作品并不多，不过摄影作品以后会慢慢积累，毕竟摄影于我来说已经是不可或缺的兴趣爱好了。

概览

麻雀虽小，五脏俱全，虽是一个小的图片主题的网站，该有的后台服务都要有，像图床服务、评论等。除了看不到的后台服务，前端的交互体验也很重要，像是多端的适配等都需要仔细打磨体验。以下是摄影作品站的简单的架构图。

接下来我会展开来做简单的介绍。

图床

图床服务说专业点就是图片处理存储服务，之前在做 360 图搜的时候就得益于强大的图床服务，前端才能对各种布局场景使用合适尺寸的图片。摄影作品站的前端需要实现多端按屏幕尺寸自适应的动态布局，主要的一个挑战是图片的动态裁切服务。

如今常见的图床服务对于图片的动态裁切都是标配的功能了吧，一开始有考虑过使用各种云现成的图床服务，但是考虑到图片的版权，尤其是对于摄影作品裁切时的质量保障也是非常重要的。于是自己动手用 Node.js 实现了一个独立的图床服务，底层的服务基于 GraphicsMagick ，GM 有丰富的图片处理的底层 API，裁切功能只是其中之一。

Web 服务与存储

Web 服务只需要向前端 API 服务，没有涉及到页面模板渲染，所以 Node.js 框架直接选用了 Koa。

2015 年的时候 MongoDB 还是比较火的时候，对于当时的前端来说，如果 Web 服务使用了 Node.js，那么数据存储通常都会选 MongoDB，不得不说 MongoDB 对于前端来说更容易上手。

MongoDB 在摄影作品站中用来存储业务数据，中间加入了 Redis 来做 KV 缓存。在开发收尾的时候想起来应该要有一些统计数据的收集，于是又开心的用上了 MySQL。

不过多套存储方案提升了部署运维的成本，且统计数据是自己存储收集，对于数据的加工、聚合、清洗又是一个成本。这就是喜欢折腾的后果。

前端应用

对于需要多端自适应的图片站来说，天生适合做成单页应用，于是毫无悬念的的选用了 React，数据管理使用了之前自己开发的 Ballade ，且前端所有数据都是 Immutable 化的。

应用分成了两个版本，一个是 PC 版，一个是 Mobile 版，使用了相同的访问地址。不同的版本按照设备特性来做了交互体验优化，如果使用 Pad 设备访问也是 Mobile 版。

Mobile 版浏览大图的手势交互体验基本按照 iOS 默认的照片应用来的，不得不说在手势事件的细节打磨上很折腾人，好在我之前在开发 360 图搜的时候就已经积攒了一些经验。

除了面向直接用户的前台应用，还有面向管理员专用的的图片管理后台，所以前端实际上分成了 3 个应用。

其他

除了以上的服务和应用，摄影作品站在安全方面也做了一些限制。HTTPS 是基本前提，还有接口的非法访问限制，图片防盗链，评论过滤等安全措施。当然还有最简单粗暴的图片手动水印，不过也只能防君子防不了小人。

之后有机会再将其中一些部分展开来细讲，最后附上摄影作品站的 传送门 。