微服务最经典的三种服务发现机制

野性酷女 2023-01-03 01:56 96阅读 0赞

# 微服务最经典的三种服务发现机制 #

大家好，今天给大家分享一篇关于微服务的服务发现机制。在分布式系统当中有许多服务，在有些公司可能有几十个甚至上百个的服务。那么这些服务当中有生产者有消费者，那么这些消费者该怎么发现生产者呢？这就是微服务的服务发现问题。  
经过实战经验，这里给大家总结了三种主流的服务发现机制，第一种传统基于LB的模式，第二种进程内LB模式，第三种主机独立LB模式。

## 传统LB模式 ##

目前大部分公司还是基于传统的LB方式进行做服务发现和负载均衡的，这个模式有一个独立的LB负载均衡的概念，比如使用硬件的F5、nginx等。当服务的提供方上线以后，会像运维申请一个域名（DNS），运维人员去配置负载均衡器，让域名指向到后台的服务，服务一般部署多分，LB有负载均衡的功能。  
服务消费方访问后台服务的时候，需要使用域名，进行域名解析，解析到LB负载均衡上，通过负载均衡访问后台的服务。这种做法是最普遍做法，也是最简单的做法，消费者接入的成本比较低。服务的配置和负载均衡的配置需要运维的介入。它的不足之处就是它需要一个集中的LB，这个集中的LB可能是一个单点，如果集中的LB挂了可能会影响整个服务的访问。还有一点在性能方面，当消费者在调用服务端的时候，必须穿透LB,这个过程中可能会有一定的性能开销。  
![image][]

## 进程内LB ##

相比传统的LB,它将LB转移到了进程内部，这种方式是目前比较普遍的做法，它的服务提供方通过注册的方式，将服务注册到服务注册表中，并且定期的发送心跳。服务消费者通过集成的客户端，客户端中集成了服务发现和负载均衡的功能，它通过LB直接调用后台的服务，客户端会定期的同步注册表中的服务信息。这个种方式的优点它没有集中的LB,不存在性能问题，也不存在单点问题。缺点：在多语言当中，必须为每个语言的消费者研发相应的客户端，多语言的升级成本会比较高。  
![image][image 1]

## 主机独立LB模式 ##

在前面两种方式做了个折中。这个LB一独立进程的方式部署在主机上。它及不是在中间的集中LB，也不是在进程内部的客户端LB。而是在每个主机上部署个LB。这种方式跟第二种有点类似，服务生产者会自动注册到我们的服务注册表中，并且定期的发送心跳。消费者端的LB也会定期的去同步主机服务。当消费者去调用后台服务的时候，直接调用本机的LB进程，这个本级的LB会负责负载均衡和远程的调用。它的优点是即没有集中LB性能问题，也没有多语言的问题，它可以通过服务调用方式，不需要为每种语言开发客户端。但是它的运维成本比较高，它需要在每台主机上部署LB进程。  
![image][image 2]

### 更多精彩内容请关注公众号《杰子学编程》 ###

![在这里插入图片描述][20210106205622658.jpg_pic_center]  
更多内容请查看 [Julywhj的博客][Julywhj]期待您的光顾。

[image]: /images/20221119/e77cb9aac75547928bb1858b7ea04f68.png
[image 1]: /images/20221119/f332759f65d941a5af6bc163fb798d50.png
[image 2]: /images/20221119/87641726cd3d4544893c7082f2eefb39.png
[20210106205622658.jpg_pic_center]: /images/20221119/53d5313f07134dd29380cfb02b9561af.png
[Julywhj]: https://bs.julywhj.cn/#/