使用Consul提供的DNS服务

使用Consul提供的DNS服务

使用Consul提供的DNS服务

• 前言
• 服务发现软件以及特性对比
• Consul 介绍
• • Consul 的优势
  • 特性
  • Consul 角色
• FQA
• • consul UI访问地址127.0.0.1改为0.0.0.0

本文部分内容摘自：
原文：.html

console 使用手册

前言

最早DNS服务器，使用的是bind应用，后面诞生了各种的服务发现的应用zookeeper、eureka、etcd、consul；而consul支持提供DNS服务，而且是分布式的架构，如果纠结该用ip还是域名，consul是一个很好的方案。

服务发现软件以及特性对比

Eureka 2.X 遇到困难停止开发了，但其实对国内的用户影响甚小，一方面国内大都使用的是 Eureka 1.X 系列，另一方面 Spring Cloud 支持很多服务发现的软件，Eureka 只是其中之一，下面是 Spring Cloud 支持的服务发现软件以及特性对比：

Consul 介绍

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案，Consul 的方案更“一站式”，内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具（比如 ZooKeeper 等）。使用起来也较 为简单。Consul 使用 Go 语言编写，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署，与 Docker 等轻量级容器可无缝配合。

Consul 的优势

• 使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft。
• 支持多数据中心，内外网的服务采用不同的端口进行监听。 多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等。 zookeeper 和 etcd 均不提供多数据中心功能的支持。
• 支持健康检查。 etcd 不提供此功能。
• 支持 http 和 dns 协议接口。 zookeeper 的集成较为复杂, etcd 只支持 http 协议。
• 官方提供 web 管理界面, etcd 无此功能。
• 综合比较, Consul 作为服务注册和配置管理的新星, 比较值得关注和研究。

特性

• 服务发现 : Consul的客户端可用提供一个服务,比如 api 或者mysql ,另外一些客户端可用使用Consul去发现一个指定服务的提供者.通过DNS或者HTTP应用程序可用很容易的找到他所依赖的服务.
• 健康检查：Consul客户端可用提供任意数量的健康检查,指定一个服务(比如:webserver是否返回了200 OK 状态码)或者使用本地节点(比如:内存使用是否大于90%). 这个信息可由operator用来监视集群的健康.被服务发现组件用来避免将流量发送到不健康的主机.
• Key/Value 存储：应用程序可用根据自己的需要使用Consul的层级的Key/Value存储.比如动态配置,功能标记,协调,领袖选举等等,简单的HTTP API让他更易于使用.
• 多数据中心：Consul支持开箱即用的多数据中心.这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域. Consul面向DevOps和应用开发者友好.是他适合现代的弹性的基础设施.

Consul 角色

• client: 客户端, 无状态, 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。
• server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通讯, 通过广域网与其* * 它数据中心通讯。 每个数据中心的 server 数量推荐为 3 个或是 5 个。
• Consul 客户端、服务端还支持夸中心的使用，更加提高了它的高可用性。

FQA

consul UI访问地址127.0.0.1改为0.0.0.0

通过设置 -client 参数来设置

consul agent -server -bootstrap-expect=1 -data-dir=/tmp/consul -node=consul -bind&#x.xxx -ui -client=0.0.0.0