堡垒机业务梳理
- 产品：可以把堡垒机理解为一个代理网页，字符，图形，文件，数据库等资产的解决方案，主要控制运维人员可以在什么时间段，那些地点访问设备，以及访问设备的时候有哪些命令的执行权限（认证+授权）toB业务。
- 项目架构：（python+go）多个服务进程跑在后台，不同服务间通过HTTP相互传递数据。supervisor做服务管理
- golang业务： engine下面的服务基本上都是基于单进程模式，内部采用多线程/协程去处理并发业务。
-
消息队列传递日志消息 kafka
shproxy/rdpproxy这些代理引擎把日志推送给logclient服务，由他统一写到kafka，另一个服务去消费日志写到mongodb
kafka：只有一个broker，单机非集群。
生产：每个topic一个分区，每个topic对应某种日志类型，每个topic对应一个producer。发送消息时采用对应topic下的producer去发送。
消费：有多少种日志就启动了多少个消费goroutine，不断从kafka对应的topic下去获取消息，并写入到mongodb数据库中。 -
运维实时回放给管理端 WebSocket
当运维开始时，运维产生的字符命令数据会被ssh代理引擎写入到文件中，通过循环读取文件新内容，发送给管理端，实现实时回放。
具体实现：一个goroutine去判断此次运维是否结束，一个goroutine发送数据到管理端。
使用WebSocket是因为更加适用于服务器主动向客户端推送消息的场景 -
网络框架如gin 提供了路由的并发处理，所以对共享数据的操作仍然需要加锁
当接收到一个 HTTP 请求时，Gin 会创建一个新的 goroutine 来处理这个请求，并调用与该请求匹配的路由的回调函数。因此，如果有多个请求同时到达，它们就会被分配给不同的 goroutines 并并行处理。注意并行特点
-
管理端可以通过账户，机构，角色，属性等四种方法给运维人员授权
初始化服务的时候会将授权策略加载到内存的结构 和 redis中，然后后续的处理落到内存处理。
核心结构如下：
// map key为用户名,树索引为资产id,值为匹配中的策略id
//从用户-->资产--》匹配的策略--》某个策略类型下的资产 从用户出发查询
var allUserAssets map[string]*rbtree.RbTree[int, *matchedAthorizationStrategyID]//从策略类型-》策略id-》查到对应的user 和 asset 从策略出发查询
var allAuthorizationStrategy authorizationStrategyID - auto_sync模块做的事情就是:
- 将已经配置好的定时任务从数据库中初始化加载到auto_sync中
- 根据请求的api添加删除定时任务
- 定时任务执行自动同步(执行同步只是请求了其他模块的api)
- 界面上配置自动同步，然后python解析请求，将该配置写到数据库，并将定时任务交给golang auto_sync代码模块，定时任务被触发后调用python接口真正进行数据同步
- ssh代理产生的sessionLog日志会通过本地套接字通信的方式将日志信息发送给log_client服务，log_client服务会接受处理该日志信息，并推送到kafka中间件中，然后access_ctl层会读取kafka中的日志并消费到mongodb数据库中。
- ssh代理中 对客户端命令进行控制的这些规则加载过来的时机 ：客户端开始运维某个资产的时候（在auth.go中）去请求access_ctl把对该资产访问的细粒度控制给加载回来
- 熟悉了golang下面的一个gocron包，用来做定时任务
