微服务中的服务发现

最新推荐文章于 2024-10-14 16:48:18 发布

StephenZou14

最新推荐文章于 2024-10-14 16:48:18 发布

阅读量1.5k

点赞数 1

分类专栏：分布式文章标签：服务发现

本文链接：https://blog.csdn.net/StephenZou14/article/details/75258040

版权

分布式专栏收录该内容

1 篇文章 0 订阅

订阅专栏

什么是服务发现

在介绍服务发现之前，先来介绍一下什么是微服务，所谓的微服务其实就是将一套软件拆分为多个服务，每个服务专注于一个功能点，然后将业务流程拆分为几个不同的服务之间的组合，从而实现高内聚低耦合的效果。

在微服务体系结构中，所谓的服务发现就是用户可以通过服务的名字，在注册中心找到可以提供正常服务的实例的网络地址（即ip地址和端口号）。这种根据服务名字发现服务的可用地址的机制就叫做服务发现。

为什么需要服务发现

现代网络程序中主要分为前端和后端两部分，当前端的程序访问后端的时候，必须要知道后端服务的网络地址（即IP地址或者端口号）。以前每一个服务都被固定的部署到某一台机器上，所以说每个服务的端口号和IP地址都是固定的，可以通过配置文件进行修改。但是，在微服务体系中，由于服务的实例有可能发送失败重启、自动扩容、升级等情况，导致这些服务实例对应的网络地址是在动态变化的。如何精准、准确地使前端能够发现后端是一个难以解决的问题。

服务发现的好处

使用服务发现机制最大的好处是使用方可以不用硬编码的网络地址，只需服务的名字（有时甚至连名字都不用）就能使用服务。在现代的体系架构中，单个服务实例的启动和销毁很常见，所以应该做到：无需了解整个架构的部署拓扑，就能找到这个实例。

解决方案

zookeeper

Zookeeper是一个集中式的服务。该服务能够维护服务配置信息。命名空间，提供分布式的同步，以及提供组化服务。Zookeeper是由Java语言实现，实现了强一致性（CP），而且是使用Zab协议在ensemble集群之间协调服务信息的变化。

Zookeeper在ensemble集群中执行3个。5个或者7个成员。众多client端为了能够訪问ensemble。须要使用绑定特定的语言。

这样的訪问形式被显性的嵌入到了client的应用实例以及服务中。

服务注冊的实现主要是通过命令空间（namespace）下的ephemeral nodes。ephemeral nodes仅仅有在client建立连接后才存在。当client所在节点启动之后，该client端会使用一个后台进程获取client的位置信息，并完毕自身的注冊。假设该client失效或者失去连接的时候。该ephemeral node就从树中消息。

服务发现是通过列举以及查看详细服务的命名空间来完成的。Client端收到眼下全部注冊服务的信息，不管一个服务是否不可用或者系统新加入了一个同类的服务。Client端同一时候也须要自行处理全部的负载均衡工作，以及服务的失效工作。

Zookeeper的API用起来可能并没有那么方便。由于语言的绑定之间可能会造成一些细小的差异。假设使用的是基于JVM的语言的话，Curator Service Discovery Extension可能会对你有帮助。

因为Zookeeper是一个CP强一致性的系统，因此当网络分区（Partition）出故障的时候，你的部分系统可能将出出现不能注冊的情况。也可能出现不能找到已存在的注冊信息，即使它们可能在Partition出现期间仍然正常工作。特殊的是。在不论什么一个non-quorum端，不论什么读写都会返回一个错误信息。

etcd

Etcd是一个高可用的K-V存储系统，主要应用于共享配置、服务发现等场景。

Etcd能够说是被Zookeeper和Doozer催生而出。整个系统使用Go语言实现，使用Raft算法来实现选举一致。同一时候又具有一个基于HTTP+JSON的API。

Etcd，和Doozer和Zookeeper相似，通常在集群中执行3，5或者7个节点。client端能够使用一种特定的语言进行绑定。同一时候也能够通过使用HTTP客户端自行实现一种。

服务注冊环节主要依赖于使用一个key TTL来确保key的可用性。该key TTL会和服务端的心跳捆绑在一起。假设一个服务在更新key的TTL时失败了，那么Etcd会对它进行超时处理。假设一个服务变为不可用状态，client会须要处理这种连接失效。然后尝试另连接一个服务实例。

服务发现环节设计到罗列在一个文件夹下的全部key值。随后等待在该文件夹上的全部变动信息。

因为API接口是基于HTTP的，所以client应用会的Etcd集群保持一个long-polling的连接。

因为Etcd使用Raft一致性协议，故它应该是一个强一致性系统。Raft须要一个leader被选举，然后全部的client请求会被该leader所处理。然而，Etcd似乎也支持从non-leaders中进行读取信息，使用的方式是在读情况下提高可用性的未公开的一致性參数。在网络分区故障期间，写操作还是会被leader处理，并且相同会出现失效的情况。