这是关于使用微服务架构创建应用系列的第四篇文章。第一篇介绍了微服务架构的模式,讨论了使用微服务架构的优缺点。第二和第三篇描述了微服务架构内部的通讯机制。这篇文章中,我们将会探讨服务发现相关问题。
为什么要使用服务发现?
设想一下,我们正在写代码使用了提供REST API或者Thrift API的服务,为了完成一次服务请求,代码需要知道服务实例的网络位置(IP地址和端口)。传统应用都运行在物理硬件上,服务实例的网络位置都是相对固定的。例如,代码可以从一个经常变更的配置文件中读取网络位置。
而对于一个现代的,基于云微服务的应用来说,这却是一个很麻烦的问题。其架构如图所示:
服务实例的网络位置都是动态分配的,而且因为扩展、失效和升级等需求,服务实例会经常动态改变,因此,客户端代码需要使用一种更加复杂的服务发现机制。
目前有两大类服务发现模式:客户端发现(http://microservices.io/patterns/client-side-discovery.html)和服务端发现(http://microservices.io/patterns/server-side-discovery.html)。
我们先来来讨论一下客户端发现。
客户端发现模式
当使用客户端发现模式时,客户端负责决定相应服务实例的网络位置,并且对请求实现负载均衡。客户端从一个服务注册服务中查询,其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一个,然后发出请求。
下图显示的是这种模式的架构图:
服务实例的网络位置是在启动时注册到服务注册表中,并且在服务终止时从注册表中删除。服务实例注册信息一般是使用心跳机制来定期刷新的。
Netflix OSS提供了一种非常棒的客户端发现模式。Netflix Eureka是一个服务注册表,为服务实例注册管理和查询可用实例提供了REST API接口。Netflix Ribbon是一种IPC客户端,与Eureka合同工作实现对请求的负载均衡。我们会在后面详细讨论Eur