Refactor-重构
#1298
Replies: 2 comments 3 replies
-
|
话说这个重构版本有大概什么时间点发布吗 |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
closed this discussion because we have completed the refactor |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
重构背景和需求列表
重构背景
领域模型不清晰 → 导致数据的来源和数据的去向不清晰,在每层都有重复的工作
存储结构不优雅 → 一次查询涉及多个数据源,多个领域模型的级联查询,查询比较慢
底层组件对上层不透明 → 写业务层时需要追底层,且链路不顺畅
代码结构比较混乱,很多历史遗留代码没有处理掉
需求列表
应用,服务这两个领域模型,dataplane需要改造字段,其余模型需要梳理变得更充血0. 架构
原有架构
重构后架构
1. 基础模块统一改造
1.1 目录结构和配置
现有的目录结构不够清晰,想要参与项目的贡献者并不能从目录结构上清晰地了解到有哪些模块,哪些组件。此外,配置从结构上也不能体现出清晰的内部结构,对于运维人员也是一个挑战。因此改造目录结构和配置是当务之急。
改造的整体方向:目录和配置按照模块划分,没有用到的代码一律放到legacy目录下,经过讨论后再进行删除。
1.2 日志库,错误处理,工具库,CI等
这一块主要就是一些通用的二方包的统一,以及现有代码中一些错误用法的纠正。
2. 领域模型改造
基础资源
应用
应用之前完全没有这个领域模型,现在需要新增这个领域模型,应用需要包含的属性如下:
服务
服务之前也完全没有这个领域模型,需要新增,包含的属性如下:
实例
实例原先的领域模型:
很多实例的原信息都塞打了extensions中,这是导致上层开发很困难的一点,不知道这个map中有什么,从哪来的。
因此实例要进行一些改造,改造的基本点在于:
实例的基本属性,ip,port,等要显示地定义
实例的结构要结合control-plane和console两方面的需求进行定义
一些不得不扔到map中的拓展字段,要在helper中显示定义get,set。
规则
规则大体上和之前保持一致就好,但一些规则的方法可以放到领域模型的类中,赋予业务语义且可以复用。
3. 数据存储改造
现状梳理
目前存在多个数据源,从查询角度看:规则的查询使用GovernanceConfig实时查registry,实例和服务的查询依赖异步更新的ApplicationContext;从更新的角度看,规则的更新依赖GovernanceConfig。
对于上层来说,查询和更新的过程并不是透明的,很多时候需要追到底层才能知道哪里缺了字段,哪里逻辑有问题。因此,数据源的统一是大势所趋。同时ApplicationContext整体的存储结构没有向领域模型对齐,存取效率都有问题。
改造方案
改造就基于上面提到的几点来展开
ResourceDiscovery:定位是服务发现组件,如zk,nacos,istio,功能包括实例/服务元信息的获取,规则的获取和下发
ResourceEngine:定位是dubbo应用的运行引擎,如k8s,docker,功能包括实例/工作负载等运行时信息的获取
Indexer:定位是索引,多个领域模型的联询场景下,Indexer就作为提高联询查询的关键组件。Indexer和store是有联动的,可参考client-go的实现
此外,原有的组件也有一些定义上的变动:
Store就完全只负责原子资源的落库,我们可以根据存储介质来实现不同的store,如memory,db。
Manager在原先功能的基础上,增加了更多的功能,比如读写分离,请求路由等等,对于上层来说,读写就完全由manager来代理,数据源只有一个,有什么问题都可以到从store为源头开始排查。
任务表
Beta Was this translation helpful? Give feedback.
All reactions