在使用spring cloud体系进行微服务开发时，一般的服务注册和发现除了 eureka 之外，还可以采用consul, zookeeper来实现。本文描述使用组件 spring-cloud-consul 时，如果保证服务变更时的实时发现和处理.
一般来说，采用zookeeper这种服务端通过连接挂在临时节点，然后消费端通过监听节点来感知服务的变更，这种实现方式对于服务端的上下线感知是最快的。因为通过socket来维系服务的健康度，当服务不可用时，socket立马即会断开.(本文不考虑服务假死,socket仍可用的情况),而监听方马上通过变更来更新server list. 当下一个请求处理时，即会正确选择合适的服务方进行处理。而且当服务方上线时，也会立马进行感知加入到服务列表中。
对于consul来实现服务注册，有很多种方式，这里我们采用 TTL check,即设置 spring.cloud.consul.discovery.heartbeat.enabled=true的情况,在这种情况下 其 默认ttl值为30，默认汇报时间为18左右.
对于消费者，即discover方，目前spring cloud consul中，采用标准的 ribbon-loadbalancer 中的 ServerList.getUpdatedListOfServers 来完成实例的更新。相应的定时任务通过 ServerListUpdater.start (默认实现为 PollingServerListUpdater) 来开启，内部采用 scheduleWithFixedDelay(默认30秒周期) 来实现.
在 consul 层,实现方为 ConsulServerList#getServers,即通过调用ConsulClient#getHealthServices 来获取健康的服务列表，对应consul的api即 /health/service/:service 来完成.
在这种情况下，存在一个间隔期，即30秒周期。如果服务方变更了，discover并不能实时感知，还需要等待下一次轮询才能感知到，对于微服务来说，这即是一个服务不可用的场景.
在官方 consul 的 API中，是存在 阻塞式调用的，即响应并不会立即返回，直到有变化或wait时间到。即长轮询概念，可以采取类似长轮询的概念来达到数据第一时间感知。目前世面大部分的配置中心同样采取类似的技术。
继续阅读“spring cloud consul微服务长轮询更新”