基于架构合理性和保护数据安全的出发点,我们对如何基于七牛云存储服务开发提供一些设计和编码建议。希望开发者能够尽可能的在使用七牛云存储服务之前先详细阅读这些建议,并尽可能的符合这些原则,以免造成没必要的时间浪费甚至造成数据安全风险。
## 基本结构
基于七牛云存储服务构建的应用建议使用如下的基本架构:
![基本模型](http://developer.qiniu.com/docs/v6/api/overview/img/programming-model.png "基本模型")
从该结构图,我们可以看到以下这几个关键组件:
1. 七牛云存储服务
七牛云存储服务以KV(即Key-Value,参见[键值对](http://developer.qiniu.com/docs/v6/api/overview/concepts.html#key-value))方式提供的非结构化资源存储服务。向业务服务器提供资源管理服务,向客户端提供资源上传和下载服务。
2. 业务服务器
开发者需要自行管理和维护的一组业务服务器,负责提供至少这几个基本功能:
1. 生成各种安全凭证(参见[安全机制](security))。安全凭证的创建不能在分发给最终用户的客户端上进行,否则会产生极大的安全风险。
2. 使用关系型数据库(比如MySQL)管理用户帐号信息。最终用户信息的管理并非云存储服务的功能范畴。云存储服务只管理企业账号。
3. 使用数据库管理资源元数据和资源之间的映射关系。
4. 响应客户端的业务请求,执行业务流程并返回执行结果。
3. 客户端
客户端通常同时是资源的生产方和消费方。客户端在展示内容时,通常需要先从业务服务器获取资源的元信息,并得到必要的下载凭证,然后使用下载凭证从七牛云存储服务获取待展示的资源内容,从而实现一个完整的内容展示过程。
## 业务流程
关键的几个交互过程:
1. 上传
客户端在上传资源到云存储之前要先从业务服务器获取一个有效的上传凭证,因此需要先后和两个服务端打交道。
![基本上传流程](http://developer.qiniu.com/docs/v6/api/overview/img/basic-upload.png "基本上传流程")
如果有设置回调,则上传完成时七牛云存储会自动回调到指定的业务服务器。
![带回调的上传流程](http://developer.qiniu.com/docs/v6/api/overview/img/upload-with-callback.png "带回调的上传流程")
2. 下载
公开资源因为不需要对应的下载凭证即可访问,客户端可以直接从云存储下载对应资源。私有资源因为需要对应的下载凭证,因此必须先和业务服务器打交道。
按照实际的使用场景,客户端对于内容的展示非常类似于一个动态网页的生成过程,因此无论该页面内容是公开还是私有,均需要从业务服务器获取该展示页面的动态布局信息。所以通常显示过程也是需要先后和业务服务器及云存储服务打交道。
3. 资源管理
为了防止安全漏洞,资源管理动作只应在业务服务器端进行。如果允许客户端进行资源管理,即使将管理凭证的生成动作放到业务服务器端进行,仍然很容易被第三方截获请求全文,从而导致重放攻击的风险。
## 关键原则
这个模型的关键要点如下:
1. 整个架构中需要一个业务服务器的组件;
2. 无论如何,AccessKey/SecretKey均不得包含在客户端的分发包中,无论是二进制代码中、配置文件中,还是网页中;
3. SecretKey不得在任何场景中在公网上传输,更不得传输到客户端;
4. 业务服务器端应维持一个数据库,用于管理资源的元数据;
5. 业务服务器端应维持一个最终用户的账号信息数据库,因为七牛并不负责管理最终用户信息;
6. 原则上客户端和云存储的交互只应是上传和下载,不应使用任何其他的API;