Docker集群中服务发现工具的概念和优势.docx

Docker集群中服务发现工具的概念及优势介绍容器给寻找大规模设计与部署应用的需求提供了一个优雅的解决方案。在Docker提供实际的容器技术的同时，许多其他的项目也在协助开发在部署环境中所需要的引导和沟通的工具。多种Docker环境依赖的核心技术之一是服务发现。服务发现可以让一个应用或者组件发现其运行环境以及其它应用或组件的信息。它通常是采用的是分布式key-value的存储方式，而且它还用来作为一般查询配置细节信息的地方。用户配置一个服务发现工具就可以将实际容器跟运行配置分离开，这样用户就可以在多个环境中复用同一个镜像。在这篇向导中，我们将讨论在一个Docker集群环境中服务发现工具带来的好处。主要关注在常规概念，在需要的地方会用详细的例子来描述。服务发现与全局可读配置存储服务发现的基本思想是任何一个应用的实例能够以编程的方式获取当前环境的细节。这是为了让新的实例可以嵌入到现有的应用环境而不需要人工干预。服务发现工具通常是用全局可访问的存储信息注册表来实现，它存储了当前正在运行的实例或者服务的信息。大多数情况下，为了使这个配置具有容错与扩展能力，这个工具分布式地存储在基础设施中的多个宿主机上。虽然服务发现平台的初衷是提供连接信息来连接不同组件的，但是它们更普遍地是用来存储任何类型的配置信息。许多部署工具通过写入它们的配置信息给发现工具来实现这个特性。如果容器配置了这些，它们就可以去查询这些预配置信息，并根据这些信息来调整自身行为。服务发现是怎么工作呢?每一个服务发现工具都会提供一套API，使得组件可以用其来设置或搜索数据。正是如此，对于每一个组件，服务发现的地址要么硬编码到程序或容器内部，要么在运行时以参数形式提供。通常来说，发现服务用键值对形式实现，采用标准http协议交互。服务发现门户的工作方式是：当每一个服务启动上线之后，他们通过发现工具来注册自身信息。它记录了一个相关组件若想使用某服务时的全部必要信息。例如，一个MySQL数据库服务会在这注册它运行的ip和端口，如有必要，登录时的用户名和密码也会留下。当一个服务的消费者上线时，它能够在预设的终端查询该服务的相关信息。然后它就可以基于查到的信息与其需要的组件进行交互。负载均衡就是一个很好的例子，它可以通过查询服务发现门户得到各个后端节点承受的流量数，然后根据这个信息来调整配置。这可将配置信息从容器内拿出。一个好处是可以让组件容器更加灵活，并不受限于特定的配置信息。另一个好处是使得组件与一个新的相关服务实例交互时变得简单，可以动态进行调整配置。配置存储是如何关联起来的?全局分布式服务发现系统的一个主要优势是它可以存储任何类型的组件运行时所需的配置信息。这就意味着可以从容器内将更多的配置信息抽取出去，并放入更大的运行环境。通常来说，为了让这个过程更有效率，应用在设计时应该赋上合理的默认值，并且在运行时可以通过查询配置存储来覆盖这些值。这使得运用配置存储跟在执行命令行标记时的工作方式类似。区别在于，通过一个全局配置存储，可以不做额外工作就能够对所有组件的实例进行同样的配置操作。配置存储如何帮助集群的管理?在Docker部署中，分布式键值对存储其中最初可能不太明显的一个功能是对集群成员的存储和管理。配置存储是为了追踪宿主机成员变更和管理工具的最好环境。一些可能会存在分布式键值对存储中的个人宿主机信息是：宿主机IP 宿主机自身的链接信息跟调度信息有关的标签或元数据信息集群中的角色(如果是采用了主从模式的集群) 在正常情况下，使用一个服务发现平台时，这些细节可能不是你需要考虑的。但是他们为管理工具提供了一个可以查询或修改集群自身信息的地方。故障检测怎么实现?故障检测的实现方式也有很多种。需要考虑的是如果一个组件出现故障，服务发现能否更新状态指出该组件不再提供服务。这种信息是至关重要的，关系到将应用或服务故障可能性降到最低。许多服务发现平台允许赋值时带一个可配置的超时时间。组件可以设置一个超时时间，并能定期去请求服务发现来重置超时时间。如果该组件出现故障，超时时间达到设定值，那么这个组件的连接信息就会从服务发现的存储中被去掉。超时时间长度在很大程度上是它与应用需要多快去应对一个组件的故障的函数。这也可以通过将一个基本的“助手”容器与每一个组件相连来实现,而它们唯一的责任是定期的健康检查组件以及更新注册表如果组件关闭。这种类型的架构值得担忧是,如果辅助容器出现故障,将导致不正确的信息在存储中。一些系统解决这个问题的方法是在服务发现的工具中定义健康检查。这样,发现平台本身可以定期检查已注册组件是否仍然可用。当细节变化时，配置服务会如何?对于基本的服务发现模型来说，一个关键的改进就是动态重新配置。普通服务发现工具允许用户通过检查在启动时的信息来影响组件的初始配置，而动态重新配置涉及配置组件