不仅游戏，所有提供虚拟产品的场合都需要应用“造物者”思维模型，制衡各方利益，引导体系演进。我曾负责设计过一个复杂云服务产品的计费策略，深有体会。

　　简单介绍一下，这个云服务主要用于对上千张表、上P的数据进行复杂的计算。典型的一次计算任务，往往占用上万节点几十个小时，说耗费的存储、计算和下载流量成本超过几十万元。麻烦在于，系统不是独占的，往往有上百个用户的不同计算任务混在一起。

　　如何计费？常规思路往往从技术实现角度拆分，把一次计算任务占用的进程、内存，以及中间IO交换的数字都拿出来，分摊到对应的CPU、内存、网络设备和磁盘的折旧成本去。然后再加上一定的利润率。

　　然而，想深一点的话，这种计费策略并不好：

　　1> 从用户角度看：“运行时间”这个变量用户失去控制。海量数据的分布式计算有特殊之处：很可能第一次运行用10分钟，重跑一下，调度到另一个节点，就用了12分钟。相同的计算任务，有时收1块，有时收1.2块，用户疯掉了。

　　2> 从平台角度看：如果技术团队优化了底层系统，把计算速度加快1倍，收入就少了50%。这会让平台方丧失优化动力。

　　于是退回原点，先定义什么是好的计费策略：

　　1. 基于统计，简单可解释：基于统计；尽量简化；输入参数用户可控；

　　2. 可预期，可重复：实际运行前就能算出花费；同样的任务重跑，价格不变；

　　3. 正引导性：各个角色做好事（优化自己的代码）不受惩罚，最好获得奖励。

　　一个例子是手机话费：两个人面对面手机通话，与一个在城南一个在城北通话，实际成本肯定不一样。如果运营商按照通信链路经过了几个路由器、几次转发来计费，用户就晕倒了。所以手机计费策略采用阶梯的、区域的、分时的模型，符合上面3条原则。

　　最终的计费模型主要由“输入数据量 * 复杂度”组成，其中“复杂度”是一个简单的阶梯表，完全取决于用户计算作业的难易程度。（更多参考 http://wangleheng.com/2014/07/odps_meter_money/）

　　几乎同时，谷歌公司推出了同类产品Google BigQuery，计费方案和我们几乎一样。他们甚至在官网上贴了一篇BLOG，详细描述了计量计费模型的“设计哲学”。大家彼此完全独立思考，得出的方法论和最终模型却殊途同归，这很有趣。

　　总而言之，无论是复杂云服务、电子商务平台……都需要谨慎设计利益策略：尽可能简化规则，保证统计公平性，对“好事”建立正反馈。必要时，不妨参考经典电信服务的计量计费策略。