微服务架构核心(五)- 服务发现

每一个服务都存在服务的提供方和消费方,服务发现就是消费方发现并且调用服务方提供的服务。

在微服务架构下,存在众多的消费方与服务方,而且服务运行在不同的进程之中,消费方如果想要调用某一个服务,必须通过远程调用的方式,此时就会遇到下面几个问题:

  1. 消费方如何知道服务方的调用地址?
  2. 以集群方式部署的服务方,如何保证负载均衡?
  3. 当服务方发生变动,例如IP变更、服务下线等,如何通知到消费方?

服务发现的出现,就是为了解决上面几个问题。在微服务架构中有三种经典的服务发现模式。

独立LB模式

这是早期采用比较广泛的一种模式,具体流程如下:

  1. 服务方将自己的服务暴露给LB(LoadBalance),并映射到某一个域名上。
  2. 消费方通过DNS解析域名,找到指定的LB。
  3. LB通过内部负载均衡算法,调用某一个服务方。

这种模式的优点是结构简单,易于使用,LB通常采用HAProxy或者F5。缺点是配置环境较多,而且变更时需要人工介入,例如需要做域名配置、LB配置,当服务发生变更时,也需要运维人工介入修改配置。另外还有一个问题时需要一个集中的LB,可能会造成LB的单点问题,影响系统整体性能。

进程内LB模式

进程内LB模式就是把LB迁移到应用进程内,同时增加了注册中心,整体流程如下:

  1. 服务方将服务信息注册到给注册中心,并定期发送心跳。
  2. 消费方从注册中心拉取需要的服务信息。
  3. 消费方通过进程内的LB,直接调用服务方。

进程内LB模式解决了独立LB模式的单点问题,在性能上更有保证。缺点则是实现难度更高,新增了一个注册中心,同时要开发独立的LB,尤其是在多语言环境中,每个语言都需要单独实现LB,增加了开发成本。

进程外LB模式

进程外LB模式与进程内LB模式唯一的区别就是将LB放到独立的进程中,与应用进程分开,在每个主机上同时部署应用与LB,一般是放在一个容器中。

这种模式的具备了进程内LB模式的所有优点,同时在多语言环境中也可以使用统一的LB缺点则是运维成本较高,需要部署单独的LB进程。

总结

前面介绍了微服务三种经典的服务发现模式:独立LB模式进程内LB模式进程外LB模式,这三种模式是一个逐步递进的关系,为了解决前一种模式的问题而提出的新方案。

最后,大家可以思考一下,目前比较流行的微服务框架Springcloud与Dubbo,他们采用了什么样的服务发现模式?

上篇常见链表操作-单链表反转(JAVA实现)
下篇微服务架构核心(四)- 微服务组织架构