nacos在它的官网上是这样介绍自己的
一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台
它可作为服务的注册中心,也可用于配置的管理。作为注册中心强调了“更易于构建云原生应用”。注册中心我们可能更加熟悉zookeeper,这里做一个简单的对比
特性 | zookeeper | nacos |
---|---|---|
一致性协议 | CP | CP + AP |
健康检查 | Keep Alive | tcp/http/mysql/client beat |
负载均衡 | 无 | 权重/selector/metadata |
多数据中心 | 不支持 | 支持 |
跨注册中心同步 | 不支持 | 支持 |
雪崩保护 | 无 | 有 |
访问协议 | tcp | http/dns |
k8s集成 | 不支持 | 支持 |
dubbo集成 | 支持 | 支持 |
在介绍一致性协议前先了解一下CAP理论
分布式系统必须具有分区容错性,一致性与可用性只能选择其一,如果选择一致性,必须在某节点写入时,数据同步到其他节点完成后才可以响应下一个请求,这段时间内服务是不可用的;反之选择可用性,则一致性无法保证,这就是CAP理论
作为注册中心,P要保证,C和A需要权衡;常见的一致性协议有paxos、raft,他们都是强一致性协议(CP),然而今天要介绍的nacos的distro协议是弱一致协议(AP),即最终一致性协议。注册中心到底该是AP还是CP,推荐阅读阿里中间件的博客《阿里巴巴为什么不用zookeeper?》(点击阅读原文直达)
distro协议网上的资料比较少,因为它是阿里“自创的协议“,通过源码总结一下distro协议的关键点:
通过几个特殊场景来加深一下理解