设计模式在一个系统架构中的应用

特征行为一:A页面点击一个按钮跳到B页面,然后在B页面点击一个链接跳到C页面,然后在C页面点击下载。

两个特征最后都在C页面下载软件,现在需要统计A-B-C-下载和D-E-C-下载这两种行为的分布(页面的访问时间,人数等),帮助运营更好的运营网站,这个有点类似AB测试,当然特征不止这两种,另外网站目前大约在20万UV,将来可能扩展到500万-1000万的UV,如何构建这个这个采集系统。

       但是要考虑到一个问题,如果这个网站有100个页面,每个页面有3个按钮。那么这种组合将会是100*100*3=30000种组合(这个只是两个页面的组合,不算多个页面的组合,当然运营也不会要求30000种组合的统计数据,他们也看不过来),用程序来维护这些组合且不说系统的设计将会有多复杂,就完成这种组合的解析工作将是一个巨大的工作量,有没有什么好的办法呢。

来源页  当前页  动作

    A1    //PX表示未知页,PA表示A页,A1表示点击动作1
   
A2
   
A3

我们来分析一下这组数据来源页可以看成一个可变量A,当前页看作是可变量B  动作可以看成是可变量C,这样一来就有了三个可变量(其实就是可变量分析),这可以就可以完全套用经典的设计模式中的桥模式来设计这个系统。我们只需要记录每次点击的来源页,当前页和动作就完全可以分析出来我们想要的用户行为轨迹。

       下面在这个是程序设计上的架构,接下来就是系统架构。看以下系统结构图





由于预测将来将会有有500-1000万UV,所以需要将采集服务器设计成可横向扩展的,所有的采集数据文本将在分析服务器上汇总,目前由于数据较少,大约每天产生1G数据,单个分析服务器完全可以胜任,如果以后业务量增加,可以轻松部署hadoopp来做分析,最后数据库基本上不会有什么压力,因为经过处理的数据放入数据库之后只有很少一部分,可以看看扩展之后的整个系统结构。


还是有点有规模的,整个设计在业务和硬件上的扩展都是很灵活的,拿出来分享一下,也希望大家在各自的应用中能够更多的使用设计模式来将系统设计得更加灵活。

猜你喜欢

转载自coffeehc.iteye.com/blog/1066953