游戏渠道打包业务架构图
主要痛点
产品流量限制
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数量。