Skip to content
This repository has been archived by the owner on Jun 23, 2022. It is now read-only.

代码重构与化简 #141

Open
10 of 28 tasks
qinzuoyan opened this issue Jul 18, 2018 · 15 comments
Open
10 of 28 tasks

代码重构与化简 #141

qinzuoyan opened this issue Jul 18, 2018 · 15 comments
Assignees
Projects

Comments

@qinzuoyan
Copy link
Member

qinzuoyan commented Jul 18, 2018

完成

TBD

  • 将cli的接口从core中挪到dist中 (cli: refactor cli related code #156)
  • 移除serialization中对protobuf的支持,从而可以删除所有的xxx.types.h的头文件,只保留_types.h即可
    (serialization: completely remove protobuf support #161, *: remove *.types.h files #164)
  • 移除 tools/repli (tools: remove repli #162)
  • 拆出随机数的接口到utility (util: make rand a standalone util decoupled from rdsn runtime #163)
  • 拆出clock的接口到utility
  • 将logger并到utility,从而使得utility可以成为脱离rdsn的库
  • 一些staled feature的删除:start_delay、rpc_message中的local_hash
  • 彻底删除memory provider,换成tcmalloc
  • 将task、rpc、file的c接口拆成concurrent、rpc、aio的三个模块,从而解除这三个模块间的耦合
  • 将uri resolver从rpc engine中挪出,放到client库中
  • 移除对group address的支持,把rpc engine变成通用、易理解的rpc库
  • 整理bootstrap流程。至少将创建线程池的功能从配置文件挪到源代码,努力把task做成通用的线程池库。
  • 合并failure_detector和failure_detector_multimaster
  • 整理register_component_provider的机制,把注册放到对应的模块中,而不要堆到tool_api.h下。
  • 测试性能影响,可能的话删除shared log
  • 整理last_durable_decree、last_committed_decree、last_flushed_decree
  • 把删表时候添加的各种奇怪的work around整理清楚
  • 将simple kv和rocksdb分别作为storage_engine放到一个公共的目录中,推动pegasus和rDSN的合并。pegasus和rdsn的分离,对于项目的开发以及pr都是不太有利的。
  • 整理C++ client:争取在异步接口层能用到rdsn的task机制;开启条件编译,减小client的库大小;可能的话利用SWIG来统一生成所有的客户端SDK。或者将 C++ client 整理为简单的 C API,可以支持其他语言如 php。
  • 整理测试,把测试和逻辑代码位置放的近一些。
  • 各种satinizer的引入,valgrind的接入,代码覆盖率工具的接入
  • 整理thrift接口,按meta_server, replica_server, base等这些方式区分开
  • 使用 rpc_holder 简化相关的逻辑代码
  • 整理构建过程,让 thrift 的编译生成结果放在 builder 下而不是作为源文件
  • 直接编译官方 thrift compiler 而非下载魔改版本的 compiler。
  • 将 c++ 的 gpid 改名为 gpid_t
  • rocksdb 减少侵入式修改
  • 把 simple_logger 用 https://github.com/gabime/spdlog 代替。
@neverchanje
Copy link
Contributor

neverchanje commented Nov 19, 2018

不管目录重整多不多,我们可以先合议一个最终目标出来,后面一步一步改。本意是改的目录结构大家提前有一个共识 (参考 #195 的讨论)

整体项目分为 core 和 dist 两大部分,按照讨论,所有 client/server 相关的模块放在 dist,dist 在 core 之上构建。

- src/core/utils: core 里的 utilities
- src/core/concurrent 或者 src/core/task
- src/core/aio
- src/core/rpc
- src/core/perf_counter
============
- src/dist/http
- src/dist/nfs
- src/dist/block_service
- src/dist/failure_detector
- src/dist/cli
- src/dist/replica_server => 
    - src/dist/replica_server/store
    - src/dist/replica_server/store/simple_kv
    - src/dist/replica_server/store/rocksdb
- src/dist/meta_server
- src/dist/zookeeper
- src/dist/duplication
- src/dist/security
- src/dist/backup
- src/dist/client 这里放我们的 ddl client,后面两个项目整合可以一起放 pegasus client

@shengofsun
Copy link
Contributor

把rserver和mserver改名成replica_server和meta_server就好,别的没问题。

@acelyc111
Copy link
Member

为什么还要保持两个目录(dist,core)呢?为什么不去掉dist,core并把目录平摊到一层呢?

@neverchanje
Copy link
Contributor

为什么还要保持两个目录(dist,core)呢?为什么不去掉dist,core并把目录平摊到一层呢?

core 目录下为 dsn.runtime 相关代码, 因为当时许多组件的代码还和 dsn.runtime 绑定, 所以我们在结构上分为 core 和 dist, 分别代表 dsn.runtime基于runtime的上层实现.

而目前许多模块已经从 dsn.runtime 剥离出来, 并且目前距上次讨论已经间隔2年, 确实我们应该再次整理代码的结构.

- src/runtime/task
- src/runtime/rpc # rpc,task和部分零碎代码在剥离后可以移出runtime
- src/runtime
============
- src/utils
- src/aio
- src/perf_counter
- src/http
- src/nfs
- src/block_service
- src/failure_detector
- src/remote_cmd
- src/replica => 
    - src/replica/store
    - src/replica/store/simple_kv
    - src/replica/store/rocksdb
- src/meta
- src/zookeeper
- src/duplication
- src/security
- src/backup
- src/client 这里放我们的 ddl client,后面两个项目整合可以一起放 pegasus client

@acelyc111 @levy5307

@levy5307
Copy link
Contributor

levy5307 commented Jun 29, 2020

还要有个common吧?存放meta server和replica server共同使用的部分,比如replication_options等
另外还有那些tool/tool-api/toolet/tool_lib/utils,很容易让人产生困惑,无法分清有什么区别

@acelyc111
Copy link
Member

可以参考下kudu的目录结构和划分逻辑:
common:存放跟rdsn/Pegasus项目紧密相关的通用文件
util:最基础的工具类,比如time、string、lock等最基础的组件,他们甚至可以移植到其他项目。跟现在rdsn的include/dsn/utility基本一致
tools:存放真正用户可使用的“工具”相关的类。跟我们的ddl_client,remote command相似
其他的tool-api/toolet/tool_lib真的无法从名字看出它是干什么的了,尽量就不保留了

@levy5307
Copy link
Contributor

可以参考下kudu的目录结构和划分逻辑:
common:存放跟rdsn/Pegasus项目紧密相关的通用文件
util:最基础的工具类,比如time、string、lock等最基础的组件,他们甚至可以移植到其他项目。跟现在rdsn的include/dsn/utility基本一致
tools:存放真正用户可使用的“工具”相关的类。跟我们的ddl_client,remote command相似
其他的tool-api/toolet/tool_lib真的无法从名字看出它是干什么的了,尽量就不保留了

所以,我们是不是也要把remote command和ddl_client这些也放到tool里,而不是单独放在一个路径下?

@neverchanje
Copy link
Contributor

neverchanje commented Jun 30, 2020

还要有个common吧?存放meta server和replica server共同使用的部分,比如replication_options等

可以多加个 common, 虽然我不太喜欢这个名字,因为很难理解这个 common 指的是什么。

所以,我们是不是也要把remote command和ddl_client这些也放到tool里,而不是单独放在一个路径下?

kudu 的 tools 本质上是 command-line tool, 是无法跟 ddl_client 和 remote_command 相提并论。

如果后续将 Pegasus 与 rdsn 合并,或许可以把 remote_command 和 ddl_client 放到 shell 的目录下。

- src/runtime/task
- src/runtime/rpc # rpc,task和部分零碎代码在剥离后可以移出runtime
- src/runtime
============
- src/utils
- src/aio
- src/perf_counter
- src/http
- src/nfs
- src/block_service
- src/failure_detector
- src/remote_cmd # remote command
- src/common # replica/meta 公共代码
- src/replica => 
    - src/replica/store
    - src/replica/store/simple_kv
    - src/replica/store/rocksdb
- src/meta
- src/zookeeper
- src/duplication
- src/security
- src/backup
- src/client 这里放我们的 ddl client,后面两个项目整合可以一起放 pegasus client

@levy5307
Copy link
Contributor

levy5307 commented Jul 2, 2020

另外还有个tools,所以应该是这样的:

  • src/runtime/task
  • src/runtime/rpc # rpc,task和部分零碎代码在剥离后可以移出runtime
  • src/runtime
    ============
  • src/tools
  • src/utils
  • src/aio
  • src/perf_counter
  • src/http
  • src/nfs
  • src/block_service
  • src/failure_detector
  • src/remote_cmd # remote command
  • src/common # replica/meta 公共代码
  • src/replica =>
    • src/replica/store
    • src/replica/store/simple_kv
    • src/replica/store/rocksdb
  • src/meta
  • src/zookeeper
  • src/duplication
  • src/security
  • src/backup
  • src/client 这里放我们的 ddl client,后面两个项目整合可以一起放 pegasus client

@neverchanje
Copy link
Contributor

另外还有个tools

tools 包括哪些组件?

@levy5307
Copy link
Contributor

levy5307 commented Jul 2, 2020

另外还有个tools

tools 包括哪些组件?

比如profiler,tracer这些,具体需要我后面整理一下

@acelyc111
Copy link
Member

另外还有个tools

tools 包括哪些组件?

比如profiler,tracer这些,具体需要我后面整理一下

profiler,tracer 应该属于util

@levy5307
Copy link
Contributor

levy5307 commented Jul 2, 2020

另外还有个tools

tools 包括哪些组件?

比如profiler,tracer这些,具体需要我后面整理一下

profiler,tracer 应该属于util

我理解utils应该是最基础的工具类,应该是即使是跨项目也可以直接用的东西。但是profiler和tracer依赖了很多task和rpc的东西

@acelyc111
Copy link
Member

另外还有个tools

tools 包括哪些组件?

比如profiler,tracer这些,具体需要我后面整理一下

profiler,tracer 应该属于util

我理解utils应该是最基础的工具类,应该是即使是跨项目也可以直接用的东西。但是profiler和tracer依赖了很多task和rpc的东西

我以为你说的是#510 这个tracer。依赖task,rpc的那个是不是放到common好点?

@levy5307
Copy link
Contributor

levy5307 commented Jul 2, 2020

另外还有个tools

tools 包括哪些组件?

比如profiler,tracer这些,具体需要我后面整理一下

profiler,tracer 应该属于util

我理解utils应该是最基础的工具类,应该是即使是跨项目也可以直接用的东西。但是profiler和tracer依赖了很多task和rpc的东西

我以为你说的是#510 这个tracer。依赖task,rpc的那个是不是放到common好点?

如吴涛所说,其实common这个路径看名字很难理解是做什么的。所以我在想要不要common改成common_define,里面只保留一些公共的变量定义等等,不向里面放入太多东西

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
Refactoring
  
To do
Development

No branches or pull requests

5 participants