GitHub user robocanic edited a discussion: Refactor-重构
### 重构背景和需求列表 #### 重构背景 1. 领域模型不清晰 → 导致数据的来源和数据的去向不清晰，在每层都有重复的工作 2. 存储结构不优雅 → 一次查询涉及多个数据源，多个领域模型的级联查询，查询比较慢 3. 底层组件对上层不透明 → 写业务层时需要追底层，且链路不顺畅 4. 代码结构比较混乱，很多历史遗留代码没有处理掉 #### 需求列表 |模块|具体改造点| |-|-| |基础模块|目录结构，配置改造，日志库，工具库，error定义和处理，冗余代码迁移| |领域模型|新增`应用` ，`服务` 这两个领域模型，`dataplane`需要改造字段，其余模型需要梳理变得更充血| |数据存储|改造领域模型之后， 需要改造对领域模型的增删改查进行增强，并且对上层常用的查询方法进行底层适配| ### 0. 架构 #### 原有架构  #### 重构后架构 <img width="2079" height="816" alt="image" src="https://github.com/user-attachments/assets/e47151cb-a1c4-4302-960d-037bce32bc07"; /> ### 1. 基础模块统一改造 #### 1.1 目录结构和配置 现有的目录结构不够清晰，想要参与项目的贡献者并不能从目录结构上清晰地了解到有哪些模块，哪些组件。此外，配置从结构上也不能体现出清晰的内部结构，对于运维人员也是一个挑战。因此改造目录结构和配置是当务之急。 改造的整体方向：目录和配置按照模块划分，没有用到的代码一律放到legacy目录下，经过讨论后再进行删除。 <img width="1350" height="795" alt="image" src="https://github.com/user-attachments/assets/27840293-89e4-44aa-a9e9-18cfa481b60d"; /> #### 1.2 日志库，错误处理，工具库，CI等 这一块主要就是一些通用的二方包的统一，以及现有代码中一些错误用法的纠正。 ### 2. 领域模型改造 #### 基础资源 应用 应用之前完全没有这个领域模型，现在需要新增这个领域模型，应用需要包含的属性如下： |字段名|类型|说明| |-|-|-| |name|string|应用名| |workloads|list|工作负载| |lables|map|标签| 服务 服务之前也完全没有这个领域模型，需要新增，包含的属性如下： |字段名|类型|说明| |-|-|-| |name|string|服务名| |version|string|版本| |group|string|分组| |definition|struct|服务定义| |labels|map|标签| 实例 实例原先的领域模型： ```ProtoBuf message Dataplane { Networking networking = 1; MetricsBackend metrics = 2; Probes probes = 3; map<string, string> extensions = 4; } ``` 很多实例的原信息都塞打了extensions中，这是导致上层开发很困难的一点，不知道这个map中有什么，从哪来的。 因此实例要进行一些改造，改造的基本点在于： 1. 实例的基本属性，ip，port，等要显示地定义 2. 实例的结构要结合control-plane和console两方面的需求进行定义 3. 一些不得不扔到map中的拓展字段，要在helper中显示定义get，set。 #### 规则 规则大体上和之前保持一致就好，但一些规则的方法可以放到领域模型的类中，赋予业务语义且可以复用。 ### 3. 数据存储改造 #### 现状梳理  目前存在多个数据源，从查询角度看：规则的查询使用GovernanceConfig实时查registry，实例和服务的查询依赖异步更新的ApplicationContext；从更新的角度看，规则的更新依赖GovernanceConfig。 对于上层来说，查询和更新的过程并不是透明的，很多时候需要追到底层才能知道哪里缺了字段，哪里逻辑有问题。因此，数据源的统一是大势所趋。同时ApplicationContext整体的存储结构没有向领域模型对齐，存取效率都有问题。 #### 改造方案 改造就基于上面提到的几点来展开 <img width="2051" height="834" alt="image" src="https://github.com/user-attachments/assets/ae00cfee-7df4-4ed2-b581-753bbabde12f"; /> 引入了三个新的组件，Discovery，Engine，Indexer。 4. ResourceDiscovery：定位是服务发现组件，如zk，nacos，istio，功能包括实例/服务元信息的获取，规则的获取和下发 5. ResourceEngine：定位是dubbo应用的运行引擎，如k8s，docker，功能包括实例/工作负载等运行时信息的获取 6. Indexer：定位是索引，多个领域模型的联询场景下，Indexer就作为提高联询查询的关键组件。Indexer和store是有联动的，可参考[client-go](https://github.com/kubernetes/client-go)的实现 此外，原有的组件也有一些定义上的变动： 7. Store就完全只负责原子资源的落库，我们可以根据存储介质来实现不同的store，如memory，db。 8. Manager在原先功能的基础上，增加了更多的功能，比如读写分离，请求路由等等，对于上层来说，读写就完全由manager来代理，数据源只有一个，有什么问题都可以到从store为源头开始排查。 ### 任务表 | 需求 | 模块 | 负责人 | 等级 | 进度 | | ---------------- | ------------------------------------------------------ | ------ | ---- | ---- | | 基础模块统一改造 | 目录结构 冗余代码迁移 配置改造 | 陈才 | p0 | done | | | 日志库 工具库 error定义和处理 （包括对现有的代码改造） | 钟坚 | p1 | | | 领域模型改造 | 应用，实例，服务等 | 陈才 | p0 | 80% | | 数据存储改造 | Store的DB实现 | | p1 | | | | Indexer的实现 | | p2 | | | | Discovery的zk/nacos实现 | 王天意 | p2 | | | | Engine的k8s实现 | | p2 | | GitHub link: https://github.com/apache/dubbo-admin/discussions/1298 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
