交流讨论💬
微服务插件体系
传统 CMDB 往往只是一个“只能看、不能动”的静态资产数据库。工程师在资产台账里查到服务器或数据库后，要想真正上手操作，依然要打开外部的堡垒机、数据库客户端、K8s 控制台或各种私有运维脚本，在多个系统之间来回切换。
为什么市面上的 CMDB 很少直接集成具体的运维操作？ 因为把各种运维连接逻辑硬编码进 CMDB 核心服务里是一场灾难：SSH 长连接消耗大量内存，文件传输占用极高带宽；各种各样的第三方工具协议极易引发阻塞或崩溃，一旦某个运维功能写出 Bug 导致进程 Panic，整个公司的 CMDB 资产中枢就彻底瘫痪了。
为了彻底打破“资产数据”与“运维现场”的割裂，ECMDB 打造了一套高隔离、强安全、支持任意业务自行扩展的微服务插件生态：
将 CMDB 升级为可操作的运维中枢：将具体的在线操作逻辑以插件微服务的形式解耦挂载到资产上，不仅开箱支持服务器终端管理，更支持团队按需自行扩展；
进程级绝对隔离，免除后顾之忧：插件作为独立的微服务运行在数据面，无论承载多大的网络流量、哪怕插件代码发生致命崩溃，资产主站始终坚如磐石，核心查询零感知、零影响；
零信任凭据安全：插件完全无需接触数据库和加密根密钥，主站仅在建立连接的瞬间在内存中透明注入解密凭据，握手连通即刻在内存彻底销毁。
官方插件生态仓库：GitHub: Duke1616/ecmdb-plugins
主站核心仓库：GitHub: Duke1616/ecmdb
统一开发套件 (SDK)：
pkg/plugin（开箱即用的声明式契约、泛型解析与反代路由）
1. 架构定位与协同流转
无论企业接入何种运维插件，系统都遵循一致的控制面与数据面协同流程：
核心解耦原则
| 考量维度 | 资产主站（控制面 ECMDB Core） | 扩展插件微服务（数据面 ecmdb-plugins） |
|---|---|---|
| 主要职责 | 统管资产模型、元数据检索、多租户权限校验、加密凭据统一落盘 | 承接具体的底层运维协议（如 SSH、SFTP 等）与交互会话 |
| 进程隔离 | 核心主站独立运行，不受任何业务运维操作影响 | 插件独立部署在内网环境，即使内存泄漏或发生崩溃，也 100% 隔离在插件自身进程内 |
| 性能保护 | 资产查询高频并发，CPU 与内存资源受到严格保障 | 海量长连接与重网络 I/O 全部由插件微服务分流消化 |
| 凭据安全 | 统管机密密钥，仅在建立物理通道的毫秒级瞬间在内存中解密 | 物理连通后立刻清空内存明文，全链路零落盘，浏览器前端绝不接触密码 |
2. 为什么开发者愿意基于它扩展运维能力？
ECMDB 插件体系并非专为特定运维工具定制，而是一套吸引开发者低成本快速实现运维需求的通用底座。开发一个全新的运维插件拥有以下三大绝招：
绝招一：不用写 SQL，不用管加解密，声明即所得
传统二次开发最头疼的是翻表结构、写 SQL、查关联关系、找密码解密接口。 而在 ECMDB 中：
- 开发者只需要写一个普通的 Go 结构体，打上
plugin:"..."标签声明自己需要什么资产字段（如 IP、端口、账号、密码）； - 管理员在管理控制台保存插件的模型绑定时，主站会读取契约，全自动把所需模型建好、字段映射对齐、拓扑规则连好，完全不需要手工去一个个建表加属性；
- 建立连接时，主站自动把已解密的数据打包成强类型的 Go 结构体直接注入给你，开发体验行云流水。
绝招二：微前端独立打包，无需改动主站一行前端代码
- 插件前端微组件采用标准 UMD 格式打包，直接托管在插件自己的后端静态目录里；
- 公共库（Vue、Element Plus 等）直接复用主站现成的基座运行时，插件打包产物仅数十 KB；
- 在管理台启用插件绑定后，资产列表操作栏自动挂载专属操作按钮；点击按钮时，主站才动态拉取插件前端并在抽屉中滑出操作工作区；
- 插件上线、发版、更新，主站前端零修改、零重新编译、零重启。
绝招三：零信任凭据流转，天生具备企业级安全合规
- 无论目标机器的登录密码还是私钥，浏览器端从始至终只传递资产 ID，网络抓包绝无明文泄露风险；
- 敏感凭据仅在插件后端建立物理连接的瞬间瞬态注入，连通后即刻在内存彻底销毁，天然满足严格的企业审计与合规规范。
3. 两阶段生命周期机制
从插件启动到用户在页面上发起操作，系统经历了两个严密阶段：
阶段一：插件启动与全自动装配
插件启动后主动向主站汇报并完成注册，整个过程零人工干预：
text
插件微服务启动 ──[ 1. RPC: RegisterPlugin ]──> 资产主站
│
<──[ 2. HTTP: GET /definition ]────┘ (主站反向拉取插件能力定义)
│
┌─────────────┴─────────────┐
▼ ▼
注册反向代理路由 持久化操作动作与权限
(/api/plugin-runtime/:id/*) (资产列表操作栏自动挂载按钮)- 上报服务地址：插件启动后，调用主站 RPC 接口上报插件唯一标识（如
builtin.ssh）及其内网访问地址； - 反拉自描述契约：主站反向调用插件的
/definition接口，拉取插件支持的操作名称、图标、挂载的目标资产模型、所需字段及微前端地址； - 注册并持久化：主站自动在网关中生成反向代理路由规则，并在对应资产模型的操作权限中生效。此时刷新资产列表页，该模型下的每一项资产操作栏都会自动出现该插件的入口按钮。
阶段二：用户触发与全双工会话流转
当工程师在资产列表页点击按钮发起操作时，网络与安全凭据开始流转：
text
[ 浏览器 ] ──1. 点击操作 (只带资产 ID，不含明文)──> [ 接入层网关 ]
│ 2. 剥离公共前缀
▼
[ 主站反代网关 ]
│ 3. 转发至插件内网地址
▼
[ 插件微服务 ]
│ 4. RPC 申请连接凭据
▼
[ 主站内存瞬态解密 ]
(解密密码/私钥，组装跳板机拓扑)
│ 5. 注入强类型对象返回
▼
[ 浏览器 ] <══ 7. 升级为全双工长连接 ═══════════════ [ 插件微服务 ] ──6. 物理直连──> [ 目标服务器 / 实例 ]
(连接成功立刻销毁内存凭据)- 双层透明反向代理：插件部署在内网无公网端口，请求统一经由接入层与主站反向代理网关透传，原生支持协议升级；
- 凭据按需下发：插件后端通过内网安全调用接口向主站申请上下文；主站在内存中把加密的密码或私钥解密，若该资产配置了跳板机，主站还会沿着拓扑关系把跳板机信息一并组装打包返回；
- 通道建立与凭据销毁：插件利用解密凭据穿透跳板机与目标服务器建立物理通信；网络握手成功瞬间，插件立即清空释放内存中的明文凭据，并将连接升级为全双工长连接，向浏览器交付交互式运维工作台。
4. 当前支持的插件能力
目前官方已正式实装并开箱即用的插件为在线终端与文件管理器（builtin.ssh）：
| 插件标识 | 插件名称 | 绑定资产模型 | 当前支持的核心能力 |
|---|---|---|---|
builtin.ssh | 在线终端与文件管理器 | 主机模型（物理服务器 / 云主机） | • 在线命令行终端：交互式命令行，原生支持跳板机网关穿透登录 • 可视化文件管理：目录树浏览、文件拖拽上传下载、文本文件在线轻量查看与编辑 |
NOTE
系统底层具备通用的插件微服务与契约协议，后续可根据团队实际运维需求按相同规范扩展更多资产插件。
5. 实操演练：插件注册、模型绑定与终端流转全景
为了让您更直观地理解插件体系在实际生产中的运作方式，以下展示从插件微服务中心注册、模型拓扑绑定到资产列表操作、全双工在线终端建立的真实操作全景。
您可以通过下方的交互式演练视窗总览全流程（支持平滑自动演示与步骤切换，点击画面任意处可进入全屏画廊并支持键盘左右方向键连续浏览）：
1/6
TIP
想要为您的团队开发一个专属的运维插件？请查阅专篇实战指南：插件契约与模型注入，了解如何仅凭一个结构体即可实现模型自动创建、已有字段别名映射与拓扑注入。