一 背景
- 每个业务系统都需记录操作日志的共性,现状是每个业务系统都需要记录在自己的数据库中(如丛林系统操作日志),会存在重复建设问题。有些系统还没有操作日志,如专题、广告、配置系统等。
- 部分的业务系统操作记录数据量不算太大,但是记录是很有必要的,可以排查问题等。不排除以后会快速增长,如果还记录在自己业务系统的数据库里,必然会影响业务系统数据库的性能,存在稳定性的风险。
- 业务操作记录分散,无法进行统一的分析和管理,无法进一步的量化和优化,为提升业务效率提供数据依据。
二 目标
- 通过合理的存储层、service层、API层,解决操作记录的存储
- 提供公共平台,避免每个业务系统重复建设
- 支持多个业务系统的各自基于各自维度的查询
三 初步实现思路
1)参考COS组记录日志系统(基于文档的存储)
注:蓝色箭头表示写操作,红色箭头表示读操作
关键步骤:
- 业务系统调用API发送操作记录到日志服务Server
- Server将操作记录封装为MQ消息
- solr从消费消息,建立索引
- 业务系统通过Server查询solr返回查询结果
server承担的职责 |
|
client职责 |
|
solar职责 |
|
2)基于数据库的存储思路
(1)K-V形式存储(medis)
键值数据库总的来说就像个的哈希表。我们可以通过key来添加、查询或者删除数据,鉴于使用主键访问,所以会获得不错的性能及扩展性。 我们美团现有的medis集群可以支持基于这种类型数据库日志记录服务的开发。
但是也有缺陷:原因也很明显,Key-Value数据库中根本没有通过值查询的途径。日志需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。
(2)面向文档的数据库(mongodb)
面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元,是一系列数据项的集合。每个数据项都有一个名称与对应的值,值既可以是简单的数据类型,如字符串、数字和日期等;也可以是复杂的类型,如有序列表和关联对象。数据存储的最小单位是文档,同一个表中存储的文档属性可以是不同的,数据可以使用XML、JSON或者JSONB等多种形式存储。
优点:因为每个应用程序都有不同的日志信息,如专题系统,广告系统,丛林系统,配置系统等他们都有不同的日志信息。这种数据库并没有固定的模式,所以我们可以使用它储存不同的信息。我们记录各系统的操作日志的记录可以是JSON形式的数据进行存储。
缺点:我对mongodb 还不熟悉,对环境搭建和内存配置等有待学习
(3) 列存储数据库(Hbase)
列存储数据库将数据储存在列族中,一个列族存储经常被一起查询的相关数据。举个例子,如果我们有一个专题类,我们通常会一起查询他们的专题名称和上线城市。这种情况下,专题名称和上线城市就会被放入一个列族中,而其他上线时间、状态、类型等则在另一个列族中。
优点:我们移动后台又有现成的搭建好的Hbase环境, 很明显的优点就是,我们可以将数据储存在不同的列中,每个应用程序可以将信息写入自己的列族中。
缺点:在模型设计,我们根本不可能去预测它的所有的查询方式,特别是每个系统的查询维度,而一旦查询方式改变,我们就必须重新设计列族。会给后期查询模块增加工作量。
(4)关系型数据库(mysql)
优点:和当前使用的数据库一致,环境搭建容易,更简单粗暴的方法是我在每个应用平台(专题,广告,丛林等)都建个日志表。
缺点:表的结构变更,必须先定义数据结构类型
(5)我们的各业务系统作为client接入Cos组的业务日志记录平台(BORP)
优点:简单
缺点:跨组依赖别组的服务,排查问题极不方便。