apache / dubbo-go

Go Implementation For Apache Dubbo .
https://dubbo.apache.org/
Apache License 2.0
4.71k stars 925 forks source link

简化目前dubbo-go的import拓展点 #1232

Closed Mulavar closed 3 years ago

Mulavar commented 3 years ago

以现在的 dubbo-go sample 为例,想要正常启动需要 import 多个拓展点如下:

import (
    hessian "github.com/apache/dubbo-go-hessian2"
    _ "github.com/apache/dubbo-go/cluster/cluster_impl"
    _ "github.com/apache/dubbo-go/cluster/loadbalance"
    _ "github.com/apache/dubbo-go/common/proxy/proxy_factory"
    "github.com/apache/dubbo-go/config"
    _ "github.com/apache/dubbo-go/filter/filter_impl"
    _ "github.com/apache/dubbo-go/protocol/dubbo"
    _ "github.com/apache/dubbo-go/registry/protocol"
    _ "github.com/apache/dubbo-go/registry/zookeeper"
)

是否可以考虑借鉴 spring - spring boot 简化配置的路子,加个中间 go 文件,里面做不同拓展点的组装集成,让用户根据需要选择其中1~2个import就行,降低使用门槛。

georgehao commented 3 years ago

隐隐有个感觉 import 这个事情不太重要。首先得把程序加载流程的init全部显式调用后,import如何加载的关系链自动就有了。

hxmhlt commented 3 years ago

这个是依赖的问题,不是配置的问题。spring boot简化的是配置,但是也没有简化java的依赖,一个项目要run起来也是要使用者把所有依赖的jar都显式依赖进来的

hxmhlt commented 3 years ago

所以你的提议,其实是个类似于依赖分组的问题,比如可以把1,2,3import定义为一个group,然后写一个空group的go文件,去引入1,2,3的import。我觉得就方法上是可行的。只是不知道golanger能否接受这种开发习惯

AlexStocks commented 3 years ago

所以你的提议,其实是个类似于依赖分组的问题,比如可以把1,2,3import定义为一个group,然后写一个空group的go文件,去引入1,2,3的import。我觉得就方法上是可行的。只是不知道golanger能否接受这种开发习惯

个人感觉,没这个必要。理由是咱们的 dubbo-go-samples 已经挺全了,用户参考着写就行了。

XiaoWeiKIN commented 3 years ago

其实这个还是有必要的,只是可能不太通用,因为注册中心、协议、元数据中心、配置中心这是个排列组合。建议在公司级别提供一个中间文件

zhaoyunxing92 commented 3 years ago

我感觉扩展点不需要用户自己引入可以dubbo-go这边自动引入比较好点

AlexStocks commented 3 years ago

其实这个还是有必要的,只是可能不太通用,因为注册中心、协议、元数据中心、配置中心这是个排列组合。建议在公司级别提供一个中间文件

我们一般项目都在 github.com/dubbogo 下面放着。要不在建立一个 github.com/dubbogo/imports 项目,把各种组合分别按照目录组织好?

XiaoWeiKIN commented 3 years ago

good idea

zhaoyunxing92 commented 3 years ago

我有两个想法

  1. 我们在解析配置的时候判断下如果是nacos就引入nacos的注册中心如果其他就引入其他的(但是这样工作量有点大)
  2. 不管有没有用到都添加到imports里面,但是这样内存会变大因为导入很多用不到的配置

这些我希望能跟配置优化一起考虑进去,用户使用的时候只用调用dubbo.run()或者其他人口方法就可以启动dubbo-go了

Mulavar commented 3 years ago

这个是依赖的问题,不是配置的问题。spring boot简化的是配置,但是也没有简化java的依赖,一个项目要run起来也是要使用者把所有依赖的jar都显式依赖进来的

手误,谢谢纠正。

Mulavar commented 3 years ago

我有两个方法

  1. 我们在解析配置的时候判断下如果是nacos就引入nacos的注册中心如果其他就引入其他的(但是这样工作量有点大)
  2. 不管有没有用到都添加到imports里面,但是这样内存会变大因为导入很多用不到的配置

这些我希望能跟配置优化一起考虑进去,用户使用的时候只用调用dubbo.run()或者其他人口方法就可以启动dubbo-go了

这两个方法我考虑过,方法1其实也得基于方法2,需要在config那层把所有的拓展点都import进来,否则问题就变成运行期间动态import,这块我对go熟悉得不够,没找到好的实现方法。 这块应该和配置优化算一个方向,但是在实现上感觉之间的依赖关系还是有点难建立。

XiaoWeiKIN commented 3 years ago

image 这就是个工程上的最佳实践,其实你也可以再封装一层。不对用户暴露就可以了

AlexStocks commented 3 years ago

I have created a project https://github.com/dubbogo/imports for u.

georgehao commented 3 years ago

我的建议:init显式化是第一步的,这个做完后,后续是否需要这么一个中间文件就能看出来了,目前这么讨论没有落脚点。

因为目前所有的初始化都是放在init里面的,所以看来main.go里面才需要那么大一坨import, 当全部显示化调用后,每个模块要依赖什么模块,自动都会import到对应的调用文件里面。

main.go里面理论上只需要 配置中心,注册中心,协议等这些关键组件的一个 入口文件就够了,所以并不会出现一个所谓的中间文件才对。

这是我的想法,请大佬们参考

mark4z commented 3 years ago

+1

LaurenceLiZhixin commented 3 years ago

完成了么,是否可以关闭? @Mulavar