Go语言由Google公司开发，并于2009年开源，相比Java/Python/C等语言，Go尤其擅长并发编程，性能堪比C语言，开发效率肩比Python，被誉为“21世纪的C语言”。
创新互联是一家专业从事成都网站设计、成都网站建设、网页设计的品牌网络公司。如今是成都地区具影响力的网站设计公司,作为专业的成都网站建设公司,创新互联依托强大的技术实力、以及多年的网站运营经验,为您提供专业的成都网站建设、营销型网站建设及网站设计开发服务！
Go语言在云计算、大数据、微服务、高并发领域应用应用非常广泛。BAT大厂正在把Go作为新项目开发的首选语言。
Go语言能干什么?
1、服务端开发：以前你使用C或者C++做的那些事情，用Go来做很合适，例如日志处理、文件系统、监控系统等;
2、DevOps：运维生态中的Docker、K8s、prometheus、grafana、open-falcon等都是使用Go语言开发;
3、网络编程：大量优秀的Web框架如Echo、Gin、Iris、beego等，而且Go内置的 net/http包十分的优秀;
4、Paas云平台领域：Kubernetes和Docker Swarm等;
5、分布式存储领域：etcd、Groupcache、TiDB、Cockroachdb、Influxdb等;
6、区块链领域：区块链里面有两个明星项目以太坊和fabric都使用Go语言;
7、容器虚拟化：大名鼎鼎的Docker就是使用Go语言实现的;
8、爬虫及大数据：Go语言天生支持并发，所以十分适合编写分布式爬虫及大数据处理。
consul是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框架（类似zookeeper）、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个节点为以下三种状态的一种：
上图来源于 Consul 官网，很好的解释了 Consul 的工作原理。consul是一个服务管理软件，主要功能如下：
有些人可能对服务注册和发现还没有概念，有些人可能使用过其他服务发现的工具，比如 ZooKeeper，etcd，会有一些先入为主的经验。本文谈一下 Consul 做服务发现的实践和原理。
下面这张图描述了服务发现的完整流程，先大致看一下：
首先需要有一个正常的 Consul 集群，有 Server，有 Leader。这里在服务器 Server1、Server2、Server3 上分别部署了 Consul Server。
假设他们选举了 Server2 上的 Consul Server 节点为 Leader。这些服务器上最好只部署 Consul 程序，以尽量维护 Consul Server 的稳定。
然后在服务器 Server4 和 Server5 上通过 Consul Client 分别注册 Service A、B、C，这里每个 Service 分别部署在了两个服务器上，这样可以避免 Service 的单点问题。
服务注册到 Consul 可以通过 HTTP API（8500 端口）的方式，也可以通过 Consul 配置文件的方式。
Consul Client 可以认为是无状态的，它将注册信息通过 RPC 转发到 Consul Server，服务信息保存在 Server 的各个节点中，并且通过 Raft 实现了强一致性。
最后在服务器 Server6 中 Program D 需要访问 Service B，这时候 Program D 首先访问本机 Consul Client 提供的 HTTP API，本机 Client 会将请求转发到 Consul Server。
Consul Server 查询到 Service B 当前的信息返回，最终 Program D 拿到了 Service B 的所有部署的 IP 和端口，然后就可以选择 Service B 的其中一个部署并向其发起请求了。
如果服务发现采用的是 DNS 方式，则 Program D 中直接使用 Service B 的服务发现域名，域名解析请求首先到达本机 DNS 代理，然后转发到本机 Consul Client，本机 Client 会将请求转发到 Consul Server。
Consul Server 查询到 Service B 当前的信息返回，最终 Program D 拿到了 Service B 的某个部署的 IP 和端口。
图中描述的部署架构笔者认为是最普适最简单的方案，从某些默认配置或设计上看也是官方希望使用者采用的方案，比如 8500 端口默认监听 127.0.0.1，当然有些同学不赞同，后边会提到其他方案。
consul必须启动agent才能使用，有两种启动模式server和client，还有一个官方自带的web ui。server用与持久化服务信息，集群官方建议3或5个节点。client只用与于server交互。ui可以查看集群情况的。
server模式启动如下：
参数解释：
client启动如下：
client节点可以有多个，自己根据服务指定即可。
ui启动如下:
参数解释：
集群创建完成后：
使用一些常用的命令检查集群的状态：
可以在raft：stat看到此节点的状态是Fllower或者leader
新加入一个节点有几种方式；
访问ui：
端口：
8300：consul agent服务relplaction、rpc（client-server）
8301：lan gossip
8302：wan gossip
8500：http api端口
8600：DNS服务端口
输入 consul agent -dev
在浏览器中输入 就可以启动web查看
consul注册服务，有三种方式，
方式一：通过配置文件的方式静态注册
创建文件夹/etc/consul.d
.d代表有许多配置文件在里面
vim /etc/consul.d/jetty.json 内容如下：
重启consul，并将配置文件的路径给consul（指定参数：-config-dir /etc/consul.d）
方式二：通过HTTP API接口来动态注册
直接调用/v1/agent/service/register接口注册即可，需要注意的是：http method为PUT提交方式。如：
注意，这种方式，和上面的注册方式有一点不一样，body的参数，是上面service的值，这点需要注意
方式三：使用程序实现服务的注册和发现（Java）
首先加入consul client的依赖
服务发现
consul支持两种方式实现服务发现，一种是通过http API来查询有哪些服务，另外一种是通过consul agent 自带的DNS（8600端口），域名是以NAME.service.consul的形式给出，NAME即在定义的服务配置文件中，服务的名称。DNS方式可以通过check的方式检查服务。
服务间的通信协议
Consul使用gossip协议管理成员关系、广播消息到整个集群，他有两个gossip pool（LAN pool和WAN pool），LAN pool是同一个数据中心内部通信的，WAN pool是多个数据中心通信的，LAN pool有多个，WAN pool只有一个。
;utm_campaign=client_sharewxshare_count=1timestamp=1546144777app=news_articleutm_source=weixiniid=55667270026utm_medium=toutiao_androidgroup_id=6639493728086000142
Consul是由HashiCorp基于Go语言开发的支持多数据中心的分布式高可用服务发布和注册软件, 采用Raft算法保持服务的一致性, 且支持健康检查.
和Eureka的侵入式服务中心不同的是, Consul是以独立的软件形式运行, 对项目侵入性小, 更方便部署.
上图为多机房数据中心部署, 每个数据中心至少三台Consul, 一台LEADER, 另外的两台是FOLLOWER.
代理是Consul集群上每个成员的守护进程, 它是由consul agent命令开始运行. 代理能够以客户端或服务器模式运行. 由于所有节点都必须运行代理, 所以将节点引用为客户端或服务器更为简单, 但还有其他实例的代理. 所有代理可以运行DNS或HTTP接口, 并负责运行检查和保持服务同步.
客户端可以将所有RPC请求转发到服务器的代理. 客户端是相对无状态的. 客户端执行的唯一后台活动是LANgossip池. 它消耗最小的资源开销和少量的网络带宽.
服务器端是具有扩展的功能的代理, 它主要参与维护集群状态, 响应RPC查询, 与其他数据中心交换WAN gossip, 以及向leader节点或远程数据中心转发查询.
虽然数据中心的定义似乎很明显, 但仍有一些细微的细节必须考虑. 比如说, 在EC2中, 多个可用中心 (EC2和AZ是AWS里的概念, 不了解的话可以去看看AWS文档) 是否应该被认为是一个单个的数据中心呢? 我们将一个数据中心定义为一个私有, 低延迟和高带宽的网络环境, 这不包括通过公共互联网的通信. 但是为了我们的目的, 单个EC2区域内的多个可用区域将被视为单个数据中心的一部分.
在我们的文档中, "一致性"的意思是对于被选举出的leader以及事物的顺序的认同. 因为这些事件被应用到有限状态机上, 我们对一致性的定义又暗含了复制备份的状态机的一致性.
consul是建立在Serf之上的, 它提供了一个完整的gossip协议, 用在很多地方. Serf提供了成员管理, 故障检测和事件广播的功能. Gossip的节点到节点之间的通信使用了UDP协议.
指在同一局域网或数据中心的节点上的LAN Gossip池. Client到Server会通过Lan Gossip, 所有的节点都在Gossip pool中
指包含服务器的WAN Gossip池, 这些服务器在不同的数据中心, 通过网络进行通信.
以开发模式启动: consul agent -dev, 如果需要Web界面的话加-ui即可, 集群的LAN服务默认启动在8301端口上, WAN服务默认启动在8302端口上, Web服务默认端口是8500, DNS服务默认端口是8600, gRPC服务默认端口是8502
默认是以server角色启动的, 启动后用consul members可以查看服务下的节点信息, 或者通过HTTP接口请求 也可以看到节点信息数据以json形式返回.
使用dig命令可以查看consul中DNS服务的一些信息, 命令如: dig @127.0.0.1 -p 8600 nodeName
一般情况下consul会在启动时通过参数的形式进行配置, 但这样子比较麻烦, 我们通过在/etc/consul.d目录下来新建配置文件的形式, 在每次启动时加载配置文件来进行启动.
consul的配置信息可以在 查看, 其中部分选项如下:
按照惯例, 我们将配置文件放在/etc/consul.d/目录下, 分别在几个机器上创建该目录. 在以bootstrap模式启动的server1上, 我们创建/etc/consul.d/bootstrap和/etc/consul.d/server目录, 在server2和server3上我们创建/etc/consul.d/server目录, 在agent上, 我们创建/etc/consul.d/agent目录.
server1的bootstrap目录下的配置文件config.json如下:
其他两台服务器中server目录下的配置文件config.json如下:
代理服务器中agent目录下的config.json如下:
这样, 首先启动server1上的consul: consul agent -config-dir /etc/consul.d/bootstrap, 然后依次启动server2, server3上的consul:consul agent -config-dir /etc/consul.d/server. 这样, 三个consul server就组成了一个cluster. 此时server1上的consul运行在bootstrap状态下. 可以在不与server2以及server3商议的情况下直接执行决议, 此时我们终结server1上运行的consul, 并执行consul agent -config-dir /etc/consul.d/server, 让server1以普通server的身份重新加入cluster. 最后启动agent模式 consul agent -config-dir /etc/consul.d/agent.
** 注意: encrypt可以使用consul keygen命令来生成, 所有服务器上需要配置一样, 如果因为哪里配置错误导致启动失败, 修改后还报失败的话, 可以尝试删除$data_dir/serf/local.keyring后重新启动 **
在需要部署服务的机器上同样创建/etc/consul.d/, 然后把不同的服务分开不同的目录, 或者就直接在此目录下创建json配置文件, 如: web1.json, web2.json等.
然后再通过consul agent指定配置文件的方式启动服务, 可以直接在配置文件中指定要注册的服务, 也可以在启动后使用consul join命令来主动注册服务, 这样再次登录到web管理界面就可以发现我们新建的服务了.
Q: 什么是bootstrap模式?
A: 使用该模式启动的server端会自动把自己选择为leader, 在搭建集群时为了方便会预先设置一台服务器为bootstrap启动
重庆分公司
重庆分公司
