平台日志服务实现思路

一 背景

1. 每个业务系统都需记录操作日志的共性，现状是每个业务系统都需要记录在自己的数据库中（如丛林系统操作日志），会存在重复建设问题。有些系统还没有操作日志，如专题、广告、配置系统等。
2. 部分的业务系统操作记录数据量不算太大，但是记录是很有必要的，可以排查问题等。不排除以后会快速增长，如果还记录在自己业务系统的数据库里，必然会影响业务系统数据库的性能，存在稳定性的风险。
3. 业务操作记录分散，无法进行统一的分析和管理，无法进一步的量化和优化，为提升业务效率提供数据依据。

二 目标

1. 通过合理的存储层、service层、API层，解决操作记录的存储
2. 提供公共平台，避免每个业务系统重复建设
3. 支持多个业务系统的各自基于各自维度的查询

三 初步实现思路

1）参考COS组记录日志系统(基于文档的存储)

注：蓝色箭头表示写操作，红色箭头表示读操作

关键步骤：

1. 业务系统调用API发送操作记录到日志服务Server
2. Server将操作记录封装为MQ消息
3. solr从消费消息，建立索引
4. 业务系统通过Server查询solr返回查询结果

server承担的职责

所有插入信息应用都连接server，相当于一个写代理 所有查询信息应用都连接server，相当于一个读代理 承担mq到solr中消费消息的角色 server负责信息的接收，转发与接收，客户端只需要跟server进行交互

client职责

相当于将大部分client转移到server中 业务系统只需要通过普通api(http或thrift)与server交互

solar职责

消费日志记录，建立索引提供查询，Cos组这部分使用ES(ElasticSeach)，ElasticSearch是一个开源的分布式搜索引擎，具备高可靠性，像Solr一样，是基于Lucene构建的。假如采用基于文件索引的方式进行存储，因为我们组有过solr的使用经验，我们可以用 solr替代ES。

 

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）

优点：简单

缺点：跨组依赖别组的服务，排查问题极不方便。