[发明专利]一种服务发现方法及系统

说明书

本发明实施例提供一种服务发现方法及系统，所述方法包括：接收服务消费端向分布式一致性存储服务发起的带有等待时间的请求；监听所述分布式一致性存储服务的服务信息列表是否更新；在所述等待时间内，当监听的服务信息列表更新，分布式一致性存储服务响应所述请求并返回更新后的服务信息列表。本技术方案既保证服务消费端对监听服务的感知灵敏度，又避免了过于频繁的对于分布式一致性存储服务的请求，节省了网络开销和对CPU的消耗。

技术领域

本发明属于微服务领域，具体涉及一种服务发现方法及系统。

背景技术

很多互联网公司在随着业务规模不断增长的同时，代码规模也在不断增长。为了更好的支撑公司业务，提高资源利用率，以及增加代码的可维护性，微服务架构会成为很多公司的首选。然而，我们在将很多项目拆分成多个功能单一的服务的时候，也带来了一些新的挑战。首先，服务的拆分会使得服务的数量迅速膨胀，大量的服务增加了运维成本。其次，由于微服务追求服务的快速部署和扩容，因此单个服务的ip和端口可能会随时发生变化，服务的节点数量也会动态改变，这样给服务之间的调用增加了难度。

在这样的一个背景下，服务注册和服务发现等诸多方案应运而生。其核心思想是提供一个单独的分布式一致性存储服务，在服务启动的时候将自己的ip和端口等信息注册到这个分布式一致性存储服务中，服务的节点宕机时，将服务从分布式一致性存储服务中摘除，其他服务调用该服务的时候需要先到分布式一致性存储中获取该服务的可用节点信息，然后再选择一个去调用。

目前市面上用于服务注册和服务发现的开源产品主要有zookeeper，consul，etcd等。它们主要提供了分布式一致性存储功能。

如果按照通用的服务注册和服务发现的方式，虽然能基本解决大量服务之间依赖的问题，但是如果服务的消费方，在每次消费服务的时候都去请求分布式一致性存储来获取服务信息列表的话，那么会对当前的业务流程增加额外的网络开销，必然会降低服务的响应速度，假设本次请求链路很长的话，在每个层级上都这样损失一些性能，最后会导致一个流程的响应非常慢。

针对这个问题，目前业界使用较多的方案就是在服务消费端启用一个线程，定期来拉取其消费的服务的可用列表信息，然后缓存起来。这样的话，在业务请求过来的时候，直接从本地缓存中获取需要调用的服务信息而不必去请求分布式一致性存储来获取服务信息列表。

但是，这种定期更新缓的方案虽然能保证不损失业务流程的性能，但是定期缓存的话会降低服务消费端对其所消费的服务的可用列表的感知灵敏度。也就是说，假如服务消费端在定期拉取完一个服务的可用列表并缓存后，假如该服务此时一个节点发生宕机，而服务消费端的缓存还没过期，那么消费端任然可能将请求发送给这个已经宕机的节点，从而导致此次请求的失败。

那么，可能有人会想到通过降低服务信息列表缓存时间的方式来提高服务感知的灵敏度。这样确实有一定的效果，但是，缓存时间太短的话，会造成频频繁的请求分布式一致性存储服务来获取服务信息列表，而事实上这样的话，绝大多数情况下服务信息列表是没有发生变更的，不仅造成了很多没必要的请求也增加CPU的开销。更重要的是，即使降低了服务缓存时间，在极端情况下还是会存在服务消费端将请求发送给已经宕机的节点的情况。

发明内容

本发明实施例提供一种服务发现方法及系统，既保证服务消费端对监听服务的感知灵敏度，又避免了过于频繁的对于分布式一致性存储服务的请求，节省了网络开销和对CPU的消耗。

为实现上述目的，一方面，本发明实施例提供了一种服务发现方法，所述方法包括：

接收服务消费端向分布式一致性存储服务发起的带有等待时间的请求；

监听所述分布式一致性存储服务的服务信息列表是否更新；

在所述等待时间内，当监听的服务信息列表更新，分布式一致性存储服务响应所述请求并返回更新后的服务信息列表。