手机游戏平台中的消费系统设计（一）
缘由
最近在研究苹果的In-App Purchase和谷歌的In-App Billing方面有一些心得，可以来分享。
事情的缘由于一个手机游戏平台的搭建，作为平台的话，投入商品并能够购买是必不可少的功能。如果是单一的手机游戏，大可直接采用IAP或者IAB，把商品信息写在程序内，简单的通过客户端和苹果/谷歌的服务之间的通讯完成商品的购买与内容的赋予功能。只需要事先在苹果/谷歌的系统中登陆商品的信息，包括作为商品表示的ID字符串，多少钱以及商品的说明，再在代码中写上成功购买了对于商品之后的动作即可。
但是作为一个游戏平台必须要考虑很多事情：
- 同一款App在iOS和android平台上同时发布的时候，商品信息能够简单的设计与更新
- 对商品的购买期限，购买数量以及其他的地方能够做出限制（比如每天购买两次，比如第一次购买的时候有优惠等等）
- 商品的购买能够采用IAP/IAB的方式来完成，内容的赋予不是通过客户端，而是通过服务器来完成。这样服务器就能完成更多除了内容赋予的功能，比如扭蛋抽奖功能
- 平台能够记录各个商品的购入历史以便于销售分析
实际上在IAP/IAB的开发者文档里面，是建议内容的发布由服务器来完成的，只是由于服务器本身的开发需要成本，对小且块需求的游戏来说是个巨大的开销。
这样的平台想起来可能会很容易做，但实际做出来却不是那么的容易。
试想一下，如果是IAP的方式，通过以下的步骤似乎可以完成这样的事情:
- 通过iTunes登录商品信息
- App购买完商品之后，发请求到服务器
- 服务器完成玩家的内容赋予，并通知App
- App收到通知后删除此购买的事务
但是这样的系统有以下几点做不到：
- 服务器严格控制商品的购买（购买期间以及购买数量等等）
- 通讯故障之后的恢复工作（比如某段时间通讯中断了，通讯恢复之后怎样继续未完成的工作）
下面介绍两种设计的方式。
虚拟货币方式
做这样的设想：如果从IAP/IAB平台上的购买仅仅局限于虚拟货币，具体游戏中商品的购买必须由虚拟货币的购买来完成。
那么事情就简单很多，首先IAP/IAB的购入没有必要做时间和数量的限制，应为是游戏的虚拟货币。 具体的商品的严格购买控制只是App和游戏服务器之间的交易，与IAP/IAB已经没有任何关系。这就与一般平台的购入一致，大致的设计思想有下面这些：
- 服务器上登录商品的具体信息，以及购买之后获得的内容
- 服务器上维护一个赋予给用户的内容的队列
- 服务器通过发放事务来控制商品的购买
- 每个用户每个商品只允许存在一个开放的事务
具体的App和服务器之间的序列图大致为以下：
在这里事务的发放似乎没有必要。在这里写上是因为，大部分公司的财务系统都是一个单独的系统，有公司内部的专用网络访问。服务器与财务系统的联系，财务系统的购买的产生，需要事务。
在这样的设计中，以下的问题可以简单的避免：
- 多用户多个客户端同时登录的时候，是否会打破购买数的限制？不能
- 用户是否能够购买超过时间限制的商品？不能
简评
作为一个简单的平台来说这样的设计无疑是最为简单方便的设计，但是对于一个大型综合性的平台来说，没有必要强制所有的游戏必须拥有游戏的虚拟货币。于是基于IAP、IAB直接购买商品的需求应运而生。