微服务架构下的服务发现功能

Posted 2021-04-14 GoDocker

　　

　　微服务架构相信大家都听说过，甚至有些人可能已经在实战用应用过，对它也有一定的了解了。本文主要是针对新入门的同学，比较详细地讲解了微服务架构下的服务发现，希望能对大家有所帮助。

 

为什么需要服务发现？

　　目前的服务发现机制主要有客户端服务发现和服务器端的服务发现两种模式，下面我先来讲。

 

客户端服务发现模式

 

客户端服务发现模式的架构如下图所示：

　　说到客户端发现模式，就必须说下项目，这个项目的服务器端发现是做的比较好的。Netflix OSS的Netflix Eureka提供了REST API接口，用来实现服务实例注册管理和可用实例查询功能。Netflix Ribbon则是IPC客户端，和Eureka协同工作，实现了在可用服务实例之间发送负载均衡请求。关于Eureka的详情我们稍后再来说。

　　说起来，客户端发现模式有它自己的优点，但是也有很多缺点。这种模式相对简单，除了Service Registry之外，其他组件都是固定不变的。另外，因为客户端可以获取到可用的服务实例列表，我们就可以通过一致性哈希算法之类的技术来实现针对特定应用的智能化负载均衡。在缺点方面，客户端服务发现模式有一个很大的毛病就是Service Registry和客户端是耦合在一起的。对于服务客户端所采用的每一种编程语言、每一种架构，我们都要分别实现一套客户端服务发现逻辑，这种做法其实并不是很经济。

　　客户端服务发现模式差不多就是这样，下面我再给大家讲下服务器端的服务发现模式。

 

服务器端发现模式

　　服务发现还有一种方式，就是服务器端发现模式，具体架构如下图所示：

　　客户端通过负载均衡器向服务发送请求，负载均衡器在Service Registry中进行查找，并将各个调用请求发送给可用的服务实例。跟客服端服务发现模式一样，服务实例也会在Service Registry中进行注册和注销。

　　举个例子，弹性负载均衡器（ELB）就是一个服务器端的服务发现路由器，常用于对互联网进来的外部流量实现负载均衡。当然，用户也可以通过ELB实现虚拟私有云（VPC）内部的流量负载均衡。这个过程是这样的：客户端通过ELB的DNS名称，向ELB发送HTTP或TCP请求，ELB根据负载均衡算法，在已注册的弹性计算云（EC2）服务实例或EC2容器服务（ECS）容器之间实现流量分摊。在这种机制下是没有单独的Service Registry的，EC2实例和ECS容器都是直接在ELB中注册。

　　像nginx Plus和NGINX之类的HTTP服务器和负载均衡器也可以用来做服务器端服务发现的负载均衡器。举个例子，现在有些网络平台是通过来实现NGINX代理的动态重新配置的。所谓其实是一种工具，可以从存储在Consul中的配置数据定时生成任意配置文件。只要文件发生了改变，Consul Template都会运行一个 shell command。在网络平台提交post请求的时候，就会生成一个包含反向代理设置的nginx.conf文件，然后再运行一条命令，让NGINX重新加载配置。当然也有更复杂的实现方式，比方说我们也可以通过HTTP API 或DNS来实现NGINX Plus的动态重新配置。

　　服务器端发现模式也有优缺点。这种模式的一大好处在于，服务发现的细节已经从客户端抽象出来了，在这种模式下客户端只负责向负载均衡器发送请求。这样我们就不用针对客户端采用的每一种编程语言、每一种框架分别实现服务发现逻辑了。而且有些部署环境还免费提供服务器端的服务发现功能。当然这种模式也有一些缺点，比方说，

Service Registry

　　再举几个服务注册方面的例子，大家感兴趣的话可以多了解下：

· – etcd是一个具有高可用性和一致性的分部式键值存储系统，主要用于共享配置和服务发现。目前业界两大巨头Kubernetes和Cloud Foundry使用的都是ETCD。

·– 这是一个用于服务发现和服务配置的工具，客户端可以通过consul提供的API来实现注册和服务发现。consul还具有health check的功能，可以用来确定服务的可用性。

·– 这个太有名了，Apache  是一个针对大型分布式系统的高效协调系统，目前已经得到了非常广泛的使用。 Apache Zookeeper最初只是Hadoop的一个子项目，但现在已经是Hadoop重点发展的项目了。

　　另外，前面我们说过，有些系统比如说Kubernetes, Marathon和AWS之流并没有单独提供服务注册功能，在这些系统中服务注册只是一个内置的功能，是基础架构的组成部分。