在之前我们将路由表以及分组信息一直存储在网关中，如下图：
显然这样设计并不合理：
- 网关应该只负责对用户的信息进行解析并根据类型进行转发，最大限度减少其他的负荷
- 网关作为一个单点，在出现故障后，我们希望可以直接重启就能处理请求，不需要有数据的恢复，也就是第一点，网关只负责转发功能。
因此在这里我们引入路由配置服务器，专门负责处理集群路由管理，可以理解为这是一个简单的Zookeeper.
显然，为了防止单点的出现，我们使用raft来做为该服务的高可用的保障，此后我们只需要关注业务层的拓展即可。
那么配置服务器里存储了什么呢？
| 字段 | 解释 | 举例 |
|---|---|---|
| Version | 记录配置版本 | 1 （启示为1） |
| Buckets | 桶列表，或者叫哈希槽（slots），存储服务器编号 | 是一个数组，自由设置长度 |
| Addr | 记录存储服务器编号对应的服务器地址 | 1–> 47.89.34.234 |
同学们，可以在体验界面实际操作理解一下，并不复杂。
此时我们的业务逻辑发送变化（假设Buckets长度为15）：
- 用户上传kv
- 网关收到 put请求，输入为(key,value), hash(key)%15达到一个[0,14]的数字X,即bucketX
- 发送请求信息到路由配置服务器组，得到bucketX对于的存储服务器A的地址
- 与存储服务器A进行通信，写入数据
- 用户下载kv
- 网关收到 get请求，输入为key, hash(key)%15达到一个[0,14]的数字X,即bucketX
- 发送请求信息到路由配置服务器组，得到bucketX对于的存储服务器A的地址
- 与存储服务器A进行通信，查询数据并返回结果
那为什么说我们的这个配置服务像zookeeper呢，这是因为除了网关与configserver通信之外，存储服务器也会和configserver进行通信。
存储服务器为了能够及时获取最新的配置进行数据效验和可能的桶迁移操作，会不断从configserver拉取最新配置，这里有两种方案：
- 存储服务器按一定的时间间隔请求配置服务器的配置信息，如果与当前版本有变化，则更新本地的配置
- 采用zookeeper监听通知的方式，存储服务器注册监听配置方法，配置服务器检测到配置变更，则通知存储服务器更新。
这里Dsjorney采用的是实现更简单的第一种，对于go语言，单独开一个协程去轮询访问开销并不大。
