微服务架构中的服务发现

许多年前，与朋友失去联系的最简单方法是在不通知您的情况下更改您的电话号码。

同样适用于微服务架构系统中的服务。 两个服务可能会彼此愉快地交谈，直到其中一个移到另一个IP地址。

什么是服务发现

服务发现是关于找到服务提供商的网络位置。

我们为什么需要它

如果团队维护物理服务器，则配置文件将最能满足需要。

但是，如果使用的是云，由于重新启动，故障和扩展，您的服务可能具有动态网络位置。 手动维护配置文件是不可行的。

有哪些成分

服务发现涉及3个方面：服务提供者，服务使用者和服务注册表。

1. 服务提供者进入时向服务注册中心注册自己，离开系统时取消注册自身
2. 服务使用者从注册表中获取提供者的位置，然后与提供者进行对话
3. 服务注册表维护提供者的最新位置

有许多现有的服务发现工具可以使用。 但是，如果我们想建立自己的公司怎么办？

设计服务发现

由于服务注册表基本上是维护键/值对(provider name, provider locations) ，因此redis是一个不错的选择。 让我们以redis作为注册表来模拟服务发现过程。

当服务提供商inventory_service在登记处登记了自己，我们用SADD其位置添加到set ：

当位置服务消费者查询inventory_service ，我们既可以使用SMEMBERS得到的所有位置，或者我们也可以随机挑选一个与SRANDMEMBER ：

当inventory_service注销本身，我们使用SREM从组中删除：

但是要处理的复杂性：

1. 该服务消失后可能不会自行注销 。 然后，注册表为使用者提供了无效的地址。 为了解决此问题，服务提供商需要定期发送心跳 （可能每5秒发送一次）。 如果提供者有一段时间没有发送任何心跳信号，则注册表将假定提供者已死亡，并注销它。
2. 每次致电提供商之前都要查询注册表吗？ 它给注册表增加了过多的负担，并给性能带来了不必要的影响。 最好将副本保留在消费者本身中。
3. 如果保留在消费者中，如何通知消费者提供者的变化？ 有两种方法可以做到这一点。 1）消费者使用轮询来获取最新版本。 由于位置通常不会经常更改，因此仍然可以使用。 缺点是轮询之间可能会停机。 2） pubsub模式。 它提供了更即时的位置更新，但会占用更多的使用者线程。
4. 可能不需要发回提供者的所有数据。 我们可以保持提供者的全局版本控制 ，并且消费者仅在版本增加时才需要更新其本地副本。
5. 单点故障 。 如果服务注册表（例如我们在此处使用的redis实例）关闭，则所有使用者和提供者都将受到影响。 为了减轻这种情况，我们可以使用分布式数据库作为服务注册表，例如zookeeper/etcd/consul 。

客户端发现或服务器端发现

1. 客户端发现：服务使用者保留提供者的所有位置，并在各个位置负载均衡请求。 优点：注册表是唯一的另一个组件。 缺点：需要为系统中使用的不同语言/框架实现服务发现客户端。
2. 服务器端发现：使用者将请求发送到负载均衡器，注册表中的负载均衡器查询并确定要发送到的提供程序的位置。 优点：与语言/框架无关。 缺点：现在您需要管理另一个运动部件-负载平衡器。

结论

本文介绍了服务发现在微服务体系结构系统中的工作方式。 它可以帮助读者理解或调试使用Netflix Eureka等开源工具时的情况。

参考并推荐阅读：

1. https://github.com/Netflix/eureka/wiki/Understanding-eureka-client-server-communication
2. https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/

From: https://hackernoon.com/understand-service-discovery-in-microservice-c323e78f47fd