Skip to content

总体架构 ​

系统是「一个入口、两层判定、四个 checker、四个中台、一套权限」的组合,理解模块边界比记住类名更重要。

1. 五层划分与边界规则 ​

层次模块边界规则
接入与平台层yidun-api-gateway、yidun-union-admin鉴权必须在网关完成,禁止下放给后端服务
前台检测层yidun-intelligent-risk、yidun-device-fingerpint、yidun-irisk-sdk-server检测主流程只做接收/判定/回包,明细落库一律异步
策略判定层yidun-mplatform-strategy、checker-rule、checker-namelist、checker-metrics、checker-preprocesschecker 不对外暴露开放 HTTP 检测接口,只被策略经 Dubbo 编排
数据中台层mplatform-business、mplatform-meta、mplatform-event、mplatform-clickhouse主数据变更单向:中台 → 事件中台 → 下游缓存,禁止下游直读上游库
平台支撑union-admin权限数据只经事件下发,网关与业务模块读本地缓存

四条边界规则是这套系统能横向扩展的根本。违反任何一条,都会在高峰期以「性能问题」或「状态不一致」的形式暴露出来。

2. 模块依赖全景 ​

3. 技术栈与选型理由 ​

能力选型为什么
RPCApache Dubbo内部服务间高频调用,按接口方法级负载均衡与超时控制
网关Apache ShenYu 2.5.0(二次开发)统一流量入口,插件链天然适合「签名 → 令牌 → 权限 → 路由」
关系存储MySQL + MyBatis配置类数据(策略、规则、名单元信息)强一致
缓存Redis名单执行只读 Redis、指标滑动窗口、令牌与验证码
检索与画像Elasticsearch检测明细检索、设备向量索引
明细存储HBase设备与 SDK 上报的宽表明细,写多读少
OLAPClickHouse命中明细入仓与看板预聚合
消息Kafka判定与落库解耦、事件分发、命中统计
配置中心Apollo各服务独立命名空间,支持运行时刷配置
调度Elastic-Job缓存同步、命中统计、名单到期释放、离线验证
表达式引擎QLExpress / Groovy规则条件求值与预处理自定义脚本

4. 判定链路的编排方式 ​

策略中台 execution 是在线判定唯一的编排者,它的编排原则是「先通用、后私有,互相并发、结果融合」:

关键点:

  • 策略集之间并发,单个策略集有独立超时,超时降级不阻塞整体回包。
  • checker 调用是远程 Dubbo 编排,顺序由策略过程配置决定:预处理 → 名单 → 指标 → 规则。
  • 命中结果三分类:正式命中(上线规则)、试运行命中(预上线规则)、执行失败规则,回包只带正式命中的作用,试运行结果供验证。

5. 数据一致性设计 ​

系统里所有的「配置变更」都走同一条可靠通道,这是排查配置类问题的核心知识:

因此「配置改了没生效」的排查顺序永远是:数据库有没有落 → 事件有没有发 → 下游缓存有没有刷,而不是先怀疑代码。

6. 部署形态 ​

服务部署单元说明
网关shenyu-bootstrap + shenyu-admin数据面 + 管理面分离
智能风控facade(HTTP)/ cache / execute / query / scheduler / mq / offline按职责独立扩缩容
策略中台execution / management / center / storage / offline在线判定与后台管理物理隔离
名单库yd-mp-list_mgmt-dubbo / yd-mp-list_exe-dubbo / yd-mp-list_skd管理写、执行读、调度同步
设备指纹upload-http(外网)/ query-http / innerapi / mq-storage / scheduler上报与查询分离
SDK 接入http-upload / http-configure / dubbo-query / console / mq上报、配置下发、回放查询分离

一个判断技巧

看到某个现象时,先问「它属于哪个部署单元」。同一个模块的管理面与执行面往往是不同的应用、不同的缓存、不同的发版节奏——很多「配置没生效」问题就出在这里。

最近更新

内部资料,请勿外传