一种对微服务架构的日志管理方法及系统技术方案

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

【技术实现步骤摘要】
一种对微服务架构的日志管理方法及系统


[0001]本
技术实现思路
涉及计算机
，尤其涉及一种对微服务架构的日志管理方法及系统。

技术介绍

[0002]随着互联网技术的发展，越来越多的微服务应用出现在日常生活中。一般，在服务划分过程中会将单体应用拆分为多个高内聚低耦合的小型服务，每个小型服务运行在独立进程中，这些小型服务即为微服务，且微服务的前端和后端由不同的团队开发和维护，服务间采用轻量级通信机制，独立自动部署，可以采用不同的语言及存储。已知微服务架构是一种架构模式和广泛使用软件架构，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP通信)，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等，其次相比较传统的单服务结构，微服务将大型复杂的应用拆分为多个功能相对独立的小服务进行协同工作，每个应用可进行独立开发、部署、升级，服务解耦，方便项目管理。
[0003]然而对于日志的采集与分析是微服务架构下的一个难题，传统的方式下，各服务的日志一般独立采集，这不利于日志的配置和检查。而日志是系统问题定位的重要手段，当系统发生故障的时候因为服务分散，排查的时候需要每一台机器每一个服务挨个查看日志，非常的不方便。为了解决微服务架构下日志管理的难题，现有的方式是通过维护一个独立的日志服务来实现日志的管理（见图1），例如非常流行的ELK（ELK是Elasticsearch、Logstash和Kibana三个单词的首字母缩写）日志采集分析系统。ELK的过程是使用logstash收集日志，之后将日志直接存储到Elasticsearch中，最后用户通过Kibana查询日志并展示（见图2），使用这种方式能够将日志集中到一起并提供统一的接口进行查询分析，logstash是日志采集的入口，服务端可以选择一种方式将日志输入到logstash中（文件方式、端口方式或者缓存方式等）。然而，这种方式比较复杂笨重，需要安装许多组件并启动独立的日志服务。另外，由于ELK是独立的服务，需要保证其安全性还需要额外一个守护程序来保证日志服务是正常工作的，这增加了整个系统的复杂性。因此可以看出其现有技术下存在如下缺陷：第一，微服务本身无法解决日志同步采集，集中管理，导致微服务架构下通过日志定位问题，时间长效率低。
[0004]第二，引入独立的日志服务组件来解决微服务架构下的日志同步采集，并解决日志服务其他服务互相独立带来的安全隐患，方案复杂并给系统带来额外消耗。
[0005]为此，亟需要对现有技术作出改进。

技术实现思路

[0006]（一）专利技术目的
针对现有技术中的不足，本专利技术提供了一种对微服务架构的日志管理方法及系统，其旨在通过中间件对日志进行同步采集，集中存储，支持日志分析和管理，避免被人为恶意关闭日志管理进程，安全性高。
[0007]（二）技术方案为了实现上述目的，本专利技术所采取的技术方案是：一种对微服务架构的日志管理方法，包括如下步骤：S1、用户在每个主机的服务端创建用于记录日志的数据库，数据库中字段包括时间、操作者ID、URL（网络地址）和操作详情，在服务端的数据库中创建一个哈希表，所述哈希表以URL为键，值为需要记录的日志格式和该次请求的信息，其中每个URL对应一个URL记录簿，时间、操作者ID和操作详情都收藏在URL记录簿中，哈希表中根据配置的key进行读取和解析用户发送的业务处理请求得到操作详情；S2、每个主机的服务端之间通过配置的中间件相连接数据库；S3、用户在发送的业务请求，中间件拦截每一次请求，中间件解析业务处理请求的URL，判断URL是否在相对应的哈希表中，若不在，不做任何处理，则响应用户发送的业务处理请求进行反馈给用户，若在，则哈希表根据URL配置的key，读取该次请求相应的信息，并将读取的信息填充到日志格式的占位中得到操作详情，最终记录到URL相对应的URL记录簿中，URL记录簿存储于数据库中；S4、在步骤S3上用户从步骤S1的数据库中读取需要展示或分析的日志。
[0008]进一步说，在所述步骤S3中还包括如需出现新的URL记录日志，则需要在步骤S1中哈希表中增加相对应的URL记录本，完成后，在用户发送业务处理请求时，URL记录本会记录被请求。
[0009]进一步说，所述步骤S1中哈希表的格式如下：{'some_url
’
: {
‘
format
’
:
ꢀ’
{}一些描述{}
’
,
‘
key
’
: [
‘
key1
’
,
ꢀ‘
key2
’
]}}其中
’
some_url
’
表示URL，为哈希表的键，每一个URL对应了一个format和key，其中format为日志的格式，key为要从请求中读取的信息，其中format中的“{}”为占位符，它们将被读取到的key信息所填充，此中，format中的第一个“{}”将被“key1”信息填充，第二个将被“key2”填充，通过format和key信息的组合得到日志详情记录到数据库中，每一个URL配置了相应的日志格式和信息，可以对每一个URL实现定制化的日志记录。
[0010]此外，本专利技术还提供了一种对微服务架构的日志管理系统，包括业务处理单元以及中间件；所述业务处理单元包括若干个微服务模块，每个微服务模块中创建用于记录日志的数据库，在数据库中创建一个哈希表，所述哈希表以URL为键，值为需要记录的日志格式和该次请求的信息，其中每个URL对应一个URL记录簿，时间、操作者ID和操作详情都收藏在URL记录簿中，哈希表中根据配置的key进行读取和解析用户发送的业务处理请求得到操作详
情；中间件包括拦截模块、解析请求模块、判断模块以及读取和处理数据模块；所述拦截模块，用于用户发送的业务处理请求，拦截每一次请求；所述解析请求模块，用于解析所述拦截模块传输来拦截业务处理请求的URL；所述判断模块，用于接收对所述解析请求模块中发送的URL是否在相对应的哈希表中，若不在，不做任何处理，则响应用户发送的业务处理请求进行反馈给用户，若在，读取和处理数据模块会根据URL配置的key，读取该次请求相应的信息，并将读取的信息填充到日志格式的占位中得到操作详情，最终记录到URL相对应的URL记录簿中，URL记录簿存储于数据库中。
[0011]进一步说，还包括请求模块和接收反馈信息模块；所述请求模块，用于发送的业务请求信息；所述接收反馈信息模块，用于接收中间件反馈回来的信息。
[0012]名词解释：中间件是一种独立的系统软件服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信，从这个意义上可以用一个等式来表示中间件。中本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种对微服务架构的日志管理方法，其特征在于，包括如下步骤：S1、用户在每个主机的服务端创建用于记录日志的数据库，数据库中字段包括时间、操作者ID、URL和操作详情，在服务端的数据库中创建一个哈希表，所述哈希表以URL为键，值为需要记录的日志格式和该次请求的信息，其中每个URL对应一个URL记录簿，时间、操作者ID和操作详情都收藏在URL记录簿中，哈希表中根据配置的key进行读取和解析用户发送的业务处理请求得到操作详情；S2、每个主机的服务端之间通过配置的中间件相连接数据库；S3、用户在发送的业务请求，中间件拦截每一次请求，中间件解析业务处理请求的URL，判断URL是否在相对应的哈希表中，若不在，不做任何处理，则响应用户发送的业务处理请求进行反馈给用户，若在，则哈希表根据URL配置的key，读取该次请求相应的信息，并将读取的信息填充到日志格式的占位中得到操作详情，最终记录到URL相对应的URL记录簿中，URL记录簿存储于数据库中；S4、在步骤S3上用户从步骤S1的数据库中读取需要展示或分析的日志。2.如权利要求1所述一种对微服务架构的日志管理方法，其特征在于：所述步骤S1中哈希表的格式如下：{'some_url
’
: {
‘
format
’
:
ꢀ’
{}一些描述{}
’
,
‘
key
’
: [
‘
key1
’
,
ꢀ‘
key2
’
]}}其中
’
some_url
’
表示URL，为哈希表的键，每一个U...

【专利技术属性】
技术研发人员：王晓梅，戴素剑，朱逢亮，许有茂，王雅宁，王晨阳，张世武，李广砥，李国林，袁雪，赵明芬，
申请(专利权)人：杭州知盛保科技有限公司，
类型：发明
国别省市：