wwcd / grpc-lb Goto Github PK

经过对比，发现博主的代码和 https://github.com/wothing/wonaming 代码相似度极高，建议添加参考代码地址

	if _, err := cli.KeepAlive(context.TODO(), resp.ID); err != nil {
		return fmt.Errorf("grpclb: refresh service '%s' with ttl to clientv3 failed: %s", service, err.Error())
	}

cli.KeepAlive返回的<-chan *LeaseKeepAliveResponse 没有消费，会一直发送keep alive requests,虽然不影响功能但是影响性能

watcher.go
return []*naming.Update{{Op: naming.Delete, Addr: string(ev.Kv.Value)}}, nil
当服务从etcd下线，客户端watch检测到删除事件，但是其实删除事件中并未携带删除的值，只携带了键，所以ev.Kv.Value是一个空字符串。这时候在 google.golang.org/grpc/balancer.go 185L 会与本地的地址列表匹配不上，导致并未执行命名地址列表的删除操作

1.本例子中是网关是只有一个服务的，但是如果我有多个服务，网关的代码应该如何编写，grpc是如何确定要选择那个路由的。

2.这行代码中的第二个参数为什么是"://authority/",有什么含义吗

conn, err := grpc.DialContext(ctx, r.Scheme()+"://authority/"+*svc, grpc.WithInsecure(), grpc.WithBalancerName(roundrobin.Name), grpc.WithBlock())

现在etcd包的结构已经混乱了，源码里引用的是go.etcd.io的包，但是这个网站上的包下不下来。这导致github上git下来的代码是乱的，import都找不到

现在应该要这样。。。。于是自己创建路径手动移动，建议你把这个写出来提醒一下大家！！很无语的。。

在项目 /cmd/cli/cli.go里面有cancel()方法，而且grpc.DialContext也继承了上面创建的上下文，如果提前执行cancel，那grpc的连接不是和上面那个上下文一样就会被cancel取消吗，不知道放在这里的作用是什么，是不是defer cancel（）更好

你好，刚刚接触 grpc的lb，不能理解在client端做负载均衡的设计，按照你的demo,比如我现在有10个服务节点，10000个client，岂不是每个client都要建立10个TCP链接，而每次只用一个链接来请求服务，每个服务端都要有10000个TCP链接，而这10000个链接平均下来只有1/10的链接是活跃的（如果使用轮询的话），这不是很耗费资源么？希望能得到回复哈，十分感谢。

如题

官方文档

// KeepAlive keeps the given lease alive forever. If the keepalive response
// posted to the channel is not consumed immediately, the lease client will
// continue sending keep alive requests to the etcd server at least every
// second until latest response is consumed.
KeepAlive使给定的租约永远活着。
如果发布到通道上的keepalive响应没有立即被消耗，
租赁客户端将继续向etcd服务器发送keep alive请求，
至少每秒钟一次，直到最新的响应被消耗掉。

如果不进行读取，将会以每秒一次的频率进行需约。

部分方法Deprecated
r.cc.NewAddress(addrList)
请问大佬还有更新计划吗？

context deadline exceeded