最近参与一个CPC广告的开发项目，所谓CPC就是按点击收费，其最早产生于搜索广告，并很快为大多数效果类广告所普遍采用。在这种计费方式下点击率有供给方统计，点击价值的估计由需求方（商家）完成，并通过点击出价的方式向市场发布自己的估价。这种方式首先是保障平台的利益，当然对广告主的利益也有兼顾；具体的定价策略是按照GSP的用户竞价方式来确定，以达到充分刺激广告主竞争意识，从而更好保障平台利益，当然GSP竞价方式也能较好的保障广告主的利益，也是广告主乐意接受的竞价方式，GSP具体竞价原理在此就不赘述了。
整个项目涉及的部门很多，包括B端、C端、M端、D端、F端，因为这是一个从商家到用户的完整的业务流程，所以流程很长，涉及的部门很多。不多啰嗦了，先展示总体业务架构：
先介绍下整体的业务分工，上面的绿色和蓝色属于B端（商家端，负责商家交互），最左侧两个显眼的模块为M端（负责管理商家信息及财务数据），红色的为D端（负责CPC核心业务），最下面的就是C端了，当然用户与商家都是F端（前段）的功能上操作了。
现在来具体讲下整个业务流程，首先通过初步筛选的商家（M端商家系统中完成注册的）发起cpc签约申请，经过运维人员审核通过后，可以发起投放计划；当然在这之前用户需要通过“账户管理”完成充值（退款）操作，这是通过“账户管理”模块完成与M端结算系统的交互功能，交易记录会在B端的DB中进行存储；商家可以设置自己投放计划，通过“投放管理”功能存储在DB中，并同步到D端，用来作为D端完成竞价排名以及商家投放状态判断的参考数据，这是商家端的交互情况。
至于用户方面，是C端接收用户点击后，会完成两个步骤，一个是竞价排名操作，另一个是计费操作。首先，用户的点击操作会进入自然排序，自然排序会对竞价系统发出请求，获取有效的竞价排名数据，将其与自然排序进行混排，按照确定的规则生成最终展示给C端的排名数据，在app上展示；与此同时会对点击进行计费，当然，并不是对所有点击都进行计费，其中会经过反作弊模块，过滤掉无效或恶意点击，从而最大程度保障商家利益，最终有效的点击会在charge中进行计费，并同步到B端结算服务，用来作为B端对商家操作有效性进行粗略评估；由于点击计费数据量太大，如果直接结算会生成大量流水，对M端压力太大，所以费用不会实时结算，而是在每日的固定时间以charge的计费作为标准进行结算，M端结算完成后，再将账户信息全量同步给各需求方。
这其中涉及很多细节，比如端与端之间的增量同步使用mq进行交互，以降低耦合，也可降低对各端的压力，使各端可以按照各自的步调进行消费；全量的执行计划以及账户信息数据同步使用RPC来进行操作，保证数据的实时准确。
这基本上就是整个cpc服务的主要框架流程，有些功能还不太完善，后续功能开发成熟后，再进行补充。
