venus-tool design discussion / venus-tool 架构初步设想与讨论

[LinZexiao]

venus-tool 架构初步设想与讨论

目标

能够确定 venus-tool 的架构,方便开展下一阶段相关工作

背景

venus-tool 提出来的初衷是希望给用户提供更加便捷和完善的管理接口,用于管理用户在链服务,订单服务和算力服务的设置和数据. 同时调和因为链服务和用户分离的情形下带来的矛盾.

初步设想

venus-tool 通过 rpc 连接的方式访问链服务的部分组件,venus-market, 和 venus-cluster ,来获取相关服务, 查询和修改用户相关的数据.
同时它可以用一套统一的 rpc 接口, 为用户提供 基于web 界面或者命令行的交互方式

部署方案

基于我们现有的 venus 体系,我们可以提出两种部署方案

• venus-tool 部署到云端
• venus-tool 部署到本地

目前的鉴权 现状

不同的部署方案有个能会新增对外暴露的接口,因此有可能需要考虑完善相关的鉴权方案

• 链服务
  使用 auth 的 token 进行鉴权
• 算力服务
  cluster 目前是只提供本地服务,不对外部开放
• 订单服务
  market 目前使用的是 auth 的 token 进行鉴权,以后有可能采用的新的鉴权方案,在本地部署的话,也可以考虑不鉴权,只对本地开放

venus-tool 机房本地部署

优点

• 现有的鉴权方案就可以直接支持
• 不需要本地部署的组件对外暴露接口

缺点

• 链服务的用户需要自己多部署一个组件

venus-tool 和云服务一起部署

优点

• 链服务的用户可以直接访问使用

缺点

• 小额度增加链服务提供商 的一定的运维成本
• 需要本地部署的 venus-market ,以及 venus-cluster 对外暴露接口
• 需要完善 venus-cluster 的鉴权机制

讨论焦点及结论

• 是否两种部署方式都支持,还是只支持其中哪一种部署方式
  • 线上部署 venus-tool ,因为需要访问本地的 算力和订单服务的原因,会很大程度地增加系统的复杂度,暂时搁置
  • 目前考虑只支持 本地部署
• 是否两种用户接口都支持, 或是只支持其中哪一种
  • 两种接口都支持
  • 更加详细的划分了两种接口的定位:
    • cmd 主要定位是 解决 用户与链服务分离带来的部分矛盾
    • web ui 侧重于 订单和算力服务的数据管理
  • 分阶段完成实现

(更多讨论的关注点,欢迎大家补充)

相关连接

• 开发计划
• venus-tool 功能点的讨论

[LinZexiao]

• 关于用户接口
  如果追求更加好的用户体验,我觉得用户界面会是比较重大的提升
  在两种 用户接口都是用同一套API 的情形下,其实主要的开发工作量还是集中在 web ui 的设计和开发上,所以我觉得可以两种都支持,先确定API,然后 CMD.然后是web ui
• 关于部署方式
  本地部署是当前情况下,不需要做多大变动就可以直接支持的,所以可以确定支持
  云端部署因为需要用户机房对外暴露接口,需要考虑用户对此的意愿,所以可以进一步考虑.
  两种方案都能支持,那是当然最好

[Fatman13]

原文里面是啥画图工具？感觉很炫酷。[doge]

[LinZexiao]

https://excalidraw.com/ ,一个手写风格的画图工具,挺有意思的

[simlecode]

关联issue：#5304

[Fatman13]

另外一个，跟设计可能关系不是最紧密。就是名称上，最好脱离venus，否则grant团队容易搞混。。
另外，有没有一并支持lotus的可能性？

[LinZexiao]

venus-tool 的开发计划

venus-tool 的开发主要分成两个大阶段来完成

Comand UI 阶段

这个阶段的 venus-tool 主要满足用户对于链服务数据管理的需求,补充当前 venus 体系下用户获取链服务相关数据和进行配置的工具
值得注意的是因为 venus-market 支持多种配置模式(本地部署,或者和链服务一起部署),如果 算力服务 和链服务一样部署到云端的话, 本阶段的 venus-tool 也应该满足用户管理订单服务的数据的基本要求

Web UI 阶段

这个阶段较上一阶段增加了对订单服务和算力服务用户相关数据的管理,并且提供更加友好的交互界面

同时,也有可能会考虑以下的架构形式:

注意点

• 前后虽然分为两个阶段进行开发,但是应该尽可能考虑接口的兼容性

[Fatman13]

另外，从一开始的设计上，venus-tool是不是就要考虑是可以管理多个节点（多个vsm），而不是单一的节点？

[Fatman13]

@LinZexiao 想到一个名字。介于这个组件相对比较工具性，思路上我们可以参照node的npm（node package manager）？

我们的就叫venus service manager？然后repo的名字可以是vsm。应该不会和venus-sector-manager冲突，以后venus-sector-manager可以改成damocles-manager？

CC @hunjixin

[Fatman13]

或者ssm，storage-service-manager 怎么样？ @LinZexiao @hunjixin