上海市大数据股份|这些姿势掌握起来,微服务越来越火=Consul越来越火( 二 )


这个架构的优势:
Consul节点服务器与应用服务器隔离 , 互相干扰少;
不用每台主机都部署Consul , 方便Consul的集中管理;
某个ConsulClient挂掉的情况下 , 注册到其上的服务仍有机会被访问到 。
但也需要注意其缺点:
引入更多技术栈:负载均衡的实现 , 不仅要考虑ConsulClient的负载均衡 , 还要考虑负载均衡本身的单点问题 。
Client的节点数量:单个Client如果注册的服务太多 , 负载较重 , 需要有个算法(比如hash一致)合理分配每个Client上的服务数量 , 以及确定Client的总体数量 。
服务发现要过滤掉重复的注册 , 因为注册到了多个节点会认为是多个部署(DNS接口不会有这个问题) 。
是否可以只有Server?
这个问题的答案还是有关服务数量的问题 , 首先Server的节点数量不是越多越好 , 3个或者5个是推荐的数量 , 数量越多数据同步的处理越慢(强一致性);然后每个节点可以注册的服务数量是有上限的 , 这个受限于软硬件的处理能力 。 所以如果你的服务只有10个左右 , 只有Server问题是不大的 , 但是这时候有没有必要使用Consul呢?因此正常使用Consul的时候还是要有Client才好 , 这也符合Consul的反熵设计 。
大家可以将这个部署架构与前文提到的普适架构对比下 , 看看哪个更适合自己 。
【上海市大数据股份|这些姿势掌握起来,微服务越来越火=Consul越来越火】文章部分素材来源:分布式实验室


推荐阅读