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

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

我有两个想法

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

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

Mulavar commented 3 years ago

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

手误，谢谢纠正。

Mulavar commented 3 years ago

我有两个方法

我们在解析配置的时候判断下如果是nacos就引入nacos的注册中心如果其他就引入其他的（但是这样工作量有点大）

不管有没有用到都添加到imports里面，但是这样内存会变大因为导入很多用不到的配置

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

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

XiaoWeiKIN commented 3 years ago

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