[发明专利]一种对微服务架构的日志管理方法及系统

说明书

本发明内容公开了一种对微服务架构的日志管理方法及系统，包括如下步骤：S1、用户在每个主机的服务端创建用于记录日志的数据库；S2、每个主机的服务端之间通过配置的中间件相连接数据库；S3、用户在发送的业务请求，中间件拦截每一次请求，中间件解析业务处理请求的URL，判断URL是否在相对应的哈希表中进行处理；S4、在步骤S3上用户从步骤S1的数据库中读取需要展示或分析的日志。本发明其旨在通过中间件对日志进行同步采集，集中存储，支持日志分析和管理，避免被人为恶意关闭日志管理进程，安全性高。

技术领域

本发明内容涉及计算机技术领域，尤其涉及一种对微服务架构的日志管理方法及系统。

背景技术

随着互联网技术的发展，越来越多的微服务应用出现在日常生活中。一般，在服务划分过程中会将单体应用拆分为多个高内聚低耦合的小型服务，每个小型服务运行在独立进程中，这些小型服务即为微服务，且微服务的前端和后端由不同的团队开发和维护，服务间采用轻量级通信机制，独立自动部署，可以采用不同的语言及存储。已知微服务架构是一种架构模式和广泛使用软件架构，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP通信)，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等，其次相比较传统的单服务结构，微服务将大型复杂的应用拆分为多个功能相对独立的小服务进行协同工作，每个应用可进行独立开发、部署、升级，服务解耦，方便项目管理。

然而对于日志的采集与分析是微服务架构下的一个难题，传统的方式下，各服务的日志一般独立采集，这不利于日志的配置和检查。而日志是系统问题定位的重要手段，当系统发生故障的时候因为服务分散，排查的时候需要每一台机器每一个服务挨个查看日志，非常的不方便。为了解决微服务架构下日志管理的难题，现有的方式是通过维护一个独立的日志服务来实现日志的管理（见图1），例如非常流行的ELK（ELK是Elasticsearch、Logstash和Kibana三个单词的首字母缩写）日志采集分析系统。ELK的过程是使用logstash收集日志，之后将日志直接存储到Elasticsearch中，最后用户通过Kibana查询日志并展示（见图2），使用这种方式能够将日志集中到一起并提供统一的接口进行查询分析，logstash是日志采集的入口，服务端可以选择一种方式将日志输入到logstash中（文件方式、端口方式或者缓存方式等）。然而，这种方式比较复杂笨重，需要安装许多组件并启动独立的日志服务。另外，由于ELK是独立的服务，需要保证其安全性还需要额外一个守护程序来保证日志服务是正常工作的，这增加了整个系统的复杂性。因此可以看出其现有技术下存在如下缺陷：

第一，微服务本身无法解决日志同步采集，集中管理，导致微服务架构下通过日志定位问题，时间长效率低。

第二，引入独立的日志服务组件来解决微服务架构下的日志同步采集，并解决日志服务其他服务互相独立带来的安全隐患，方案复杂并给系统带来额外消耗。

为此，亟需要对现有技术作出改进。

发明内容

（一）发明目的

针对现有技术中的不足，本发明提供了一种对微服务架构的日志管理方法及系统，其旨在通过中间件对日志进行同步采集，集中存储，支持日志分析和管理，避免被人为恶意关闭日志管理进程，安全性高。

（二）技术方案

为了实现上述目的，本发明所采取的技术方案是：

一种对微服务架构的日志管理方法，包括如下步骤：

S1、用户在每个主机的服务端创建用于记录日志的数据库，数据库中字段包括时间、操作者ID、URL（网络地址）和操作详情，在服务端的数据库中创建一个哈希表，所述哈希表以URL为键，值为需要记录的日志格式和该次请求的信息，其中每个URL对应一个URL记录簿，时间、操作者ID和操作详情都收藏在URL记录簿中，哈希表中根据配置的key进行读取和解析用户发送的业务处理请求得到操作详情；