go微服务框架go-micro深度学习(三) Registry服务的注册和发现
服务的注册与发现是微服务必不可少的功能,这样系统才能有更高的性能,更高的可用性。go-micro框架的服务发现有自己能用的接口Registry。只要实现这个接口就可以定制自己的服务注册和发现。
go-micro在客户端做的负载,典型的Balancing-aware Client模式。
服务端把服务的地址信息保存到Registry, 然后定时的心跳检查,或者定时的重新注册服务。客户端监听Registry,最好是把服务信息保存到本地,监听服务的变动,更新缓存。当调用服务端的接口是时,根据客户端的服务列表和负载算法选择服务端进行通信。
go-micro的能用Registry接口
type Registry interface { Register(*Service, ...RegisterOption) error Deregister(*Service) error GetService(string) ([]*Service, error) ListServices() ([]*Service, error) Watch(...WatchOption) (Watcher, error) String() string Options() Options } type Watcher interface { // Next is a blocking call Next() (*Result, error) Stop() }
这个接口还是很简单明了的,看方法也大概能猜到主要的作用
Register方法和Deregister是服务端用于注册服务的,Watcher接口是客户端用于监听服务信息变化的。
接下来我以go-micro的etcdv3为Registry的例给大家详细讲解一下go-micro的详细服务发现过程
go-micro 服务端注册服务
流程图
服务端看上去流程还是比较简单的,当服务端调用Run()方法时,会调用service.Start()方法。这个除了监听端口,启动服务,还会把服务的ip端口号信息,和所有的公开接口的元数据信息保存到我们选择的Register服务器上去。
看上去没有问题,但是,如果我们的节点发生故障,也是需要告诉Register把我们的节点信息删除掉。
Run()方法中有个go s.run(ex) 方法的调用,这个方法就是根据我们设置interval去重新注册服务,当然比较保险的方式是我们把服务的ttl也设置上,这样当服务在未知的情况下崩溃,到了ttl的时间Register服务也会自动把信息删除掉。
设置服务的ttl和 interval
// 初始化服务 service := micro.NewService( micro.Name(common.ServiceName), micro.RegisterTTL(time.Second*30), micro.RegisterInterval(time.Second*20), micro.Registry(reg), )
ttl就是注册服务的过期时间,interval就是间隔多久再次注册服务。如果系统崩溃,过期时间也会把服务删除掉。客户端当然也会有相应的判断,下面会详细解说
客户端发现服务
客户端的服务发现要步骤多一些,但并不复杂,他涉及到服务选择Selector和服务发现Register两部分。
Selector是基于服务发现的,根据你选择的主机选择算法,返回主机的信息。默认的情况,go-micro是每次要得到服务器主机的信息都要去Register去获取。但是查看cmd.go的源码你会发现默认初始化的值,selector的默认flag是cache。DefaultSelectors里的cache对应的就是初始化cacheSelector方法
但是当你在执行service.Init()方法时
go-micro会把默认的selector替换成cacheSelector,具体的实现是在cmd.go的Before方法里
cacheSelector 会把从Register里获取的主机信息缓存起来。并设置超时时间,如果超时则重新获取。在获取主机信息的时候他会单独跑一个协程,去watch服务的注册,如果有新节点发现,则加到缓存中,如果有节点故障则删除缓存中的节点信息。当client还要根据selector选择的主机选择算法才能得到主机信息,目前只有两种算法,循环和随机法。为了增加执行效率,很client端也会设置缓存连接池,这个点,以后会详细说。
所以大概的客户端服务发现流程是下面这样
主要的调用过程都在Call方法内
主要的思路是
从Selector里得到选择主机策略方法next。
根据Retory是否重试调用服务,调用服务的过程是,从next 方法内得到主机,连接并传输数据 ,如果失败则重试,重试时,会根据主机选择策略方法next重新得到一个新的主机进行操作。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
如何提升团队的研发效率?阿里工程师这么做
背景 大约在5年前,也就是2013年我刚加入阿里的时候,那个时候 DevOps 的风刚吹起来没多久,有家公司宣称能够一天发布几十上百次,这意味着相比传统软件公司几周一次的发布来说,他们响应商业需求的能力可以甩后者几条街,而且这差距根本不是加班能赶上的。今天的 AliExpress 技术团队小几百人的规模,可一天发布几十次也已经司空见惯了,这主要得益于三个方面: ● 非常彻底地微服务化,拆分粒度很细,且旗帜鲜明地反对重二方库。 ● 阿里集团整体的运维标准化,尤其是 Docker 技术的全面覆盖。 ● AliExpress SRE 团队不断努力保证稳定性。 然而,效能这个东西,你永远不会说:“够了,够快了”,尤其是在当下的消费型社会,人人都是消费者,而消费者恨不得脑子里的欲望刚闪现出来,你的商品或服务瞬间就到他面前。况且,随着我们不
- 下一篇
Dubbo在Service Mesh下的思考和方案
开头 Service Mesh这个“热”词是2016年9月被“造”出来,而今年2018年更是被称为service Mesh的关键之年,各家大公司都希望能在这个思潮下领先一步。今天我也分享阿里中间件在这方面的观点,思考和实践。考虑到有些人没了解过Dubbo(集团内以HSF为主)和Servicemesh,先简单介绍下这两个词。Dubbo应该是国内最受欢迎的远程服务框架,在Github上有超过2w的star数,也是阿里分布式架构互联互通的核心所在。跟Dubbo一样,servicemesh也是面向服务互联互通这一问题域,是云原生技术栈的核心之一;大家可以简单理解service mesh就是云原生组织定义的微服务架构解决理念。Dubbo是实现框架,融入servcemesh理念就是我们今天分享的。 现状和挑战 当前Dubbo支撑的阿里分布式应用内支撑万级别的应用数,运行在20多万的服务器实例上,每天调用量是万亿级别,这应该是国内最大的分布式应用集群。 挑战主要来自三方面 首先, 数以万计的应用意味着有以十万级的服务,理顺错综复杂的服务拓扑关系,甚至及时诊断某个异常调用链路,需要考虑海量数据的拉取分...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS8编译安装MySQL8.0.19
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Windows10,CentOS7,CentOS8安装Nodejs环境