在传统应用中,对于其他服务的依赖通常是在安装的时候写在配置文件里面的。客户端在访问服务端的时候会从配置文件中读取服务端信息,之后再构造请求连接进行访问。这种模式在微服务的情况下是行不通的。一个应用被拆分成了多个服务,服务之间的依赖要比之前的依赖多几个数量级。如果这个时候依然使用配置文件的方式,那么配置这些文件就是一个噩梦。另外,一般服务是以多实例的形态存在,在扩容或者收缩实例时,IP信息会发生变化,每次去修改配置文件是不现实的事情。为此,服务发现出现了。
总体来说,服务发现分两种:客户端服务发现和服务端服务发现。
在客户端服务发现的场景下,服务在启动的时候会把自己注册到注册中心,并且在之后的运行中会与注册中心以心跳的方式保持联系。当服务down掉时,这个服务的信息会从注册中心删除;当有新服务加入时,新服务会把自己的信息注册到注册中心,让客户端能够感知到新服务的存在。客户端会持有注册中心的访问信息。因为注册中心的访问信息是相对比较固定的,基本不会发生变化,所以注册中心的访问信息可以写到配置文件中。客户端在需要访问服务端的时候,会去注册中心查讯服务端信息,再拿着服务端信息去访问。
服务端服务发现与客户端服务发现比较相似,区别就是,客户端不去感知服务发现的信息。客户端只与负载均衡器进行交互。服务发现的能力由负载均衡器进行实现。
在服务发现中,一般客户端是具有负载均衡能力的。客户端从服务端拿到全部的服务端信息之后,可以随机挑选一个服务或者对这些服务进行轮询,再或者使用一致哈希算法进行选择。
服务发现的能力中,一般也会带有路由的能力。通过路由可以配置客户端可以访问哪些服务。利用这个能力,能够实现灰度发布,即环境中同时存在高版本和低版本的服务,利用路由能力,使一部分客户端使用新版本的服务,另一部分客户端使用旧版本的服务。
服务发现框架一般还要具备调用链跟踪、熔断和服务降级能力。
当前注册中心一般使用etcd、zk等。作为注册中心本身,需要具备这些能力:1.服务健康检测的能力,一般通过心跳的方式实现;2.服务信息更新后通知客户端的能力。注册中心不需要强一致性。很多服务发现框架都采用AP存储来实现,即保证可用性和分区容忍性而不要求一致性。
现在有比较多的服务发现开源框架,如阿里的dubbo、华为的servicecomb、百度的bsf、spring cloud等。一般不需要自己实现,使用开源框架即可。
更多相关技术内容咨询欢迎前往并持续关注六星社区了解详情。
如果你想用Python开辟副业赚钱,但不熟悉爬虫与反爬虫技术,没有接单途径,也缺乏兼职经验
关注下方微信公众号:Python编程学习圈,获取价值999元全套Python入门到进阶的学习资料以及教程,还有Python技术交流群一起交流学习哦。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!