Service Discovery in Microservices 客户端/服务端服务发现

原文链接 Client Side Service Discovery in Microservices - GeeksforGeeks

原文链接 Server Side Service Discovery in Microservices - GeeksforGeeks

服务发现介绍

Server-Side 服务发现

实例：

Client-Side 服务发现

实例：

服务发现介绍

服务发现（Service Discovery）就是通过服务名去找服务地址（如 IP和端口）的过程。

去哪里找？当然是去拥有服务器地址信息的组件中找，这个组件就是发现服务（Discovery Service）。

发现服务（Discovery Service）哪来的这些地址信息？每一个微服务启动的时候主动注册上去的。

这些地址信息可以存在一个特定的map，list 或数据库里。

假设我们现在有一个 Service-A，四个不同地址的Service-B，在启动的时候注册自己的IP和端口到发现服务（Discovery Service）中，则信息如下图所示。

当 Service-A 准备调用 Service-B时，首先请求发送到 load balancer（LB），然后LB去发现服务（Discovery Service）查询 Service-B的地址，结果发现有四个 Service-B。LB只需要按照设置的算法分发给其中一个 Service-B。

具体算法可以看这篇 What is load balancing? 什么是负载均衡？-CSDN博客

Server-Side 服务发现

其实上面这种就是服务端（Service-Side）的服务发现。具体步骤如下：

1，客户端（Service-A）向服务器发出请求，服务器可能是路由器（Router）、负载平衡器（Load Balancer）或中间人（Middleman）。在本例中，它是一个负载均衡器（Load Balancer）。

2，服务器（负载均衡器）使用发现服务（Discovery Service）执行查询。

3，发现服务（Discovery Service）响应负载均衡器（Load Balancer）可以调用的 Service-B 实例的可用数量。

4，然后负载均衡器服务器（Load Balancer）拿起一个 Service-B 实例并进行调用。

5，这里，Service-A（客户端）不直接与发现服务（Discovery Service）通信。它调用另一个服务器（负载均衡器）来帮助发现Service-B的URL信息。

这个完整的模式我们称之为服务器端发现。

优点：

在这种方法中，负载平衡器（Load Balancer）完成负载平衡的工作。这是这种方法的主要优点。毫无疑问，开发这种级别的抽象使服务消费者更加轻量级，因为它不需要处理查找过程。因此，不需要为服务消费者使用的每种语言和框架单独实现发现逻辑。

缺点：

缺点是我们必须设置和操作负载平衡器（Load Balancer），除非部署环境已经提供了它。

实例：

Nginx: Nginx是一个web服务器，也可以用作反向代理，负载均衡器，邮件代理和HTTP缓存。Nginx是一个免费的开源软件。
AWS ELB：弹性负载平衡器（Elastic Load Balancer， ELB）是Amazon提供的一项服务，在该服务中，传入流量以提高速度和性能的方式在一组后端服务器之间高效、自动地分布。它有助于提高应用程序的可伸缩性并保护应用程序。