转)分布式系统架构 - Net凯 - 博客园

2019-10-05 03:46

  各国领导人或高级代表将在纽约联合国总部就人类共同面临的重大威九龙挂牌解特马b基于window平台搭建的大型分布式系统不多,之前了解过myspace、stackoverflow等大型网站。搭建一个大型平台需要综合考虑很多方面,不单纯是软件架构,还包括网络和硬件设备等。由于现代大部分应用建设都面临用户多、高并发、高可用的需求,传统软件架构已不能满足需求,需要支持分布式软件架构,能支持横向扩展,具有高可用、伸缩性、稳定性等特点。搭建如下系统架构。

  系统基于SOA架构设计,系统整体划分为不同组件或者应用服务,支持分布式的部署及扩展,并通过Nginx组件实现负载均衡。根据逻辑关联划分为:表现层、应用层和数据层。表现层负责系统与用户或者外部系统交互;应用层是服务于表现层,主要实现业务逻辑处理满足表现层的需求;数据层是负责系统数据的存储。

  主要负责与用户和外部系统交互,具体提供系统可操作WEB功能、数据交换程序或者数据接口。满足不同的场景使用。Web Layer主要用asp.net mvc5技术实现;Data Exchange根据需求实现数据交换程序;Data Interface主要基于http协议,用Web API技术实现。

  主要负责系统逻辑计算的实现,提供服务接口给展现层使用。此两层之间通信基于系统内部局域网tcp/ip协议,为了提高数据传输效率。根据应用服务职责不同,将分两大类,分别为业务应用服务和基础应用服务。业务应用服务实现业务需求的功能服务,比如用户订单、某类商品的管理功能等。基础应用服务实现系统基础公用的功能服务,比如:日志服务、缓存服务、用户认证服务功能等。本系统应用服务一般使用.NET平台的通信框架WCF技术实现,个别其他组件除外,比如MQ组件、Redis缓存组件。

  主要负责系统数据存储、同步、缓存和备份管理。本系统数据分为结构化数据和非结构化数据。对于结构化数据使用MSSQL2008以上数据库存储,基于MSSQL复制同步的机制,可以进行数据读写分离的实现,提升数据层面的优化。对于本系统业务日志数据的存储选型,由于考虑到业务日志数据结构多样化、数据量较大,所以选用MongoDB的NoSQL技术,同时系统面对着高并发的访问,采取了缓存的机制提升性能,选用Redis缓存组件实现数据缓存存储。对于非结构化数据存储,比如文档、图片等数据,本系统基于Windows平台NTFS文件系统实现文档存储和读写功能。

  本系统网络分为:内部局域网和互联网。服务器位于内部局域网,通过反向代理服务器对互联网公布系统,用户通过互联网访问系统。从网络层面安全进行隔离。用户访问系统基于http协议,系统内部之间服务器通信基于tcp/ip协议。根据部署应用的划分,将服务器分为负载均衡服务器、Web服务器、应用服务器、数据服务器四大类。

  部署基于.net平台通信框架之WCF技术实现的服务接口,提供与展现层调用,其中部分公用组件,如MQ则根据组件的要求部署。

  本系统数据存储选用:mssql数据库、MongoDB、Redis缓存和文件存储。根据项目情况数据库可做读写分离,同时结合redis做缓存策略提高系统性能。

  本章节先大致介绍系统框架及物理结构情况,由于涉及几个技术点,比如:nginx负载均衡搭建、asp.netmvc与WCF服务之间调用、redis分布式缓存使用、MongoDB存储日志、MQ异步传输日志数据、文件服务实现。后续逐步介绍。

  VMWare (Virtual Machine ware)是一个“虚拟PC”软件公司.它的产品可以使你在一台机器上同时运行二个或更多Windows、DOS、LINUX系统。与“多启动”系统相比,VMWare采用了完全不同的概念。多启动系统在一个时刻只能运行一个系统,在系统切换时需要重新启动机器。本文使用VMWare WorkStation12安装CentOS操作系统。详细安装步骤参考:查看, 百度软件下载点击。

  首先需要下载CentOS安装包,下载IOS格式,本文使用CentOS7 64bit 版本,下载

  3、安装完成重启后提示License的,输入:1、2、r、yes 完成进入成功进入系统

  Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,并在一个BSD-like 协议下发行。由俄罗斯的工程师Igor Sysoev研发,供俄国大型的入口网站Rambler使用。其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好。

  以上记录在CentOS7操作系统搭建Nginx负载均衡解决方案记录。后续简介通过Keepalived搭建Nginx负载高可用解决方案。

  上一篇文章介绍了VMWare12虚拟机、Linux(CentOS7)系统安装、部署Nginx1.6.3代理服务做负载均衡。接下来介绍通过Nginx将请求分发到各web应用处理服务。

  以上实现session和cookies读写,为了验证负载均衡下,每次请求处理是否保持一致,接下来重要内容,做负载均衡如何如何保持session一致,对于asp.net技术session原理此处不做介绍,网上搜索下大把。

  session存储于当前站点在同一个进程内,修改web.config或者bin中文件更新,会导致session丢失。此模式为默认模式。

  此模式需要SQL Server配置相关信息,启动代理服务、数据库账号及表,并将web.config指向数据库。

  上一篇写了nginx负载均衡,此篇实现高可用(HA)。系统整体设计是采用Nginx做负载均衡,若出现Nginx单机故障,则导致整个系统无法正常运行。针对系统架构设计的高可用要求,我们需要解决Nginx负载均衡出现单机故障时,系统正常运行的需求。所以系统架构引入Keepalived组件,实现系统高可用。

  Keepalived是分布式部署系统解决系统高可用的软件,结合LVS(Linux Virtual Server)使用,其功能类似于heartbeat,解决单机宕机的问题。

  keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。通过VRRP协议结合LVS,对组群服务器监控情况,若master出现宕机情况,则将VIP漂移到backup机上。实现了分布式系统高可用。可以理解为:keepalived是LVS的管理软件,根据监控情况,将宕机服务器从ipvsadm移除掉。

  1、安装ipvsadm,CentOS7自带安装包,通过yum进行安装。实现系统支持LVS

  以上完成相关配置,nginx和web服务以上一篇博客内容一致。如下对功能进行验证测试。

  1、访问系统情况:通过VIP(192.168.1.120)访问系统页面。因为设置了轮询调度,所以刷新页面访问不同站点。

  我们看到将104服务器从 LVS移除掉。此时则将后续请求转发到103服务器。

  消息通信组件Net分布式系统的核心中间件之一,应用与系统高并发,各个组件之间解耦的依赖的场景。本框架采用消息队列中间件主要应用于两方面:一是解决部分高并发的业务处理;二是通过消息队列传输系统日志。目前业界使用较多的消息队列组件有RabbitMQ、ActiveMQ、MSMQ、kafka、zeroMQ等,本文对系统架构之MQ Component诠释,并采用RabbitMQ作为消息队列中间件。

  RabbitMQ是一款基于AMQP(消息队列协议),由Erlang开发的开源消息队列组件。是一款优秀的消息队列组件,他由两部分组成:服务端和客户端,客户端支持多种语言的驱动,如:.Net、JAVA、Erlang等。RabbitMQ与其他消息队列组件性能比较,在此不作介绍,网上有大把的资料。

  RabbitMQ中间件分为服务端(RabbitMQ Server)和客户端(RabbitMQ Client),服务端可以理解为是一个消息的代理消费者,客户端又分为消息生产者(Producer)和消息消费者(Consumer)。

  2、服务端(RabbitMQ Server):主要负责处理消息路由、分发、入队列、缓存和出列。主要由三部分组成:Exchange、RoutingKey、Queue。

  (1)Exchange:用于接收消息生产者发送的消息,有三种类型的exchange:direct, fanout,topic,不同类型实现了不同的路由算法;

  (2)RoutingKey:是RabbitMQ实现路由分发到各个队列的规则,并结合Binging提供于Exchange使用将消息推送入队列;

  (3)Queue:是消息队列,可以根据需要定义多个队列,设置队列的属性,比如:消息移除、消息缓存、回调机制等设置,实现与Consumer通信;

  3、消息消费者(Consumer):主要负责消费Queue的消息,同样基于TCP协议,通过建立Connection和Channel与Queue传输消息,一个消息可以给多个Consumer消费;

  (2)Channel:是基于Connection之上建立通信通道,因为每次Connection建立TCP协议通信开销及性能消耗较大,所以一次建立Connection后,使用多个Channel通道通信减少开销和提高性能。

  以上对RabbitMQ简介,接下来我们通过实际搭建消息队列服务实践。RabbitMQ服务端能运行于Window、Linux和Mac平台,客户端也支持多种技术的实现。本次我们将在Linux之CentOS7平台搭建。

  由于RabbitMQ使用Erlang技术开发,所以需要先安装Erlang运行环境后,才能安装消息队列服务。

  (6)rabbitmq默认会创建guest账号,只能用于localhost登录页面管理员,本机访问地址:

  本章节描述,web应用生产的日志,通过rabbitmq传输,然后日志服务接收消息队列的消息。

  基于window form开发一个日志处理服务,并将接收的消息打印出来。

  此文大概介绍RabbitMQ搭建和应用于本系统,RabbitMQ还是较为简单,还提供界面监控工具方便运维人员监控。

  系统考虑到高并发的使用场景。对于并发提交场景,通过上一章节介绍的RabbitMQ组件解决。对于系统高并发查询,为了提供性能减少数据库压力,我们加入缓存机制,可以不同层次加入缓存支持,本文主要介绍应用服务层和数据层之间加入缓存机制提升性能。业界缓存组件有Redis、Memcached、MemoryCache。本系统采用Redis缓存组件,有些系统将Redis当作MQ使用,此场景本系统用RabbitMQ,Redis主要用于系统缓存应用。

  3、由于我们使用不同端口号区分,在两个服务各自建立以端口命名的文件夹。配置7000节点服务,将redis-server和redis.conf复制到/etc/redis/7000

  之前框架是一个基于SOA思想设计的分布式框架。各应用通过服务方式提供使用,服务之间通信是RPC方式调用,具体实现基于.NET的WCF通信平台。框架存在如下2个问题:

  1、高并发处理能力不足。一当高并发请求,可能出现多个服务待定处理,导致整个系统出现瓶颈。

  基于以上存在问题升级框架,结合当前主流的架构思想,将系统进行服务化思维,就是“微服务架构”。

  微服务架构(Microservices Architecture)是将系统拆分为多个服务,俗称为应用服务。应用服务实现单一、具体的业务应用功能,支持独立部署维护,多个应用服务构建成系统。应用服务之间通过轻量级通信框架进行,并且支持应用服务用不同技术或者平台实现。微服务架构是SOA架构设计思想另一种实现方式。微服务架构有如下特点:

  系统是否需要采用微服务架构进行构建是由项目需求决定。采用微服务架构进行设计构建系统,对团队成员能力比传统要求高,尤其是设计能力。

  3、高并发:支持快捷扩张应用服务处理能力,提升系统处理能力,满足并发请求。

  4、安全性:访问安全通过统一认证访问;信息安全通过加解密、签名传输;网络安全通过网络隔离及防火墙;数据安全通过定时备份及高容错能力。

  如图所示,系统架构基于SOA架构设计思想,并且采用微服务架构方式进行设计和构建。将系统呈现和数据进行分离。系统呈现基于网页进行实现,支持多种前端UI框架整合及自定义开发;数据由应用服务提供,统一通过“网关API”提供使用。架构支持通过网络层、应用层的负载均衡中间件等,实现高可用和并发处理能力。架构将一些基础公共功能抽离构建成中间件。

  1、网关API:应用服务通过网关API统一对外提供服务。网关API基于http协议、以restful方式提供统一服务接口,约定接口通信协议,支持系统呈现的功能,以轻量级的通信方式,满足不同客户端。网关API实现统一数据访问权限控制、路由应用服务、限流等功能。

  2、消息平台:负责应用服务之间更新同步信息,将原有系统架构分布式事务调用更新信息的方式,调整为通过消息异步发布/订阅处理,保证数据最终一致性,应用服务之间降低耦合度和强依赖关系。高并发能力下,取得缓存作用。

  3、服务注册监控中心:负责应用服务注册发布登记,同时监控应用服务接口运行情况,支持动态控制应用服务接收请求,实现“去中心化”服务控制。组件实现服务注册登记、监控等功能。

  4、认证中心:负责架构访问统一身份认证。通过用户口令和权限进行控制访问。结合“网关API”实现安全访问、限流等功能,同时实现页面管理功能。

  5、日志管理系统:负责记录系统日志,提供服务接口和组件,业务代码通过异步方式将日志信息传输到“消息平台”,日志管理系统订阅“消息平台”的日志信息进行处理存储。同时提供日志管理功能

  6、缓存中心:基于Redis分布式内存数据库,搭建架构统一缓存中心,提供统一缓存服务。

  如图所示,系统架构以微服务架构方式进行开发,从切面观察每个应用服务进行垂直独立开发,根据职责划分层次,从上而下分为四个层次,分别为Web层、服务接口层、业务逻辑层及数据访问层。Web层主要负责系统功能呈现表达,直接面对用户;服务接口层主要负责提供标准化服务接口,与呈现层对接;业务逻辑层主要实现应用业务逻辑,是应用服务核心部分;数据访问层负责数据持久化,支持业务逻辑层。各层次之间通过接口进行隔离,有利于后续维护扩展,减低依赖和影响。

  应用服务完成开发后进行集成部署。Web层将根据约定集成到Web应用容器,其余层次构建为应用服务进行部署,并将服务接口进行注册登记发布使用。

  基础架构大致设计就这样,还需要考虑实施部署,可以考虑云平台弹性资源,再结合docker容器技术。

  后续再逐步介绍相关基础组件设计及实现原理。技术框架重于解决问题,设计依赖需求,需求来源实际业务场景。

  本人建立了个人技术、工作经验的分享微信号,计划后续公众号同步更新分享,比在此更多具体。欢迎有兴趣的同学一起加入相互学习。基于上篇微服务架构分享,今天分享其中一个重要的基础组件“API网关”。

  随着互联网的快速发展,当前以步入移动互联、物联网时代。用户访问系统入口也变得多种方式,由原来单一的PC客户端,变化到PC客户端、各种浏览器、手机移动端及智能终端等。同时系统之间大部分都不是单独运行,经常会涉及与其他系统对接、共享数据的需求。所以系统需要升级框架满足日新月异需求变化,支持业务发展,并将框架升级为微服务架构。“API网关”核心组件是架构用于满足此些需求。

  很多互联网平台已基于网关的设计思路,构建自身平台的API网关,国内主要有京东、携程、唯品会等,国外主要有Netflix、Amazon等。

  API网关是微服务架构(Microservices Architecture)标准化服务的模式。API网关定位为应用系统服务接口的网关,区别于网络技术的网关,但是原理则是一样。API网关统一服务入口,可方便实现对平台众多服务接口进行管控,对访问服务的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制,甚至基于API调用的计量或者计费等等。组件设计如下:

  多种客户端程序,例如:移动APP、PC端和智能终端设备等。客户端程序通过互联网或者专网访问API网关,由API网关统一接收请求后,通过一系列模块定位具体处理的微服务机,并将其转发至目标服务处理,网关与微服务之间通信是内部局域网。API网关统一规范平台对外的服务,同时充当了平台的PaaS层。如上图所示,API网关功能结构基于管道模型和支持可插拔式的设计开发,提供统一基于http协议的WebAPI访问接口,内部每个模块各自实现功能,包括:黑白名单、日志、协议适配、身份认证、计流限流及路由。并且依赖“访问认证中心、服务发布管理中心”分别实现API网关访问权限控制和定位目标微服务。各模块功能说明如下:

  1、黑白名单:实现通过IP地址控制禁止访问网关功能,此功能是应用层面控制实现,再往前也可以通过网络传输方面进行控制访问。

  2、日志:实现访问日志的记录,可用于分析访问、处理性能指标,同时将分析结果支持其他模块功能应用。

  4、身份认证:负责网关访问身份认证验证,此模块与“访问认证中心”通信,实际认证业务逻辑交移“访问认证中心”处理。

  5、计流限流:实现微服务访问流量计算,基于流量计算分析进行限流,可以定义多种限流规则。

  6、路由:路由是API网关很核心的模块功能,此模块实现根据请求,锁定目标微服务并将请求进行转发。此模块需要与“服务发布管理中心”通信。“服务发布管理中心”实现微服务发布注册管理功能,与其通信获得目标微服务信息。

  API网关是一个公共基础组件,无状态,可支持多套分布式部署。如下图所示:

  1、技术:框架整体基于.NET平台构建,所以API网关也暂定基于.NET4.6平台和ASP.NET WebAPI2.0框架实现。具体软件架构就用上一篇所介绍的。

  2、性能:部署于IIS7.0,1000个并发查询请求,平均响应90ms。

  可能在IIS7.0和.Net4.6平台,在大并发性能处理上会更不上,后续将考虑基于.net core进行升级开发,并部署于Linux平台。

  API网关主要原理是相通,不同平台结合本身平台整体框架设计,可选用不同的技术实现,目前有些基于Spring MVC、node.js、Erlang技术进行研发。

  以上是对API网关概要进行设计,还有其他方面的内容此篇文章未讨论,例如:安全性、高并发、扩展性等特性设计,同时作为平台其中一个组件,也涉及与其他组件一并协同运行。此块内容会后续分享。

  日志对大型应用系统或者平台尤其重要,系统日志采集、分析是系统运维、维护及用户分析的基础。

  2、业务变更日志:特定业务场景需要,采集某用户在某时使用某功能,对某业务(对象、数据)进行某操作,由A变成B。

  3、系统运行日志:系统运行服务器资源、网络及基础中间件的情况进行定时采集日志分析。

  日志采集分析是由需求驱动,根据某种场景的需要日志采集,采集的日志进行针对性的分析。一般常见的日志分析结果应用场景有:

  1、分析系统或者平台哪些功能是最受欢迎:什么时候使用最多用户使用,某个区域、某类用户使用最多。有利于功能推广;有利于提升服务器资源从而提高用户体验。

  2、内容推荐:根据用户平常阅读内容,采集相关日志,并通过分析后,将用户感兴趣的内容系统自动推荐给用户,从而提升用户站粘性。

  3、系统审计:对于应用系统,采集操作日志、业务变更日志,有利于备查及提供相关安全审计功能。

  4、自动化运维:场景微服务架构的系统或者平台,对运维投入的要求高,自动化部署和运维,可以减少运维的工作量和压力。系统运行环境日志采集、分析,可实现预警、服务器资源动态调配,有利于快速定位排查故障。

  不同系统的运行环境、功能应用场景及需要采集分析日志的需求也各不相同。日志内容、采集方式存在多样性,日志数据量大,所以需要设计一套日志采集系统,满足日志采集需求,支持便捷将分析结果反捕于应用功能。

  基于以上日志采集的初步分析,尤其微服务架构中,微服务治理能力、服务负载需要依赖服务日志的采集分析,所以日志采集子系统是微服务架构的基础支持功能。日志采集系统总体设计如下:

  如上图所示,根据日志整个过程,系统由三部分组成:日志采集、日志存储&分析及结果应用。日志采集主要负责提供多种方式进行采集日志;日志存储&分析主要实现分析统一存储和定制的场景分析日志;结果应用实现将日志分析结果提供服务接口或者默认的管理功能,供应用功能使用。

  日志采集整体过程:日志采集后,通过在线或者离线传输到消息队列,由日志消费应用拉取后进行存储。根据分析需要定制自动作业任务实现日志数据抽取、转换、统计后,将结果数据写入关系型数据库。提供服务接口或者日志查询默认管理功能进行使用。

  (1)WebAPI方式:实现基于http协议 restful方式采集日志数据,并发送至消息队列。主要用于提供移动端、微信公众号及小量日志采集使用,在NET分布式系统上可结合“API网关”使用。

  (2)Service Proxy方式:基于log4.net优秀的日志组件和消息队列客户端驱动,进行封装为日志记录服务代理,提供便捷、统一的接口供应用进行使用。支持将日志记录到应用本地和在线实时发送至消息队列,其中记录到应用本地,可结合第三种方式完成应用功能日志采集的功能。

  (3)LCClient方式:实现客户端批量抓取日志数据,发送至LCServer。LCClient客户端基于TCP协议与LCServer服务端进行通信,基于NIO框架构建,可支持高并发处理能力。LCServer再将日志数据写入消息队列。

  日志存储及分析由五部分构成:消息队列(MQ)、日志接收服务端(LCServer)、日志存储(Elasticsearch)、任务作业(Quartz.net)及关系型数据库(MySQL)。

  (1)消息队列(MQ):日志通过消息队列实现消息统一接收,做一道缓冲,满足日志数据并发接收能力。

  (2)日志接收服务端(LCServer):接收LCClient客户端批量发送日志数据,并将其发送至消息队列。

  (3)日志存储(Elasticsearch):选用ES做日志存储,主要考虑ES是一种文档化分布式搜索服务,支持PB级的数据存储,支持上百个节点的分布式集群能力,并且提供丰富的API使用,数据查询方面有着优越的性能。

  (4)任务作业(Quartz.net):通过定制化开发作业任务实现对ES日志数据抽取、转换、分析后,将结果存储于关系型数据库。Quartz.net中间件是业界公认的作业任务组件。

  (5)关系型数据库(MySQL):实现日志结果数据存储,供日志应用查询使用。MySQL有着优越的主从复制机制,可解决单节点查询性能瓶颈,同时提供传统SQL脚本操作数据的能力,提供开发效率。

  (1)服务接口方式:基于http协议以restful方式提供接口,支持应用功能方便调用。

  (2)管理模块方式:默认提供一套日志查询管理功能,方便于应用直接集成使用。

  日志采集本身也是一个分布式系统,服务端每个节点都支持分布式集群部署,可实现高并发、高可用性。本文只是一种抛砖引玉,系统每个组件还需要深化详细,同时也包括实施部署。

  .Net技术栈目前还没有像spring cloud相对完整一整微服务架构栈,随着业务发展系统架构演进,自行构建.Net技术体系的微服务架构,配套相关核心组件。因平台基于微服务架构方式研发,每个领域服务遵循平台统一标准,各自研发,独立部署运行,服务运行日志均通过记录本地文件方式进行记录。程序日志无法及时查阅,需登录服务器查看,同时不利于日志统一管理,因研发运行日志分析系统,进行日志统一分析管理,便于快速定位程序运行问题及时处理,保障平台运行稳定。虽然行业上也有一些日志架构,如较为有名的LEK(logstash, elasticsearch, kibana),因考虑到后续一些个性化的需求,还是自行研发运行日志分析系统。

  系统在总体微服务架构设计思想下,遵守平台标准,并结合实际解决问题的需要,进行设计和研发,系统严格按照如下设计原则设计:

  2、服务化:各模块通信,通过服务方式进行调用,服务之间通信,遵守平台的标准。

  3、松耦合:系统模块之间通信,基于行业通用标准,按照“约定优于配置”思想,充分体现系统模块之间松耦合的关系。

  如图所示,系统基于上述设计原则,主要由五部分组成:日志记录、日志采集、日志接入、日志分析及存储、日志管理服务。每部分职责定位明确,相互支持、相互协作,共同构成运行日志分析系统。日志记录到本地文件,通过日志采集器将本地日志文件抽取后,发送至Kafka,同时由日志分析服务进行消费、分析及存储于elasticsearch,日志管理服务提供于用户查阅&分析日志信息。在平台统一通信协议下,扩展运行日志的内容,沿用Json报文格式,记录内容包括:IP、端口、服务ID、记录时间、日志内容。

  日子记录,支持多种日志记录组件:Log4.net(本系统选用)、.Net core 自带的Nlog、微软企业库等,针对JAVA技术语言开发的服务,则选用log4j组件,只要按照约定规范进行打印日志即可。将日志信息记录到本地文件。

  日志采集,选用filebeat组件,filebeat是一个轻量级的日志传输组件,其可以通过提供一种轻量级的方式来转发和集中日志和文件,帮助你把简单采集和发送的事情简单化。本质上filebeat是一个日志信息搬运工,不进行日志过滤和分析工作。同时支持跨平台。

  日志接入,考虑日志量在某一故障情况,可能存在较大并发接入,所以选用Kafka组件作为日志信息接入分析的统一入口,kafka组件是一个高性能的MQ组件,具有高并发、高可用的特性。统一接入方案,为系统提供更为灵活的采集日志,不受限于某一平台、技术或者日志采集组件,均可将运行日志进行接入分析和存储。

  日志分析,采用.Net Core研发,以后台服务的方式进行运行,订阅kafka的日志消息进行批量消费,分析程序支持横向扩展部署于多个程序,提升日志的消费能力,保障日志接收能力和分析能力相当。对日志分析后存储于Elasticsearch(以下简称:ES),ES是一个高可扩展的开源全文搜索和分析引擎,它允许存储、搜索和分析大量的数据。非常适合存储半结构化的日志数据,便于全文搜索日志信息。

  日志管理服务,实现查询ES中的运行日志数据,通过WebAPI方式提供界面功能调用。本系统采用“前后分离”应用开发技术,前端界面功能采用H5+JS,后端服务以restful方式提供API接口。

  根据不同应用场景和需求,选用不同的日志分析架构或者自行研发,最终目的就是为了快速、方便捕捉系统日志,有助于分析系统运行情况。尤其对于微服务架构大型平台,运行日志更为重要。本文主要是将系统设计原则、思想进行记录,同时对有需要的同学提供参考,可能再实际应用中,还有很多地方需要完善或者优化。

  关于作者:专注于微软平台项目架构、管理。熟悉设计模式、领域驱动、架构设计、敏捷开发和项目管理。现主要从事ASP.NET MVC、WCF/Web API、SOA、MSSQL、redis方面的项目开发、架构、管理工作。 如有问题或建议,请一起学习讨论!