mirror of
https://gitee.com/Tencent-BlueKing/bk-cmdb.git
synced 2025-12-06 08:59:15 +08:00
24 lines
1.9 KiB
Markdown
24 lines
1.9 KiB
Markdown
# BK-CMDB 3.0的设计理念
|
||
---
|
||
BK-CMDB 3.0 是基于微服务架构设计的，整体分为四层，除了API网关和最底层的存储，中间的逻辑部分按照资源的操作边界进行了分层，分为业务场景层和资源管理层。
|
||
|
||
业务场景层中有各种贴近业务的场景服务，每个服务都有清晰的边界。场景服务与场景服务之间没有直接的耦合，并且每个场景服务都是无状态的，去中心化部署的。
|
||
|
||
资源管理层中有各种管理资源的抽象控制器，我们称之为controller，这个controller代理了对该资源的所有操作。
|
||
|
||
对每个场景层的服务而言，服务的逻辑是对各种资源的操作组合；对资源管理层的服务而言，服务的调用方都是各种不同的场景。
|
||
|
||
采用这种基于资源的分层设计，充分发挥了微服务架构中服务复用的特点，在实际应用中有几个好处：
|
||
* 可扩展性强
|
||
* 易于监控
|
||
* 系统热更新
|
||
|
||
## 可扩展性
|
||
如果业务场景需要扩展，只需要重新开发新的场景层服务，并复用资源管理层的服务和接口。新增的服务并不影响现有各服务的功能。
|
||
同样如果需要增加新的管理资源类型，只需要新开发对应的资源管理服务，并不影响既有资源管理服务的运行和场景层服务的功能。
|
||
|
||
## 易于监控
|
||
将资源的原子管理和复杂的场景分开，可以将资源操作的情况标准化、流程化，资源变更的捕获和推送也更精确。同时，场景层只聚焦于专有场景的业务逻辑，在链路监控上的处理也更明确清晰。
|
||
|
||
## 系统热更新
|
||
得益于微服务架构的特点，资源管理和场景类服务分层处理后，新增的场景服务，和新增的资源管理服务都可以在不影响线上环境既有部署的情况下增量发布，并通过类似蓝绿发布或金丝雀发布的方式控制灰度的过程。 |