互联网|阿里为啥不用 ZooKeeper 做服务发现？( 二 )
相信你一定已经看出来了 ， svcB 的各个节点流量会有一点不均衡 。
ip1和ip10相对其它8个节点{ip2...ip9} ， 请求流量小了一点 ， 但很明显 ， 在分布式系统中 ， 即使是对等部署的服务 ， 因为请求到达的时间 ， 硬件的状态 ， 操作系统的调度 ， 虚拟机的 GC 等 ， 任何一个时间点 ， 这些对等部署的节点状态也不可能完全一致 ， 而流量不一致的情况下 ， 只要注册中心在SLA承诺的时间内（例如1s内）将数据收敛到一致状态（即满足最终一致） ， 流量将很快趋于统计学意义上的一致 ， 所以注册中心以最终一致的模型设计在生产实践中完全可以接受 。
分区容忍及可用性需求分析 接下来我们看一下网络分区（Network Partition）情况下注册中心不可用对服务调用产生的影响 ， 即 CAP 中的A不满足时带来的影响 。
考虑一个典型的ZooKeeper三机房容灾5节点部署结构 (即2-2-1结构) ， 如下图:
本文插图
当机房3出现网络分区(Network Partitioned)的时候 ， 即机房3在网络上成了孤岛 ， 我们知道虽然整体 ZooKeeper 服务是可用的 ， 但是节点ZK5是不可写的 ， 因为联系不上 Leader 。
也就是说 ， 这时候机房3的应用服务 svcB 是不可以新部署 ， 重新启动 ， 扩容或者缩容的 ， 但是站在网络和服务调用的角度看 ， 机房3的 svcA 虽然无法调用机房1和机房2的 svcB,但是与机房3的svcB之间的网络明明是 OK 的啊 ， 为什么不让我调用本机房的服务？
现在因为注册中心自身为了保脑裂(P)下的数据一致性（C）而放弃了可用性 ， 导致了同机房的服务之间出现了无法调用 ， 这是绝对不允许的！可以说在实践中 ， 注册中心不能因为自身的任何原因破坏服务之间本身的可连通性 ， 这是注册中心设计应该遵循的铁律！ 后面在注册中心客户端灾容上我们还会继续讨论 。
同时我们再考虑一下这种情况下的数据不一致性 ， 如果机房1 ， 2 ， 3之间都成了孤岛 ， 那么如果每个机房的svcA都只拿到本机房的 svcB 的ip列表 ， 也即在各机房svcB 的ip列表数据完全不一致 ， 影响是什么?
其实没啥大影响 ， 只是这种情况下 ， 全都变成了同机房调用 ， 我们在设计注册中心的时候 ， 有时候甚至会主动利用这种注册中心的数据可以不一致性 ， 来帮助应用主动做到同机房调用 ， 从而优化服务调用链路 RT 的效果！
通过以上我们的阐述可以看到 ， 在 CAP 的权衡中 ， 注册中心的可用性比数据强一致性更宝贵 ， 所以整体设计更应该偏向 AP ， 而非 CP ， 数据不一致在可接受范围 ， 而P下舍弃A却完全违反了注册中心不能因为自身的任何原因破坏服务本身的可连通性的原则 。
服务规模、容量、服务联通性 你所在公司的“微服务”规模有多大？数百微服务？部署了上百个节点？那么3年后呢？互联网是产生奇迹的地方 ， 也许你的“服务”一夜之间就家喻户晓 ， 流量倍增 ， 规模翻番！
当数据中心服务规模超过一定数量 (服务规模=F{服务pub数,服务sub数}) ， 作为注册中心的 ZooKeeper 很快就会像下图的驴子一样不堪重负
本文插图
其实当ZooKeeper用对地方时 ， 即用在粗粒度分布式锁 ， 分布式协调场景下 ， ZooKeeper 能支持的tps 和支撑的连接数是足够用的 ， 因为这些场景对于 ZooKeeper 的扩展性和容量诉求不是很强烈 。
但在服务发现和健康监测场景下 ， 随着服务规模的增大 ， 无论是应用频繁发布时的服务注册带来的写请求 ， 还是刷毫秒级的服务健康状态带来的写请求 ， 还是恨不能整个数据中心的机器或者容器皆与注册中心有长连接带来的连接压力上 ， ZooKeeper 很快就会力不从心 ， 而 ZooKeeper 的写并不是可扩展的 ， 不可以通过加节点解决水平扩展性问题 。
推荐阅读
- 互联网|上线半年收获6700万用户，这款聚焦下沉用户的陌生人社交APP是怎么做到的？
- 互联网|5G商用一周年，华为云向互联网企业大抛绣球
- 互联网|中台产品经理实战(14)：中台与SaaS、微服务关系
- 互联网|行业观察 | 你所不知道的5G消息
- 互联网|多名知名人物推特被黑，拜登奥巴马都“中招”，比尔盖茨也在其内
- 互联网|发放高利贷，还要窃取用户信息？这些金融APP在秀“道德底线”
- 互联网|东莞先知：数字智能，先觉“先知”
- 云计算|从互联网到AI崛起，上海能弯道超车吗？
- 行业互联网,5G|江苏有线顺利完成园区5G信号开通测试
- 行业互联网,AI人工智能|城市教育大脑以“ AI+ 大数据”为核心 , 引领教育变革