pingback系统的进化

所有的项目,只要到一定级别 都会涉及到此问题,它用来收集用户操作行为,统计用户的焦点点击,以及测试page到达率,相关业务的转化率等有着最重要的指标。公司都是根据此数据来做出决策,其实高层作出决策的最重要依据,也受各大领导关注最多的东西,重要性不多说。
现在,我想总结一下在我经历的过程中这个不是系统的东西变成系统的过程。
1.在APP 3.0版本之前 ,后端,前端都是发送最重要的统计数据,其只想当于一个上传接口,将一段json串串给后端,在VC中我门通过AFNetwork,ASI 直接去网络请求,没有架构,没有耦合,完全case to case处理 ,遇到一个处理一个

2.在APP 4.0版本 我们将这个单独出来成为一个库开出来几个接口,大家传入一些参数,然后这个模块来处理 缓存,上传时机 ,批处理等各种策略。这个时候的APP业务还是比较单一,相对来说 1.0 可以耦合复用 拉出来为库即可。

3.在APP5.0版本 整个移动业务 各个公司都受够了APP版本迭代慢的问题,开始出现平台化架构模式来满足千变万化的运营需求,内容编辑需求,甚至广告展示需求,在一个page内可以配置出尽量多的模版。由后端来决定前段展示的样式,这也就造就了要统计的东西爆发性的增长,由于页面都是动态的配置所以,所以发送时机需求的实时化 统计参数的直线增长,使得原有的接口已经完全无法适应当前的需求,那么重构随之而来。
这次重构主要解决两个问题:
1.发送时机可控制
2.demol依托后端数据结构,即后端可控
3.如何平滑过渡旧版本
4.性能

解决了此问题,感觉以后再也不用折腾了,然而变化太快了。

4.在6.0版本,伴随着公司收购,伴随着各个赚钱的业务均整合到移动端,随之而来的 统计系统有3到4个系统(各个业务以前都有自己的独立统计),初始的时候,各个业务都是以库的形势加入,这样能快速整合进工程享受基线带来巨大流量变现,但是随着业务加入的增多,导致工程中集合的统计库都有N个,并且各种发送时机,导致包一下大让人惊人,并且有些第三方库竟然重复N边,随着老大的强硬,这次整合也在所难免,这次重构主要解决的问题是:
1.整合各个业务线的统计系统,以后规整成一个
2.基线所有统计的库去重,
3.各个业务可自定义参数
4.提供改变固定参数接口,以适应特殊业务需求改变固定参数的需要。
5.提供平滑过渡方案。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 173,640评论 25 708
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 135,009评论 19 139
  • 自从罗胖提出了“国民总时间”这个概念,最近“时间管理”之类的词汇又不断地冒出来了。李笑来老师专门写过一本书——《把...
    胆小的鳄鱼阅读 248评论 2 2
  • 各位战友下午好,我是31班的张养浩,这次活动的筹办者之一。很荣幸参加这次活动的组织以及被邀请作为活动嘉宾。欢迎大家...
    成长浩阅读 560评论 2 6
  • 小明没有爸爸,他妈妈也从不提起爸爸。 但小明知道,爸爸在路上堵车,爸爸回不来了,他已经堵在路上 10 年了。 小明...
    灯下鼠阅读 898评论 13 11