服务发现
一 服务发现
1.1 服务发现出现的缘由
因为一套微服务架构中有很多个服务需要管理,管理几百个服务所使用的端口列表是一大挑战,我们应该部署无需指定端口的服务,并让Docker为我们分配一个随机端口。
那么问题就演变成了我们需要发现端口号,让别人知道。为了能够定位服务,需要下面2个步骤:
- 服务注册:该步骤存储的信息至少包括正在运行的服务的主机和端口信息
- 服务发现:该步骤允许其他用户可以发现在服务注册阶段存储的信息。
微服务的框架体系中,服务发现是不能不提的一个模块。客户端的一个接口需要调用多个服务 ,客户端必须知道所有服务的网络位置,以往的做法是使用配置文件,或者配置在数据库中,这就出现了一些问题:
- 需要配置N个服务的网络位置,加大配置的复杂性
- 服务的网络位置变化,都需要改变每个调用者的配置
- 集群的情况下,难以做负载(反向代理的方式除外)
有了服务发现模块,多个微服务把当前自己的网络位置注册 到服务发现模块(这里注册的意思就是告诉),服务发现就以K-V的方式记录下,K一般是服务名,V就是 IP:PORT。服务发现模块定时的轮询查看这些服务能不能访问的了(这就是健康检查)。客户端在调用服务A-N的 时候,就跑去服务发现模块问下它们的网络位置,然后再调用它们的服务。
客户端完全不需要记录这些服务网络位置,客户端和服务端完全解耦!
1.2 需要额外考虑的地方
如果一个服务停止工作并部署/注册了一个新的服务实例,那么该服务是否应该注销呢?当有相同服务的多个副本时咋办?我们该如何做负载均衡呢?如果一个服务器宕机了咋办?所有这些问题都与注册和发现阶段紧密关联。现在,我们限定只在服务发现的范围里(常见的名字,围绕上述步骤)以及用于服务发现任务的工具,它们中的大多数采用了高可用的分布式键/值存储,这就是服务发现工具需要实现的功能。