一 硬编码问题
1 适用场景有局限:如果服务提供者的网络地址(IP和端口)发生了变化,将会影响服务消费者。例如,用户微服务的网络地址发生了变化,就需要修改电影微服务的配置,并重新发布,这显然不可取。
2 无法动态伸缩:在生产环境中,每个微服务一般都会部署多个实例,从而实现容灾和负载均衡。在微服务的系统中,还需要具备自动伸缩的能力,例如动态增减节点。硬编码无法适应这种需求。
二 服务发现
服务提供者、服务消费者、服务发现组件这三者之间的关系如下
1 各个微服务在启动时,将自己的网络地址等信息注册到服务发现组件中,服务发现组件会存储这些信息。
2 服务消费者可从服务发现组件查询服务提供者的网络地址,并使用该地址调用服务提供者接口。
3 各个微服务与服务发现组件使用一定机制(例如心跳)通信。服务发现组件如长时间无法与某微服务实例通信,就会注销实例。
4 微服务网络地址发生变更(例如实例增减或者IP端口发生变化等)时,会重新注册到服务发现组件。使用这种方式,服务消费者就无须人工修改提供者的网络地址了。
三 服务发现组件的功能
1 服务注册表
服务注册表是一个记录当前可用服务实例的网络信息的数据库,是服务发现机制的核心。它用来记录各个微服务的信息,例如微服务的名称、IP、端口等。服务注册表提供查询API和管理API,使用查询API获得可用的服务实例,使用管理API实现注册和注销。
2 服务注册和服务发现
服务注册是微服务在启动时,将自己的信息注册到服务发现组件上的过程。服务发现是指查询可用微服务列表及网络地址的机制。
3 服务检查
服务发现组件使用一定机制定时检测已注册的服务,如发现某实例长时间无法访问,就会从服务注册表中移除该实例。
四 服务发现的方式
客户端发现:Eureka、zk
服务端发现:Consul+nginx

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐