原有拉取方式

原有的服务拉取方式：定时的从 Registry拉取全量信息

上述表述有2个关键词：定时、全量

1. 定时拉取：这一个BASE的场景，只能保证最终一致性，在上一次和下一次拉取的间隔，如果服务端的信息发生变化，客户端是无法即时更新的。
2. 全量拉取：每一次客户端都是全量拉取，意味着即使数据不变，也会进行所有数据的拉取，随着客户端数量的增大，容易对服务器造成流量风暴。

后续的优化主要也是针对这2点进行处理的。

改进

引入了几个机制：

1. 服务端数据的版本号，每次服务端数据更新后版本号会跟着变换，我用的是核心数据的来标识的
2. 客户端每次发起请求的时候，会带上服务端响应给它的版本号（第一次版本号为空）
3. 当客户端的版本号同服务端的版本号一致的时候，服务端会阻塞一段时间，直到超时或者核心数据发生变更后，才会将数据返回。
4. 客户端一旦接收到服务端的响应，立即重新进行下一次服务请求。

客户端第一次请求

客户端第一次请求的时候，本地没有版本号，所以此时版本号为空，服务端收到版本号后同自身保存的版本进行对比，如果结果是不同的，那么会将核心数据和版本号一起返回

客户端第二次请求＋服务端数据未变化

假如这个过程中，服务端的数据未发牛变换。

客户端发起请求时带上从服务端获取的版本号，服务端接收到客户端的版本号，一对比发现者相同，此时服务端开始阻塞，直到超过最大的阻塞时间。

因为在这段时间以内服务端数据没有变更，所以此时服务端返回的数据仅仅是版本号，不包含核心数据。

客户端第三次请求，服务端数据变化

客户端发起请求时带上从服务端获取的版本号，服务端接收到客户端的版本号，一对比发现者相同此时服务端开始阻塞，但是服务端在阻塞的过程中，发现了数据发生了变更，此时会马上将最新的版号和数据返回

简而言之：一旦在阻塞时间段服务端数据发生了变更，那么立马返回核心数据和版本号。