每一个服务都存在服务的提供方与消费方，服务发现就是消费方发现并且调用服务方提供的服务。
在微服务架构下，存在众多的消费方与服务方，而且服务运行在不同的进程之中，消费方如果想要调用某一个服务，必须通过远程调用的方式，此时就会遇到下面几个问题:
- 消费方如何知道服务方的调用地址？
- 以集群方式部署的服务方，如何保证负载均衡？
- 当服务方发生变动，例如IP变更、服务下线等，如何通知到消费方？
服务发现的出现，就是为了解决上面几个问题。在微服务架构中有三种经典的服务发现模式。
独立LB模式
这是早期采用比较广泛的一种模式，具体流程如下：
- 服务方将自己的服务暴露给LB（LoadBalance），并映射到某一个域名上。
- 消费方通过DNS解析域名，找到指定的LB。
- LB通过内部负载均衡算法，调用某一个服务方。
这种模式的优点是结构简单，易于使用，LB通常采用HAProxy或者F5。缺点是配置环境较多，而且变更时需要人工介入，例如需要做域名配置、LB配置，当服务发生变更时，也需要运维人工介入修改配置。另外还有一个问题时需要一个集中的LB，可能会造成LB的单点问题，影响系统整体性能。
进程内LB模式
进程内LB模式就是把LB迁移到应用进程内，同时增加了注册中心，整体流程如下:
- 服务方将服务信息注册到给注册中心，并定期发送心跳。
- 消费方从注册中心拉取需要的服务信息。
- 消费方通过进程内的LB，直接调用服务方。
进程内LB模式解决了独立LB模式的单点问题，在性能上更有保证。缺点则是实现难度更高，新增了一个注册中心，同时要开发独立的LB，尤其是在多语言环境中，每个语言都需要单独实现LB，增加了开发成本。
进程外LB模式
进程外LB模式与进程内LB模式唯一的区别就是将LB放到独立的进程中，与应用进程分开，在每个主机上同时部署应用与LB，一般是放在一个容器中。
这种模式的具备了进程内LB模式的所有优点，同时在多语言环境中也可以使用统一的LB。缺点则是运维成本较高，需要部署单独的LB进程。
总结
前面介绍了微服务三种经典的服务发现模式：独立LB模式、进程内LB模式、进程外LB模式，这三种模式是一个逐步递进的关系，为了解决前一种模式的问题而提出的新方案。
最后，大家可以思考一下，目前比较流行的微服务框架Springcloud与Dubbo，他们采用了什么样的服务发现模式?
博文地址
https://www.taowong.com/blog/2018/09/05/microservice-05.html
