《企业级容器云架构开发指南》—2.3.3　服务发现

2.3.3　服务发现

在单体阶段，为了完成一次服务请求，代码需要知道服务实例的网络位置（IP地址和端口）。传统应用都运行在物理硬件上，服务实例的网络位置都是相对固定的。例如，代码可以从一个经常变更的配置文件中读取网络位置。而对于一个现代的、基于云微服务的应用来说，这却是一个很麻烦的问题。服务实例的网络位置都是动态分配的，而且因为扩展、失效和升级等需求，服务实例会经常动态改变。因此，客户端代码需要使用一种更加复杂的服务发现机制。目前有两大类服务发现模式：客户端发现和服务器端发现。

如图2-20所示的客户端发现模式指当使用客户端发现模式时，客户端负责决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端从一个服务注册表中查询，其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择一个，然后发出请求。

客户端发现模式的优劣势如下。

优势：相对较为直接，不再考虑负载均衡，由于客户端知道可用的服务注册表信息，剩下的控制都可以由服务的请求端完成，可通过使用散列一致性更有效地实现负载均衡。

劣势：针对不同的语言注册不同的服务，在客户端需要实现每种语言的发现逻辑。

图2-20　客户端服务发现

如图2-21所示，服务器端的发现模式指单独做一个负载均衡，这是与客户端发现模式最大的区别。还是通过注册表找到一个可用的服务，之后要把所有的请求发给作为服务器端的负载均衡，由服务器端的负载均衡具体地来找到可用的实例，然后进行相应的通信。

图2-21　服务器端服务发现

服务器端发现模式的优劣势如下：

优势：客户端无须关注发现细节。

劣势：除非部署环境提供负载均衡，否则负载均衡是一个需要配置和管理的高可用的功能。

两种方式各有利弊，可以根据实际情况进行选择。

服务注册表也有自注册的模式，以及第三方注册的模式。自注册的模式比较简单，不需要其他系统功能，但如果想把服务实例和服务注册表联系起来，必须在每种编程语言和框架内实现注册代码。第三方注册模式即服务和注册表分离，不需要每种编程语言和架构完成注册逻辑，但需要配置和管理一个高可用系统。