白话微服务架构中的服务发现
作者：Jason Xu
译者：忆蓉之心
原文链接：https://hackernoon.com/understand-service-discovery-in-microservice-c323e78f47fd
如果你想跟朋友失去联系的最简单方法就是在不通知他们的情况下更改您的电话号码。同样适用于微服务架构系统中的服务。两个服务可能会愉快地相互通信，直到其中一个服务移动到另一个IP地址，而不通知对方，导致服务不可用。
一、什么是服务发现？
服务发现是关于查找服务提供者的网络位置。
二、我们为什么需要它？
如果一个团队正在维护的是一台物理服务器，那么配置文件将主要满足需求。
如果你正在使用云，由于重新启动，失败和缩放，您的服务可能具有动态网络位置。因此，手动维护配置文件就不可行了。
三、什么是组件
服务发现涉及三方：服务提供者，服务使用者和服务注册中心。
服务提供者在服务注册表进入注册时注册自己，并在注销时自行注销。
服务消费者从注册中心获取提供者的位置，然后与提供者交谈。
服务注册中心维护提供者的最新位置。
目前，市面上有许多现有的服务发现工具可供使用。但是，我们如果想要建立自己的注册中心，应该怎么做呢？
四、设计服务发现
由于服务注册表基本上保持键值对(provider name, provider locations) ，因此redis可能是一个不错的选择。因此，我们用redis模拟服务发现过程作为注册表。
当服务提供者 inventory_service 在注册表中注册时，我们使用 SADD 它的位置添加到 set ：
当服务消费者查询位置时 inventory_service ，我们可以使用 SMEMBERS 获取所有位置，或者我们可以随机选择一个SRANDMEMBER ：
当 inventory_service 注销本身时，我们用 SREM 它从集合中删除它：
但是处理起来很复杂：
该服务在消失时可能不会注销。然后注册表向消费者提供一个无效的地址。为了解决这个问题，服务提供商需要定期发送心跳「每5秒钟」。如果提供者在一段时间内没有发送任何心跳，则注册管理机构将认定提供者死亡，并取消注册。
每次调用提供者之前查询注册表？这对注册表造成太大的负担，并施加不必要的性能影响。最好在消费者身上也保留一份副本。
如果保存在消费者中，如何通知消费者关于服务提供者的变化？有两种方法可以做到这一点。1）消费者使用投票获取最新版本。由于这些地点通常不会如此频繁地变化，所以这仍然有效。缺点是轮询之间可能会停机。2）pubsub 模式。它提供了更直接的位置更新，但它会占用额外的消费者线索。
返回提供者的所有数据可能不是必需的。我们可以保留提供者的全局版本，消费者只需要在版本增加时更新其本地副本。
单点故障。如果服务注册表中心「如我们在此使用的 redis 实例」关闭，则所有消费者和提供者都将受到影响。为了减轻这一点，我们可以使用分布式数据库作为服务注册表，例如 zookeeper/etcd/consul 。
五、客户端发现或服务器端发现
客户端发现：客户端查询服务注册中心，接着使用负载均衡算法选择可用的服务实例中的一个并把这个请求路由到该实例。优点：注册表是唯一一个更多的组件。缺点：需要为系统中使用的不同语言/框架实现服务发现客户端。
服务器端发现：客户端通过负载均衡器向服务发送请求。负载均衡器查询服务注册中心并路由每个请求到可用的服务实例。优点：语言/框架不可知。缺点：现在你需要管理另一个移动部分「负载平衡器」。
六、结论
本文解释了服务发现是如何在微服务体系结构系统中起作用的；它将会有助于你在使用Netflix Eureka等开源工具时了解或调试。
七、参考
https://github.com/Netflix/eureka/wiki/Understanding-eureka-client-server-communication
https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
—————END—————
看更多技术好文
请长按下方图片扫码关注