近几年,随着Go语言社区逐步倒退和壮大,越来越多的公司开始尝试采纳Go搭建微服务体系,也涌现了一批Go的微服务框架,如go-micro、go-kit、Dubbo-go等,跟微服务治理相干的组件也逐步开始在Go生态发力,如Sentinel、Hystrix等都推出了Go语言版本,而作为微服务框架的外围引擎--注册核心,也是必不可缺少的组件,市面曾经有多款注册核心反对Go语言,应该如何抉择呢?咱们能够对目前支流的反对Go语言的注册核心做个比照。
图1
依据上表的比照咱们能够从以下几个维度得出结论:
- 生态:各注册核心对Go语言都有反对,然而Nacos、 Consul、Etcd 社区沉闷,zookeeper和Eureka社区活跃度较低;
- 易用性:Nacos、Eureka、Consul都有现成的管控平台,Etcd、zookeeper自身作为kv存储,没有相应的管控平台,Nacos反对中文界面,比拟合乎国人应用习惯;
- 场景反对:CP模型次要针对强统一场景,如金融类,AP模型实用于高可用场景,Nacos能够同时满足两种场景,Eureka次要满足高可用场景,Consul、Zookeepr、Etcd次要满足强统一场景,此外Nacos反对从其它注册核心同步数据,不便用户注册核心迁徙;
- 性能完整性:所有注册核心都反对健康检查,Nacos、Consul反对的查看形式较多,满足不同利用场景,Zookeeper通过keep alive形式,能实时感知实例变动;Nacos、Consul和Eureka都反对负载平衡策略,Nacos通过Metadata selector反对更灵便的策略;此外,Nacos、Eureka都反对雪崩爱护,防止因为过多的实例不衰弱对衰弱的实例造成雪崩效应。
综合下面各维度的比照,能够理解到Nacos作为注册核心有肯定的劣势,那么它对Go微服务生态的集成做得如何?接下来咱们首先摸索下Nacos是如何与Dubbo-go集成。
引言
Dubbo-go目前是Dubbo多语言生态中最炽热的一个我的项目,从2016年公布至今,曾经走过5个年头。最近,Dubbo-go公布了v1.5版本,全面兼容Dubbo 2.7.x版本,反对了利用维度的服务注册与发现,和支流的注册模型保持一致,标记着Dubbo-go向云原生迈出了要害的一步。作为驱动服务运行的外围引擎--注册核心,在切换到利用维度的注册模型后,也须要做相应的适配,本文将解析如何以Nacos为外围引擎实现利用维度的服务注册与发现,并且给出相应的实际案例。此外,本文代码基于Dubbo-go v1.5.1,Nacos-SDK-go v1.0.0和Nacos v1.3.2。
服务注册与发现架构
从架构中,咱们能够看到,与接口级别的服务注册发现不同的是,Dubbo-go的provider启动后会调用Nacos-go-sdk的RegisterInstance接口向Nacos注册服务实例,注册的服务名即为利用名称,而不是接口名称。Conusmer启动后则会调用Subscribe接口订阅该利用的服务实例变动,并对的实例发动服务调用。
图2
服务模型
图3是咱们Dubbo-go的利用维度服务发现模型,次要有服务和实例两个层级关系,服务实例的属性次要蕴含实例Id、主机地址、服务端口、激活状态和元数据。图4为Nacos的服务分级存储模型,蕴含服务、集群和实例三个档次。两者比照,多了一个集群维度的层级,而且实例属性信息可能齐全匹配。所以在Dubbo-go将应用服务实例注册到Nacos时,咱们只须要将集群设置为默认集群,再填充服务和实例的相干属性,即可实现服务模型上的匹配。此外Nacos能够将服务注册到不同的Namespace下,实现多租户的隔离。
图3
图4
服务实例心跳维持
Dubbo-go的Provider在向Nacos注册应用服务实例信息后,须要被动上报心跳,让Nacos服务端感知实例的存活与否,以判断是否将该节点从实例列表中移除。保护心跳的工作是在Nacos-SDK-go实现的,从图5代码中能够看到,当Dubbo-go调用RegisterInstance注册一个服务实例时,SDK除了调用Nacos的Register API之外,还会调用AddBeatInfo,将服务实例信息增加到本地缓存,通过后盾协程定期向Nacos发送服务实例信息,放弃心跳。当服务下线时,能够通过调用DeRegisterInstance执行反注册,并移除本地的心跳放弃工作,Nacos实例列表中也会将该实例移除。
图5
订阅服务实例变动
Dubbo-go的Consumer在启动的时候会调用Nacos-SDK-go的Subscribe接口,该接口入参如图6,订阅的时候只须要传递ServiceName即利用名和回调函数SubscribeCallback,Nacos在服务实例发生变化的时候即可通过回调函数告诉Dubbo-go。Nacos-SDK-go是如何感知Nacos的服务实例变动的呢?次要有两种形式:
- Nacos服务端被动推送,Nacos-SDK-go在启动的时候会监听一个UDP端口,该端口在调用Nacos Register API的时候作为参数传递,Nacos会记录Ip和端口,当服务实例发生变化时,Nacos会对所有监听该服务的Ip和端口发送UDP申请,推送变动后的服务实例信息。
Nacos-SDK-go定期查问,SDK会对订阅的服务实例定时调用查问接口,如果查问有变动则通过回调接口告诉Dubbo-go。作为兜底策略保障Nacos服务端推送失败后,仍能感知到变动。
图6
此外Nacos-SDK-go还反对推空爱护,当Nacos推送的实例列表为空时,不更新本地缓存,也不告诉Dubbo-go变更,防止Consumer无可用实例调用,造成故障。同时,SDK还反对服务实例信息本地长久化存储,能够保障在Nacos服务故障过程中,Consumer重启也能获取到可用实例,具备容灾成果。
范例实际
环境筹备
dubbo-go samples代码下载:https://github.com/apache/dub...,基于Nacos注册核心的利用级服务发现的hello world代码目录在 registry/servicediscovery/nacos。
图7
Nacos服务端搭建,参考官网文档:https://nacos.io/zh-cn/docs/q...,或者应用官网提供的公共Nacos服务:http://console.nacos.io/nacos...:nacos,仅供测试),或者购买阿里云服务:https://help.aliyun.com/docum...
Server端搭建
进入registry/servicediscovery/nacos/go-server/profiles文件,能够看到有dev、release和test三个文件夹,别离对应开发、测试和生产配置。咱们应用dev配置来搭建开发环境,dev文件下有log.yml和server.yml文件,上面对server.yml配置进行批改。
remote配置,这里应用公共的Nacos服务,address反对配置多个地址,用逗号宰割。params参数配置nacos-sdk的日志目录。
remote: nacos: address: "console.nacos.io:80" timeout: "5s" params: logDir: "/data/nacos-sdk/log"configCenter配置config_center: protocol: "nacos" address: "console.nacos.io:80"
配置server端环境变量
export CONF_PROVIDER_FILE_PATH=server端的server.yml文件门路export APP_LOG_CONF_FILE=server端的log.yml文件门路
进入registry/servicediscovery/nacos/go-server/app,运行server.go的main办法,能够从Nacos的控制台(http://console.nacos.io/nacos...)
看到,利用user-info-server曾经注册胜利。
Client端搭建
client的配置文件在registry/servicediscovery/nacos/go-server/profiles目录下,须要批改的中央跟server端一样,这里不赘述。
配置client端环境变量
export CONF_CONSUMER_FILE_PATH=client端的server.yml文件门路export APP_LOG_CONF_FILE=client端的log.yml文件门路
进入registry/servicediscovery/nacos/go-client/app,运行client.go的main办法,看到如下日志输入,示意调用server端胜利。
作者:李志鹏
Github账号:Lzp0412,Nacos-SDK-go作者,Apache/Dubbo-go Contributor。现就职于阿里云云原生利用平台,次要参加服务发现、CoreDNS、ServiceMesh相干工作,负责推动Nacos Go微服务生态建设。
相干链接
Nacos-SDK-go我的项目地址:https://github.com/nacos-grou...
Nacos golang生态交换群:23191211
Nacos我的项目地址:https://nacos.io/
Nacos社区交换群:30438813
Dubbo-go 我的项目地址:https://github.com/apache/dub...
Dubbo-go社区交换群:23331795