游戏分发市场打包OSS-UDF改造方案

游戏渠道打包业务架构图

主要痛点

产品流量限制

ECS内网限流500M，打包集群用8台ECS、合计4Gbps的带宽峰值，在打包业务峰值时也不够处理，继续扩展ECS又会达到OSS的单用户吞吐量上限，业务进一步扩展遇到瓶颈。

存储成本

分发市场一般会对接上千个渠道，一款爆款游戏需要打上百个渠道包，所以存储量百倍提升，成本压力较大。

OSS-UDF方案

OSS-UDF(（User Defined Function）)是OSS团队针对存储内容有轻量计算需求所提供的产品化解决方案。

UDF程序是一个运行在OSS服务器端的用户自定义的处理程序，OSS在收到用户的UDF请求后，会转发给用户的UDF程序，对存储内容进行诸如解压、转码、图像处理等处理，并在处理完成后将结果返回给用户。

使用UDF，必须按照OSS的UDF协议来开发UDF程序、并将UDF程序托管到OSS；包括UDF程序的规范、托管方法、客户端调用规范。

利用UDF改造渠道打包系统

1 以熟悉的编程语言开发好UDF程序，假设叫做BuildChannel，该程序需要监听9000端口，能够接收HTTP POST请求，内容是对一个原始的游戏包做渠道包打包操作（新型的渠道包打包基本是在原始渠道包文件后attatch一段渠道信息）

2 通过一个YAML格式的文件，用户配置OSS安装必要的依赖，最终BuildChannel要能直接运行于Ubuntu 14.04。

3 注册BuildChannel,后续控制台会开放标准注册页面和API，当前阶段线下配置；

4 客户端根据UDF协议调用，获取渠道YYY包的调用形式如下（其中jsonParaYYY是json组装的YYY渠道包必要信息）： 

GET http://bucketName.oss-cn-hangzhou.aliyuncs.com/game.apk?x-oss-process=udf/BuildChannel,jsonParaYYY

5 OSS接到调用，将UDF请求解析出来POST给UDF程序，处理完成后，OSS调用将直接返回打好渠道信息的安装包

改造方案解析

UDF只适合对单体资源对象做简单处理的场景，因为UDF的调用时间包含在OSS调用的返回时间内，如果需要较长时间（涉及复杂计算场景、批量资源）的调用不合适使用UDF。

绝大部分数量的游戏包只用存储1份原始包、以及少量不能用UDF构建的渠道包，存储空间比起全部静态打包的方式，缩减到1/N，极好替用户节省了成本。可以有效减少打包服务器ECS数量。