分布式日志服务

分布式日志服务

日志为每一个开发人员都需要用到的功能，每一个开发人员都会写日志，都会用日志。单点应用的日志采用log4j就基本可以满足要求，但对于分布式架构，log4j就好像无法应对，那分布式架构下的日志有什么不同的需求呢？

日志需求

对于日志服务不论是单点应用还是分布式应用，需求基本都是一直的，这是我总结的几个需求：

1. 代码侵入低，业务中编写较少的代码就可以实现日志功能。
2. 性能高，日志记录性能要求较高，不能因为系统中增加日志而造成系统变慢。
3. 上下文汇总，可汇总同一上下文中产生的日志，编译进行问题跟踪。
4. 通用信息统一记录，对于调用方法、线程、上下文等信息统一进行记录。
5. 日志前后按照时间先后记录。

日志服务

Java开发经常会使用的日志工具时log4j组件。它提供了多种日志记录方式（文件、控制台、数据库、网络等），同时提供了丰富的扩展接口，以满足特殊的需求。对于单点应用，基本可以满足要求，然而从分布式角度就需要对其完善或者重新封装。

并发性能

控制台：性能高，但无法持久化
文本：性能高，但无法进行汇总
数据库：性能低，扩展性好
网络：性能较高，持久化存在瓶颈
高并发架构中，可以采用kafka消息队列进行缓存，采用大数据（如HBase）保存，同时可以方便的进行查询统计等。
并发不是很大时，可以采用独立的日志数据库，将日志分库分表进行存储，有利于进行日记汇总分析。

日志上下文

回头看看我们现有系统的日志记录方式。

• 将debug、info、error等记录在同一文本文件中，可以进行上下文梳理（通过线程信息），但不利于发现error问题。
• 将其记录在多个文件中，可以较为清晰的找到异常，上下文梳理很是不方便。
• 客户端与服务端没有一个RequestId打通，客户端问题到服务端日志进行问题确认时就成为一个难点。
  鉴于业务和架构的发展，分布式、微服务将逐渐融入到架构中，因为日志上下文链路将成为一个刚性需求。
  上下文链路需要将一次服务发起（例如客户端点击一次按钮），涉及多个服务能够形成一个链路。这与单点日志记录有大差距。，这需要在请求开始生成一个RequestId，将RequestId在客户端及服务端进行传递，实现现客户端与服务端、服务端各个服务之间打通。RequestId成为链路关键
  同时日志记录的内容也需要增加日志记录时的进程、服务器IP、服务类型等信息，丰富日志记录内容，为系统问题跟踪提供更多信息。

总结

分布式架构中日志记录对上下文链路的要求更高，但是虽然我们还没有进行分布式部署，一些理念还是可以借鉴的，一些封装也可以先行一步。