Otter源码深入详解(二)

本文详细解析Otter Manager系统的架构组成,包括biz模块中的AutoKeeperCollector监控ZooKeeper状态、alarm模块实现告警功能;deployer模块使用Jetty启动Web容器;web模块处理Controller请求并调用biz模块。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在这里插入图片描述
先从manager的三个子模块开始分析
一、biz模块
autokeeper
AutoKeeperCollector类:
继承自InitializingBean,afterPropertiesSet()调用后,调用startCollect()在这里插入图片描述
startCollect启动线程,通过调用zk的四字命令,来获取zk的状态:
在这里插入图片描述
autokeeper
AutoKeeperData类:继承自AutoKeeperPersist接口
每次监控zk状态,有新的连接加入的时候,就会调用autoKeeperData对象,将连接信息,存入Map
在这里插入图片描述
在这里插入图片描述
Map的大体结构就是<server,<connection,[watcher,ephemeral]>>,说白了就是存的zk信息

common-alarm模块
主要是告警模块,最终发告警邮件,都是这个模块,
在这里插入图片描述
AlarmMessage data ,data.getMessage为告警信息,data.getReceiveKey为管理后台配置的告警接收人。
common-arbitrate模块
ArbitrateConfigImpl类,存着channel和pipeline的映射关系
DeadNodeListener类,继承InitializingBean接口,当afterPropertiesSet()接口调用,启动线程,处理死亡节点(Node节点)
其中processDead()方法,确认节点死亡,会发送告警,并重启对应channel

common-DataSourceCreator、basedao、baseservcie,不多说,数据库的连接及增删改查。

config模块为各增删改查的业务模块(channel、pipeline、canal、zk、node、alarm)
monitor为各种模块的监控报警策略,报警收敛配置等
statistics为延迟、堆积等状态的增删改查方法
user顾名思义,用户,管理员,增删改查

remote模块:这个模块都是一些远程调用的方法,用于获取node,canal的一些状态信息
interceptor和impl分别为接口和实现,具体是干嘛的,在接口的代码里,都有详细的介绍
在这里插入图片描述

再看biz模块的配置,配置采用spring配置,ORM框架为Mybatis
在这里插入图片描述

二、deployer模块分析:
web容器为内嵌Jetty,实现类:JettyEmbedServer
启动类:OtterManagerLauncher 加载配置文件,调用jetty启动web容器
resources下放入很多静态文件,和主配置文件

三、web模块:
放了一堆Action(Controller方法) ,调用biz模块中的service,dao。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值