java grpc服务注册与发现_战旗直播基于consul服务注册与发现的GRPC服务实战与感想...

前言

鄙人关注consul也有一段时间了，从2017年开始了解它的一些特性，它能帮助解决哪些问题，然后怎么应用到微服务中去。随着时间的推移，微服务的发展也是非常的迅速，可以说日新月异，每天都在变化。consul工具所提供的功能也在不断地新增和完善。OK，有些扯远了，咱们还是回到主题上来吧。

在微服务领域有个重要的概念——服务注册与发现。google或baidu一下，会发现有大量的关于服务注册发现的文章、博客等，有基于consul的、也有基于etcd和zoomkeeper的，每个工具都有自己的特点和优势，也有一定的相似性，比如它们都可以实现服务注册与发现，也都可以实现kv存储等。但是它们也有一定的区别，比如consul重点是服务注册与发现，其次是kv存储；像etcd重点是处理kv存储的功能，在kv存储上来实现服务的注册与发现。侧重点不一样，感兴趣的朋友可以去google或baidu一下，这里就不在叙述了。由于侧重点不同，依据战旗直播业务的实际情况，选择了consul来实现战旗后端的服务注册与发现。

consul能解决的问题

服务注册(注销)与发现

节点/服务监控

KV存储——业务服务配置统一管理

consul-template

ACL

DNS

其他

consul集群部署

依据consul的文档，consul集群中需要部署两种类型的节点：server节点和client节点。server节点推荐部署奇数个节点，有利于leader的选举过程快速的结束(偶数个节点可能需要多个选举过程才能选举出leader)。这里有几个概念：集群，leader选举，对这些原理感兴趣同学可以去google下.

战旗部署了5个server节点，其他节点都是client,也就是说每台服务上都有一个node。然后，战旗的服务通过localhost:8500地址向consul集群注册自己。部署结构1如下图所示：

思考：这样的部署结构存在一定的缺陷，如果某个节点的consul挂了，会直接影响该节点上的所有应用服务，应为它们都是通过localhost来跟consul进行通讯的。那怎么预防这样的情况呢？

这时备选方案plan B出台了.

通过coreDNS获取consul集群状况，来自动配置一个内部DNS路由条目。当访问consul服务时，自动路由到consul集群中的某个节点。

也可以部署两个nginx(主备)，由nginx路由到consul集群中的某个节点。

如果您采用的是k8s环境，那恭喜您，可以省略很多工作来，直接在k8s中部署一个service来指向consul集群。

部署结构2如下图所示：