dubbo-go
dubbo-go copied to clipboard
Go Implementation For Apache Dubbo .
同一个interface,group不同,注册多个服务的时候,config.GetConsumerServiceByInterfaceName只会返回最后一个服务实列
**What happened**: dubbo-go v3.0.1 (both consumer and provider). Used nacos as registration Center. When the provider is upgraded, the new provider is online, and the old provider is offline, but...
**What would you like to be added**: 目前dubbo-go的配置加载主要都围绕自身的配置,是否可以支持用户自定义配置加载
**What would you like to be added**: 在模块加载的时候可以提供钩子方便用户自定义加载逻辑,例如:配置文件用的密码解密
因为使用过spring cloud,就很喜欢spring cloud自己完全一套的搭建。 就对dubbogo提点建议: 1. 有自己的服务入口平台 2. 有全服务统一鉴权认证 3. 有全局的日志管理 谢谢
k8s服务如果使用的是node的ip在滚动升级的时候触发下线事件就会把刚刚注册的服务下线掉,导致客户端找不到服务,代码流程如下 > registry/directory/directory.go:124 ```go // refreshInvokers refreshes service's events. func (dir *RegistryDirectory) refreshInvokers(event *registry.ServiceEvent) { .... if event != nil { // 根据事件缓存Invoker oldInvoker, _ = dir.cacheInvokerByEvent(event) } .... }...
[CallProxy] received rpc err: Failed to invoke the method selectById in the service com.xxxxxx.RpcTaskInfoService. Tried 1 times of the providers [dubbo://:@192.0.0.0:20881/?interface=com.crm.gateway.xxxxx.RpcTaskInfoService&group=&version= dubbo://:@192.0.0.0:20881/?interface=com.crm.gateway.xxxx.RpcTaskInfoService&group=&version=] (2/1)from the registry zookeeper://192.0.0.0:2181?registry=zookeeper®istry.group=®istry.label=true®istry.namespace=®istry.preferred=false®istry.role=0®istry.timeout=10s®istry.ttl=10s®istry.weight=0®istry.zone=&remote-client-name=dubbo.registries-zookeeper-192.0.0.0%3A2181%2C192.0.0.0%3A2181%2C192.0.0.0%3A2181&simplified=false on the consumer 172.0.0.1...
**What happened**: nacos-go-sdk stdout 是有重定向的,但是在 dubbogo 层面没有透出
### 触发下线 k8s在终止容器进程的时候,会由kubelet向进程发送SIGTERM信号量。Dubbo-go中已经集成对该信号量的监听逻辑。 > dubbo-go/config/graceful_shutdown.go/config#gracefulShutdownInit  ### 服务端下线期 当触发了优雅下线的时候,这时候需要一个可配置的下线期超时时间。该段时间内,需要完成对Provider的下线和对Consumer的下线。如果该段时间内下线逻辑仍未执行完,也无需继续等待。强制下线即可。 因此可以将需要下线的进程的下线逻辑如下表示:  整个流程将在设置的超时时间`Timeout`内完成。 #### 反注册 这一步是为了将Provider从注册中心取消注册,让客户端可以通过反注册事件来将该请求实例缓存移除,这样的话之后的请求就不会请求到该进程了。由于我们需要实现不依赖注册中心的反注册事件的方案,这一步在这里是为了正常的下线逻辑和为了一个保底的下线通知。 #### 主动通知 对于Triple等依赖长连接的协议,可以采用主动通知的逻辑,也就是在维护的长连接处对Consumer发送请求。可以直接复用该连接,客户端需要对该处的请求做出下线相关处理。 ##### 重试 长连接的保活机制并不能保证当前正在维护着的长连接就是活跃的。因此可能会下线通知失败,那么这时候可以进行重试。 ##### 超时 在超时时间内,若完成了收到了和长连接个数的正确响应,那么直接继续下一步,否则会进行某一步的重试。在超时时间到之后,不再进行重试了,直接进入到下一步。 该步骤的超时时间其实可以和目前采用的等待注册中心的下线通知下发的时间相关,因为可以让注册中心的通知作为保底。 #### 被动通知 若不是采用长连接或者对于主动通知没有覆盖到的客户端,我们只采用被动通知的方式, 我们仍采用现在的方案,使用filter来对当前接收到的但还未返回的请求计数。但是这时候我们仍需要ProviderFilter,作用是用来在`OnResponse()`函数中返回一个标记,比如使用Attachment作为载体,来记录当前是否处于下线流程中。也就是我们在下线的时候,标记了Provider为Closing状态,那么这时候的所有Response中都会带上Closing标记。用于通知上游该进程正在下线。 ####...
项目上提供者节点往返zookeeper注册中心流量还是一直很大 我的提供者大概有80个节点 每一个提供者节点都和zk注册中心通信发送100k/每秒的数据 有拦包看了下像是一些用于缓存的所有提供者的列表,注册中心一直发给提供者节点,提供者也在发给注册中心; **What happened**: **What you expected to happen**: **How to reproduce it (as minimally and precisely as possible)**: **Anything else we need to know?**: