Hydra/Sparta系统设计与安排

7、8、9 OKR

抽象服务系统：
功能简述：盗版nacos，我想写自己的服务发现逻辑（用户编辑服务信息或者如同nacos一样导入依赖），发现服务后提供服务管理功能，主要集中在实现服务发现与导入服务进行管理，这个可能时最耗时间的
时间安排1:8月12-14号左右实现节点树（服务树推广，不含前端，能打出JSON）
时间安排2:8月25号之前基本实现第一版本（包含前端）
（服务发现建议先不急着写，先把业务弄完，先实现静态服务，服务发现是另外一个专门系统）

抽象场景信息：
（这个就是纯后端，老样子包含节点树，对服务、任务等的再分类而已）
如：
1=>中台技术部 【这个就是场景节点】
   1.1=>基础架构部【这个就是场景节点】
     1.1.1=>云部署（混合云）代理组【这个就是场景节点】
       1.1.1.1=>VPN V2Ray内网穿透部署模块【服务或任务节点】

然后你点这个1.1.1.1，又可以看见具体的服务部署情况等。
功能简述：对不同的场景进行建表分类，其实和服务树一样，从场景节点细化到服务或者任务节点，然后还可以查看服务或者任务的详细情况
时间安排：9月10号前基本完场第一版本（包含前端）
抽象任务管理：
功能简述：有点像任务管理器，任务管理逻辑基本实现主要集中在数据层的操作
时间安排：8月25号之前基本实现第一版本（包含前端）

统一配置管理器：
功能简述：实现统一配置管理（我想到了nacos的配置拉取，应该差不多），主要还是集中在前端和数据层的操作
时间安排：9月5号之前基本实现第一版本（包含前端）

中间件和系统组件管理器：
功能简述：统一管理系统的中各种组件（应该像是docker之类），控制页面可以参考一下宝塔
时间安排：9月5号之前基本实现第一版本（包含前端）

节点间的继承逻辑：物理结构上支持多继承，一个子节点可以有多个父节点，但是一个子节点只能归属于一个节点（多引用，单归属），当引用节点被删除时，被引用的节点不会被删除，但是当一个节点所归属的节点被删除时该节点也会被一同删除，若一个节点没有归属关系则当这个节点还有引用关系时存活，无引用关系时被清除（垃圾回收）

10、11 OKR

1. 10月底 KOM 树核心部分收尾。
2. 10月底 S3协议认真搞一下。
3. 11月底 完成基础前后端业务部分。
4. 11月底前 MC 的 RPC子应用的二次开发（protobuf、thrift）
5. 11月初前 MQ 小封装。

加字段 （file_at_offset、crc32_xor、簇的申明大小[definition_size]）
bug修字段（long_path）
hydra_uofs_files_cluster_mapping <!important>
export
stream
copy（IO复制<开专门家族>、Tree复制）、move(本地移动)