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

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
None yet
Development

No branches or pull requests

5 participants