[得到大学课程作业] 如何设计云服务的计费策略?

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

  简单介绍一下,这个云服务主要用于对上千张表、上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,详细描述了计量计费模型的“设计哲学”。大家彼此完全独立思考,得出的方法论和最终模型却殊途同归,这很有趣。

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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.