首页
学习
活动
专区
工具
TVP
发布

体系化认识微服务之四:服务注册发现机制

服务调用者要在众多的微服务中调用具体的服务提供者,必然涉及到负载均衡的问题,根据负载均衡的实现可以分为集中式LB、进程内LB和独立进程LB。

集中式LB

LB上有所有的服务地址配置,当服务消费者调用某个服务的时候,LB会根据负载均衡策略(随机、轮询等)将请求转发到具体的服务上。此外,服务调用者还需要知道LB的地址,通常的做法是运维在服务器上配置一个DNS域名或者IP,这个域名指向LB。这种实现方式的问题每次调用都要访问LB,LB存在单点问题,无法水平扩展

进程内LB

为了解决每次服务调用都经过LB的不足,把LB放在客户端可以很好解决,这里多了一个注册表,服务提供方启动时,首先将服务地址注册到服务注册表,定期发送心跳包到服务注册表,检查存活状态。服务消费方要访问某个服务时,经历以下过程:

服务消费者在启动时从服务注册表获取需要的服务注册信息

将服务提供者注册信息缓存在本地(客户端LB)

监听服务提供者注册信息的变更,如接收到服务注册中心的服务变更通知,则在本地缓存中更新服务的注册信息

根据本地缓存中的服务注册信息构建服务调用请求,并根据负载均衡策略(随机负载均衡,Round-Robin负载均衡等)来转发请求

对服务提供方的存活进行检测,如果出现服务不可用的服务提供方,将从本地缓存中剔除,定期检测本地服务注册表的存活状态

这一方案对服务注册表的可用性要求很高,一般采用能满足高可用分布式一致的组件(例如Zookeeper、Consul、Etcd等)来实现。这里由于LB是在服务调用者的进程内,那么每个服务调用者都有自己的本地LB,不会导致每次调用都直接访问LB的情况,而且服务调用者直接访问服务提供者,没有额外的开销。这样部署的条件是服务注册表要支持高可用,通常采用集群部署的方式实现。目前开源组件比如Dubbo、Eureka、Karyon都是采用类似这种服务注册发现机制,不足是要对不同的语言开发不同的客户端,因为LB需要进行路由,不同的语言就需要开发不同的客户端进行路由,比如Dubbo本身是用Java开发的,只要配和注册中心比如zookeeper就可以完成服务注册和发现,但是使用Node.js如果要调用dubbo服务就需要开发基于Node.js的客户端去发现dubbo的服务,相当于是Node.js版的Dubbo。

独立进程LB

与第二种类似,区别是这将LB作为独立进程,好处是多语言环境下可以不用开发不同的客户端,不足是部署复杂,增加了出错调试的复杂度。只要LB进程的主机部署了其他应用,不管是什么语言开发的都能通过LB完成路由,这样就不需要开发专门的客户端去路由了每次服务调用都要穿透主机所在的LB,包括请求和响应。目前开源的组件有Airbnb的SmartStack

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180602G0UFOZ00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券