原文链接 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提供的一项服务，在该服务中，传入流量以提高速度和性能的方式在一组后端服务器之间高效、自动地分布。它有助于提高应用程序的可伸缩性并保护应用程序。        

Client-Side 服务发现

客户端的服务发现其实就是 Service-A想要调用Service-B，直接请求发现服务，发现服务返回Service-B的四个实例地址，然后负载均衡由客户端Service-A 决定。

优点：对于服务端来说，少了一个额外的跳跃（hop）。

缺点：客户端要自己实现Load Balancing 逻辑。

实例：

        Netflix Eureka：Eureka 是Netflix服务发现服务器和客户端。可以将服务器配置和部署为高可用性，每个服务器将已注册服务的状态复制到其他服务器。

        Zookeeper: Zookeeper是一个分布式、开源的分布式应用协调服务(coordination service)。它公开了一组简单的原语，用于实现用于同步、配置维护、分组和命名的高级服务。

        Consul: Consul是一个服务网络解决方案，用于自动执行网络配置、发现服务，并支持跨任何云或运行时的安全连接。