运行三年，日活百万的微服务数据分析架构

架构使用的语言知识

这几年数据分析迅速发展，我们也做了一个微数据分析工具。该产品已成功运行三年，满足日活百万的企业。产品结构很简单，用世上最简单的语言php，最普遍的数据库mysql，服务器可以选择apache也可以选择nginx，一切看你自己的喜好。

一、微服务架构图




整个流程图：
1、SDK上传数据到服务器，如果安装redis做缓存，数据会最先进到redis，然后定时抽取数据到DB服务器。有了redis可以大大提高并行数据处理能力。
2、数据库收集原始数据，存储过程将数据按照不同维度统计各个指标数据，同时将数据汇总表。
3、前台报表展示，实时报表、小时报表和天报表数据展示。最好做到读写分离。

二、功能架构




功能架构主要包括功能、角色和权限三部分。功能是企业服务，用户使用的每一个功能，就是企业的每一个服务。角色是用户操作的归类，功能与角色的对应关系及权限。了解系统架构的现状，从功能架构开始。

三、应用架构

应用架构的内容包括现有架构图、web应用现状和接口架构。其中，接口是应用层面的关键，它是程序之间交互的部分。
主要包括clientdata、usinglog、event和errorlog等接口。
SDK通过接口定时发送数据到后台。
应用架构罗列出前后端调用关系。

四、数据设计

两个数据库，大约一百张表。数据库的设计依赖业务数据，对业务数据归类，导致数据设计画出E_R图，数据设计完成，最终数据库设计就出来了。数据库只要早起设计的号，是可以做到易伸缩、易拆分的。统计类主要分为统计的维度，还有就是用户、设备、错误信息等。
1、数据处理能力
日活百万，启动次数大概两百万，事件数和页面访问量起码在三百到五百万之间，平均每小时数据量五十万。运行过程中，**客户数据量集中在早晚高峰。根据客户的特殊情况，会把一些任务安排在闲暇时间段，比如日任务、周任务、月任务等安排在零晨。
好的硬件配置是数据处理的好帮手，更大的内存更快的硬盘绝对可以让数据流快速执行。
2、数据清洗和读写分离
大量原始数据入库，这些数据处理之后就是垃圾数据了。当所有报表数据都统计之后并写入各个维度表之后，需要定时把这些数据清除掉。
前台报表展示数据跟存储分析数据库最好分开。

五、物理架构

微服务的物理架构需要的机器很少，一台机器也能跑起来。分析统计主要是数据处理能力要求很高，数据库服务器需要两台，web端需要一台足矣。多年运营结果是并发和数据库处理能力是统计分析的最大瓶颈。

六、继续优化的方向

1、数据读写分离，数据清洗。
2、并发量。

七、客户

客户最关心的数据：
每一个客户最关心的就是用户表，用户新增状况、用户活跃情况、用户留存情况。
不同的客户对用户要求不同，需要判断用户是否是刷机来的，用户跟设备号及用户ID（用户号码）之间的映射关系。
事件数据也是很重要的，关系转化率。
页面访问跟事件是同等重要。
错误数据可以检测应用存在的Bug。
不同的客户，不同的使用场景对指标会有不同需求。

更多精彩内容可以查看Cobub Razor官网博客www.cobub.com