Go语言注册到nacos go语言nil

三、微服务注册到Nacos

将各个微服务注册到Nacos，方便调用与配置

ps：启动可能会报错： NACOS SocketTimeoutException httpGet] currentServerAddr:，error超时 ，因为找不到配置的nacos远程服务。若配置没有错误，则要修改 application.yml 为 bootstrap.yml ，因为：

所以建议：若要在Nacos中管理配置文件，服务中直接使用 bootstrap.yml（bootstrap.properties） 来放nacos的配置。

相关问答

Q1: Nacos服务的注册与心跳

一个服务实例需要注册到多个nacos命名空间，利用nacos的命名空间实现服务的逻辑隔离。

在多租户场景下，服务实例需要区分所属租户，且要保证服务间正常调用。

因此需要实现：

为完成以上的背景要求，使用nacos做注册中心、配置中心，记录各个服务实例信息（实例元数据做区分），动态修改服务的配置项.

在各个服务上自定义：注册、心跳、LB逻辑

nacos注册相关的接口

接口只有一个实现类

注册的逻辑由NamingProxy对象实现

初始化注册需要的参数

nacos集群场景下的负载逻辑处理

调用nacos的openAPI

在注册服务的逻辑出，添加了服务的心跳信息

服务的心跳信息由定时任务触发

调用nacos的openAPI以实现心跳

Q2: 什么是Nacos？Nacos注册配置中心介绍

英文全称Dynamic Naming and Configuration Service，Na为naming/nameServer即注册中心,co为configuration即注册中心，service是指该注册/配置中心都是以服务为核心。服务在nacos是一等公民

Nacos注册中心分为server与client，server采用Java编写，为client提供注册发现服务与配置服务。而client可以用多语言实现，client与微服务嵌套在一起，nacos提供sdk和openApi，如果没有sdk也可以根据openApi手动写服务注册与发现和配置拉取的逻辑

Nacos服务领域模型主要分为命名空间、集群、服务。在下图的分级存储模型可以看到，在服务级别，保存了健康检查开关、元数据、路由机制、保护阈值等设置，而集群保存了健康检查模式、元数据、同步机制等数据，实例保存了该实例的ip、端口、权重、健康检查状态、下线状态、元数据、响应时间。这些数据的作用会在第三章讲到

服务注册方法：以Java nacos client v1.0.1 为例子，服务注册的策略的是每5秒向nacos server发送一次心跳，心跳带上了服务名，服务ip，服务端口等信息。同时 nacos server也会向client 主动发起健康检查，支持tcp/http检查。如果15秒内无心跳且健康检查失败则认为实例不健康，如果30秒内健康检查失败则剔除实例。

不同的命名空间逻辑上是隔离的，不特殊设置的情况下，服务不会跨命名空间请求，命名空间主要的作用是区分服务使用的范围，比如开发、测试、生产、灰度可以分别设置四个命名空间来互相隔离。

以springcloud为例，首先用maven导入nacos clinet的依赖：

先导入springcloud的alibaba-nacos-config和alibaba-nacos-discovery两个依赖，这两个依赖是用于nacos clinet与cloud结合的工具，0.2.x对应springboot 2.x.x ,0.1.x对应springboot 1.x.x。这两个组件可以和各种版本的nacos-client结合。把其中的nacos-clinet依赖给排除，引入想要引入的nacosclinet版本，如下：

在bootstrap.properties上添加配置中心的配置

在application-xxx.properties新增如下配置

如果springboot启动类没有 @EnableDiscover 注解则加上

完成如上更改，即可使用Nacos注册/配置服务

演示：

使用Feign、Ribbon均可，在这不做过多介绍

普通application参数在配置中心直接配置皆可，如果需要可以动态刷新的配置，需要在相应类上加上 @RefreshScope 注解,示例如下，当在nacos配置中心更改配置后，方法getId的值也会刷新。

配置中心参数修改/设置

如下两张图：在nacos控制台的 配置管理-配置列表 中顶部选择相应的命名空间，点击列表右上角的加号新增配置，Data ID 为 项目名-{spring.profiles.active}.properties,Group如果在bootstrap.properties中不指定则填默认的DEFAULT_GROUP，描述写该配置的描述，配置内容填写Properties格式或者Yaml格式。

在控制台的 服务管理-服务列表 选择一个服务点击详情，在下方的集群列表可以看到有上线/下线按钮，点击即可以对该实例执行上线/下线操作，下线后的实例不会被请求

可以通过手动配置权重来控制流量，当一个集群内两个实例，权重越高，到达该实例的请求比例越多。

权重的初始值是1

保护阈值的范围是0~1

服务的健康比例=服务的健康实例/总实例个数

当服务健康比例=保护阈值时候，无论实例健不健康都会返回给调用方

当服务健康比例保护阈值的时候，只会返回健康实例给调用方

在 服务管理-服务列表 选择一个服务点击详情可以配置

Q3: nacos与k8s 服务注册与发现

首先先说说比较常规的nacos的服务注册与发现。

用spring cloud为例，ali集成了spring-cloud和nacos，因此加入以下依赖

然后我们配置nacos server的地址，并通过 Spring Cloud 原生注解 @EnableDiscoveryClient 开启服务注册发现功能，在 application.properties 中配置 Nacos server 的地址，启动服务之后，服务会将自己的元数据注册到nacos上，最主要的是服务名，ip，端口，namespace等。服务注册成功后，服务将与注册中心维持心跳，心跳机制可以保证当服务中的某个实例不健康之后，服务中心将该实例剔除，以保证服务正常提供服务。

当服务注册上去之后，消费者就可以调用服务了，那么消费者是怎么发现服务的呢，消费者向注册中心订阅某个服务，并提交一个监听器，当服务提供方实例发生变化，比如ip变了，消费者会收到通知，更新本地的服务列表，nacos client获取到服务列表之后，通过负载均衡，spring一般都是结合ribbon，获取一个可用的实例，得到它的ip和端口号，以及服务路由，然后进行调用。

由于客户端将获取到的服务实例保存在一个 map 中，而该 map 中的内容是由调度任务定时去更新的，存在一定的延时。

一般来说，在k8s中一个服务有多个实例，是通过pod去部署的，多个实例则有多个pod，每一个pod都会有自己的容器组ip，在集群内，直接通过这个容器ip和端口是可以访问服务的，但是每次服务重启，也就是pod销毁重建的时候，ip也会改变。k8s并没有一个注册中心让我们注册实例的ip和端口到服务下面，并且其他服务通过这个注册中心去发现服务。在k8s里是通过service去实现的。

这是一个service定义的例子， 这个 Service 将被指派一个 IP 地址（通常称为 “Cluster IP”），上述的selector代表这个service代理的pod选择器，也就是说具有这个app标签的选择器的一组pod，可以通过service这个统一的访问入口去做服务发现。

比如说我们现在有一组pod叫base-opc-biz

查看它的service

信息包括 ：name，namespace，selector，labels等基础信息

type 是ClusterIP,IP这个值 即是在集群内部，其他所有的pod都可以通过这个虚拟的ip来访问service，service就会将这个请求负载均衡到后端的所有pod上去。

Port 是访问service的端口

TargetPort 是代理的pod的端口

Endpoints 是当前service代理的所有pod的ip地址，当某个pod被销毁重建的时候，这里的ip地址也会随之变化

集群内其他pod访问我们创建的service有三种方式：

1、 通过clusterIp+port直接去访问

2、 同一个namespace直接访问服务名，不同的 namespace 里面，我们可以通过 service 名字加“.”kube-dns可以解决Service的发现问题，k8s将Service的名称当做域名注册到kube-dns中，通过Service的名称就可以访问其提供的服务。

Kubernetes 集群中部署了一套 DNS 服务，通过 kube-dns 的服务名暴露 DNS 服务。您可执行以下命令查看 kube-dns 的服务详情。

kubectl get svc kube-dns -n kube-system

服务后端是两个名为 coredns（下文会介绍 CoreDNS 解析原理） 的 Pod。您可执行以下命令查看 coredns 的 Pod 详情。

kubectl get deployment coredns -n kube-system

3、 通过环境变量访问，在同一个 namespace 里的 pod 启动时，kubelet 会为每个活跃的 Service 添加一组环境变量，会把 service 的一些 IP 地址、端口，以及一些简单的配置，通过环境变量的方式放到 K8s 的 pod 里面。因此我们可以通过环境变量去直接访问。

上面三种方式都是在k8s集群内部互相访问的情况，对我们应用的某些部分，可能希望将 Service 暴露在一个外部 IP 地址上。 Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。

我们看下我们原本的service 的yaml文件

把type改成NodePort 或者 LoadBalancer

然后重新创建service，再看看信息

发现有了EXTERNAL-IP，这个ip是一个公网的ip，因此我们就不只可以在集群上访问我们的服务了。

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

一、服务注册中心的由来

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

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

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

接下来可能因为应用B开始访问量大了，单台机器已经不能满足我们的需求，于是一些反向代理工具应运而出，其中比较常见的有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语言注册到nacos和go语言nil的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。