服务发现的背景
服务发现并不是新出现的概念,在分布式系统中是一个很基础的概念,并有很长的历史,DNS(域名系统)就是一个很好的例子。但是在最近一段时间,随着Docker和微服务架构的迅速发展,服务连接趋于动态化,服务的位置(IP和端口号)变化会非常频繁,动态服务注册和发现变得越来越重要,因此,越来越多的人开始关注服务发现。
服务发现的目的
在多台主机组成的集群中,通常情况下,通过用配置文件来让客户程序发现提供服务主机的IP地址和端口号。但是,在现代的基于云计算的微服务应用中,当部署更多的服务时,要解决这个问题变得非常复杂。在运行的系统中,由于人为的或自动的集群扩展、新的服务被部署以及主机宕机或被替换,服务的位置(IP和端口号)变化非常频繁。
服务发现的目的减少或消除组件之间的“手动”的连接。当你把你的应用程序推送进生产的时候,所有的这些事情都可以配置:数据库服务器的主机和端口,REST 服务的 URL 等等,在一个高可扩展的架构中,这些连接可以动态改变。一个新的后端可以被添加,一个数据库节点可以被停止。你的应用需要适应这种动态环境。
服务发现的定义
服务发现的基本思想[6]是任何一个应用的实例能够以编程的方式获取当前环境的细节。这是为了让新的实例可以嵌入到现有的应用环境而不需要人工干预。服务发现工具通常是用全局可访问的存储信息注册表来实现,它存储了当前正在运行的实例或者服务的信息。大多数情况下,为了使这个配置具有容错与扩展能力,这个工具分布式地存储在基础设施中的多个宿主机上。
服务发现是大多数分布式系统和面向服务的架构的重要组成部分,服务发现组件记录了(大规模)分布式系统中所有服务的信息,人们或者其它服务可以据此找到这些服务。复杂系统的服务发现组件要提供更多的功能,如存储元数据服务,健康监测,不同的查询功能,实时更新,等等。不同的使用情境,服务发现的含义也不同。例如,网络设备发现、零配置网络[12]、交汇发现和 SOA 发现等。无论是哪一种使用情境,服务发现提供了一种协调机制,方便服务的发布和查找。换一个方式来讲,服务发现就是利用服务发现工具来管理集群中的流程和服务找到它所涉及的相关服务并与之互相通信。它涉及到服务的目录,在该目录中注册服务,然后能够在该目录中查找并连接到服务。
服务发现工作在容器中
分布式服务发现系统的一个主要优势是它可以存储任何类型的组件运行时所需的配置信息。这就意味着可以从容器内将更多的配置信息抽取出去,并放入更大的运行环境中。每一个服务发现工具都会提供一套API,使得组件可以用其来设置或搜索数据[7]