方案对比

大量的静态图像数据

一、 问题

1. 数据流量特征

通过App向各个微服务提交的业务数据中，通常会包含以下类型的现场照片：委托人、委托物品、交易凭据等。

• 每张原始照片的文件大小，大约在 1MB 上下。即便经过App压缩处理，每张照片的文件大小也会在 100KB 上下。
• 而与此同时上传的JSON格式的业务数据大小，通常在 1KB 上下。

二者相对比，静态图片数据平均占据业务数据通道的 99% 以上，而核心的业务数据平均只占据不足 1% 的业务数据通道。

2. 现有解决方案的缺陷

应用服务器的职责是接受提交的业务数据，经过处理后存入业务数据库。在此过程中需要大量的数据转换、运算等，因此对CPU、内存有较高的要求，而对网络带宽要求较低。
然而目前应用服务器需要同时处理业务和静态图像数据。导致以下3个问题：

• 浪费现有应用服务器的CPU和内存：工作时间段内网络带宽被大量占用的同时，无法发挥出计算优势，充分利用CPU和内存。这带来了单个服务器的极大浪费。
• 扩张成本增加10倍以上：由于无法发挥出计算优势，所以与完全发挥计算能力的应用服务器相比，需要10倍以上的目前的服务器才能处理同样的业务请求。这在业务扩张阶段，会带来大量额外的成本。
• 高成本地重复建设分布式对象存储基础设施：由于缺乏分布式对象存储的基础设施，所以业务扩张的同时，还需要面对静态数据分布式存储、访问的问题。而仅利用应用服务器的资源解决此类问题的性价比极低。

二、 解决方案

流量分流：图片等静态资源存储在OSS上，将访问图片的流量转向到OSS上，不仅减少因为占用大量带宽造成的服务器资源浪费，还可以减少存储和带宽上的投入。

现有的解决方案，同时发送几个图片请求就会将带宽占满，不仅影响图片响应速度，还可能会影响到核心数据，而且费用也非常高。

以一张大小为 150KB 的图片，磁盘空间40G为例，服务器带宽 10Mbps 为例 。发8张图片就会将带宽沾满。
根据阿里云的定价。

40G的磁盘价格为14元/月。10Mb带宽费用是472.5/月 ，每年所需费用（14+472.5）* 12 = 5838 元

将图片存储到阿里云OSS对象存储上，图片流量不会对应用服务的带宽多大的影响，而且对象存储的价格也十分的便宜。
同样以一张大小为 150KB 的图片，磁盘空间40G 为例 。

由于图片这样占用带宽较大的静态文件通过OSS读写，不占用服务器的带宽资源，使用4M带宽即可满足需求。4M带宽的费用是86.4元，一年的带宽费用为84.4*12 = 1036 元

使用OSS一年总共需要费用是1036+186.2 = 1222.2 元

一年节省的费用 5836-1222.2= 4613.8 元

三、对开发人员的影响

前端人员	后台人员	APP开发	系统维护	存储
现有方案	需要额外进行处理	文件上传	POST , BASE 64	分布式存储
阿里云OSS	URI后直接添加变量参数进行处理	仅需要图片的存储路径和文件名	SDK 并行/异步	无需其他额外工作
本地OSS(swift)	URI后直接添加变量参数进行处理	仅需要图片的存储路径和文件名	SDK 并行/异步	无需其他额外工作

• 前端人员: 现有方案，当前端需要对的图片进行处理时（例如，做缩略图，裁剪等），需要添加额外的功能来做处理。阿里云OSS存储自带图片处理的相关功能。使用本地OSS结合Nginx模块，也可以实现图片处理的相关功能
• 后台人员: 现有方案中，后台需要接收请求，并将图片存储到服务器中。而不论是在阿里云还是本地OSS不需要上传图片，尽需要知道图片的链接地址即可获得图片。
• APP开发: APP上需要将图片转成BASE64格式，并使用图片数据与业务数据打包上传。而在OSS的方案中，使用SDK，可以并行或者异步传输 图片和业务数据
• 系统维护:现有方案中，需要维护一个分部式存储，来存储图片。而OSS方案中，有OSS存储即可。

使用OSS存储方案，不仅减少由于带宽大量占用而造成的的资源浪费，同时降低了服务器对带宽的要求，从而节约了一定的成本。

配置请参考： http://www.jianshu.com/p/9195c4bcc7d6