ZooKeeper、Doozerd、Etcd在架构上都非常相似,它们都有服务节点(server node),而这些服务节点的 *** 作都要求达到节点的仲裁数(通常,节点的仲裁数遵循的是简单多数原则)。此外,它们都是强一致性的,并且提供各种原语。通 过应用程序内部的客户端lib库,这些原语可以用来构建复杂的分布式系统。
Consul在一个单一的数据中心内部使用服务节点。在每个数据中心中,为了Consule能够运行,并且保持强一致性,Consul服务端需要仲裁。然而,Consul原生支持多数据中心,就像一个丰富gossip系统连接服务器节点和客户端一样。
当提供K/V存储的时候,这些系统具有大致相同的语义,读取是强一致性的,并且在面对网络分区的时候,为了保持一致性,读取的可用性是可以牺牲的。然而,当系统应用于复杂情况时,这种差异会变得更加明显。
这些系统提供的语义对开发人员构建服务发现系统很有吸引力,但更重要的是,强调开发人员要构建这些特性。ZooKeeper只提供一个原始的 K/V值存储,并要求开发人员构建他们自己的系统来提供服务发现功能。相反的是,Consul提供了一个坚固的框架,这不仅仅是为了提供服务发现功能,也 是为了减少推测工作和开发工作量。客户端只需简单地完成服务注册工作,然后使用一个DNS接口或者>
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)