go-micro

go-micro线上部署,注册服务到etcd

月盾
线上部署 在线上部署就不能使用go run main.go命令了,需要打包编译成可执行文件。 linux系统需要这样编译:GOOS=linux go build -o service main.go,就是在windows系统上进行交叉编译,可根据自己服务器情况修改参数。 go build -o service main.go go build -o api api/api.go 线上的restful api也不能使用micro api了。需要选择适合自己的web服务框架,在web服务中调用api服务。 etcd启动 线上etcd和本地启动有区别,如果etcd是单独的服务器,那么在不加任何参数的情况下直接启动,那基本是调不通的。 $ ./service --registry=etcd --registry_address=xx.xx.xx.xx:2379 2020-03-17 17:04:42 Starting [service] go.micro.srv.user 2020-03-17 17:04:42 Server [grpc] Listening on [::]:48493 2020-03-17 17:04:42 Registry [etcd] Registering node: go.micro.srv.user-f32a2950-8e59-44d4-ac86-f4e1ec103395 {"level":"warn","ts":"2020-03-17T17:04:47.849+0800","caller":"clientv3/retry_interceptor.go:61","msg":"retrying of unary invoker failed","target":"endpoint://client-e45decee-12bf-4a9b-a7ab-f92eece39420/xx.xx.xx.xx:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest connection error: connection error: desc = \"transport: Error while dialing dial tcp xx.

go-micro v2弃用了consul作为默认的服务发现

月盾
很遗憾,go-micro v2版本不再使用consul作为服务发现中间件,官方文档也没有consul相关的文档,而是默认改用了mdns,生产推荐etcd。 问题:I can’t set registry with consul 解答:《Deprecating Consul in favour of Etcd》 超过4年的时间,Consul一直是Micro的默认服务发现系统之一,为我们提供了良好的服务。实际上,从一开始,它就是用于注册表的默认机制以及入门所需的唯一基础依赖项。 从那时起,世界在不断发展,原生云技术也在不断发展。我们发现了许多与使用Consul的方式有关的问题。这不是对Consul的打击,而是对我们的用例的反思,以及对继续前进的需求。 例如,我们将元数据和服务端点信息进行二进制编码,压缩和base64编码,然后再将它们存储为Consul标签,因为没有其他方法可以这样做。我们还非常严重地滥用Consul的分布式属性,这导致了许多关于raft共识的问题。 不幸的是,我们发现现在该继续前进了。 自2014年以来,Kubernetes真正成为了容器编排和基础服务平台中的一支计算力。因此,etcd成为了他们选择的键值存储的一种,它是基于raft共识构建的分布式键值存储。它已经发展到可以满足kubernetes的规模需求,并且已经以其他开源项目所没有的方式经过了实战测试。 Etcd还是用于二进制数据的非常标准的Get / Put / Delete存储,这意味着我们可以轻松地编码和存储服务元数据,而不会出现零问题。它对所存储数据的格式没有意见。 过去一周中,我们已将etcd迁移为Micro中的默认服务发现机制之一,并将在未来几周内弃用Consul。这是什么意思?好吧,我们将领事移交给我们社区维护的go-plugins存储库,并专注于支持etcd。 我们知道许多用户正在使用Consul,这可能会导致中断。对我们来说,这是通往v2的重大突破,因此我们的下一个发行版将被标记为v2。您可以放心,您的v1发行版将继续按原样运行,但希望我们发布的下一个发行版是micro v2.0.0。 参考项目:micro-service