go语言注册服务 go语言官方中文文档

分布式架构的注册中心，该怎么选？

互联网架构下，大部分系统已经转型分布式。其中服务注册发现中心，分布式服务中非常重要go语言注册服务的组成部分。按需选择合适的注册中心，也变的尤为重要。

Eureka是SpringCloud全家桶中非常重要的一个组件，主要是实现服务的注册和发现。Eureka做到go语言注册服务了CAP理论中的AP，强调服务的高可用性。实现中分Eureka Server和Eureka Client两部分。

Eureka客户端会向Eureka注册中心注册为服务，并通过心跳来更新它的服务租约。同时也可以从服务端查询当前注册的服务信息并把他们缓存到本地并周期性的刷新服务状态。若服务集群出现分区故障时，Eureka会转入自动保护模式，允许分区故障的节点继续提供服务；若分区故障恢复，集群中其他分区会把他们的状态再次同步回来。

SpringCloud对其做了非常好的集成封装，是官方推荐的注册中心。

Zookeeper是大数据Hadoop中的一个分布式调度组件，强调数据一致性和扩展性，可用于服务的注册和发现。她是dubbo中默认的服务注册中心，也是目前使用最广泛的分布式服务发现组件。注重CAP理论中的CP。

Consul是一个高可用的分布式服务注册中心，由HashiCorp公司推出，Golang实现的开源共享的服务工具。Consul在分布式服务注册与发现方面有自己的特色，解决方案更加“一站式”，不再需要依赖其他工具。

1、通过HTTP接口和DNS协议调用API存储键值对，使服务注册和服务发现更容易；

2、支持 健康 检查，可以快速的告警在集群中的操作

3、支持key/value存储动态配置

4、支持任意数量的区域

ETCD是一个高可用的分布式键值数据库，可用于共享配置、服务的注册和发现。ETCD采用Raft一致性算法，基于Go语言实现。ETCD作为后起之秀，又非常大的优势。

1、基于HTTP+JSON的API，使用简单；

2、可选SSL客户认证机制，更安全；

3、单个实例支持每秒千次写操作，快速。

4、采用Raft一致性算法保证分布式。

consul入门篇

consul是google开源go语言注册服务的一个使用go语言开发的服务发现、配置管理中心服务。内置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

go语言聊天室实现（七）websocket收消息设置

上一节中，我们为每个连接都创建了一个goroutine来读取其中的消息，现在我们将这个读取消息的方法实现一下。

我们在application目录下新建controllers目录，并在其中创建一个MessageController.go文件。

首先我们新建一个MessageController的结构体，内容如下

这个结构体包括两个内容，一个是我们将连接放在数组之后，返回的索引，另一个是连接本身.

这个是具体的方法。

我们首先设置了一下读消息的大小、超时时间以及超时后需要的操作。

超时时间如果设置为0,那么就是永不超时。之前在这里直接写0，被告知需要传一个time.Time类型的数据。最终谷歌后才得到了这个值time.Time{}为"0001-01-01 00:00:00 +0000 UTC"。

我们将用户手法消息的内容定义为一个结构体，然后将用户的订阅信息的json通过json.unmarshal转换成这个结构体。

之后的switch操作与我们在Swoole中的操作基本雷同，在查询到login之后，调用service中 的login方法来进行注册。

下一节中我们再介绍具体的注册逻辑。

微服务架构之服务注册与发现(一)

一、服务注册中心的由来

假如没有服务注册中心，go语言注册服务我们会干些什么事情呢？

在传统行业的项目架构中以下的方案最为常见了：

这种架构开发、部署都是最简单的，一般适用于中小企业访问量并不是太多的情况下，各个系统服务一台机器就搞定了。系统之间的调用也是拿到对方的IP+PORT直接连接。

接下来可能因为应用B开始访问量大了，单台机器已经不能满足go语言注册服务我们的需求，于是一些反向代理工具应运而出，其中比较常见的有Apache、Nigix，架构演变为：

相比之前的应用B的单台机器访问，这种nginx代理的方式减轻了服务器的压力，但是可能会出现Nginx挂了，那么整个服务也不可用，于是又来了这么一套架构：

这样看方案算是完美了吧。然后事情并不是想象的那么一帆风顺，这还只是应用A调用一个应用B，如果应用A调用的可能是应用B、C、D、E...，这种完全就不知道他后面到底还想干嘛，这种架构看似可以，但是绝对会累死运维的（nginx的配置将会非常混乱，直接导致运维不干了）。

服务注册中心干些什么事情呢？

上面提到的那种靠人力（主要是运维干的事情）比较繁琐，还不好维护，有这么几点不方便：应用服务的地址变了、双十一搞活动服务器新增等等。那么我们可以有这么的一种架构：

    服务注册中心主要是维护各个应用服务的ip+port列表，并保持与各应用服务的通讯，在一定时间间隔内进行心跳检测，如果心跳不能到达则对服务IP列表进行剔除，并同时通知给其它应用服务进行更新。同样要是有新增的服务进来，应用服务会向注册中心进行注册，服务注册中心将通知给其它应用进行更新。每个应用都有需要调用对应应用服务的地址列表，这样在进行调用时只要处理客户负载杂均衡即可。

二、微服务注册中心

1.Zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

上面的话直接摘抄百度百科的内容，国内很多公司做分布式开发最初的选型大部分都是采用dubbo框架。dubbo框架注册中心主要使用zookeeper。zookeeper服务端与客户端的底层通讯为netty。zookeeper采用CAP理论中的CP，一般集群部署最少需要3台机器。

2.Euraka

先来看一下euraka的架构图：

Register：服务注册

当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。

Renew：服务续约

Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。

Fetch Registries：获取注册列表信息

Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。

Cancel：服务下线

Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：

DiscoveryManager.getInstance().shutdownComponent()；

Eviction 服务剔除

在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。

自我保护机制：

既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了 异常，所有的服务都没能够进行续约，Eureka Server就把所有的服务都剔除了，这样显然不太合理。所以，就有了 自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下， Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eureka.server.enableself-preservation: false)

3.Consul

consul推荐的架构图：

Consul不像Euraka的部署那么简单，他是go语言开发的，需要运维单独部署，有提供java的客户端连接，采用的是CAP的CP。

4.Nacos

    Euraka是Spring Cloud Netflix早期版本中推荐使用的，后来euraka1.0版本不再维护，euraka2.0已经闭源，导致很多新项目基于Spring Cloud Netflix 开发的选型变迁为Consul.

Nacos是阿里开源的服务注册中心，它可以与spring cloud aliaba集成使用。

Nacos的官方介绍：

    Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。

    Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。

Nacos 地图

Nacos 生态图

如 Nacos 全景图所示，Nacos 无缝支持一些主流的开源生态，例如

Spring Cloud

Apache Dubbo and Dubbo Mesh TODO

Kubernetes and CNCF TODO

三、服务注册与发现技术选型

以下是来自网上的一个分享：

除了上述的几种以外，笔者更推荐使用Nacos作为服务注册中心。

推荐理由：

Nacos服务注册表结构Mapnamespace, Mapgroup::serviceName, Service采用多层次Map结构，控制的颗粒度更细，支持金丝雀模式发布，心跳同步机制也更快速，服务更新更及时。

go语言注册服务的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于go语言官方中文文档、go语言注册服务的信息别忘了在本站进行查找喔。