前言
英文全称Dynamic Naming and Configuration Service,Na为naming/nameServer即注册中心,co为configuration即注册中心,service是指该注册/配置中心都是以服务为核心。服务在nacos是一等公民。
在学习Nacos之前先来思考一个问题:注册中心应设计为AP还是CP系统?
参考《阿里巴巴为什么不用 ZooKeeper 做服务发现?》http://jm.taobao.org/2018/06/13/%E5%81%9A%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0%EF%BC%9F/
这篇文章的描述,阿里在很早就开始思考这个问题,对注册中心来说,AP和CP究竟哪种系统更加适合,在文中已经有详细的论证和阐述,简单来说,CP系统因为强一致性而只能放弃高可用性,但可用性对于注册中心来讲其实更为重要,注册中心不能因为自身的任何原因破坏服务之间本身的可连通性,这是注册中心设计应该遵循的铁律!一旦注册中心出现不可用,那服务的上线下线均受到影响,注册中心客户端虽然可以通过缓存等手段解决一部分可用性问题,但并无法完全避免可用性的缺失对服务间通信带来的影响。AP系统缺失了强一致性,文中提到会导致一定的流量不均衡,但随着最终一致性,流量不均衡的问题最终可以解决,但笔者认为,除了不均衡问题之外,服务下线信息如果没办法做到强一致性,还会导致增加服务失败的概率,这种服务失败的情况是否能够被业务场景所接受,也是需要考虑的因素,该如何解决和避免,是否应该在注册中心客户端层来对失败服务的ip做一定封锁,需要进一步思考。但总体来讲,比较认同AP系统更加适合作为注册中心这一结论。
下面就几个方面来介绍一下nacos注册中心的关键要点:
一、nacos如何进行服务注册、探活
服务注册方法:以Java nacos client v1.0.1 为例子,服务注册的策略的是每5秒向nacos server发送一次心跳,心跳带上了服务名,服务ip,服务端口等信息。同时 nacos server也会向client 主动发起健康检查,支持tcp/http检查。如果15秒内无心跳且健康检查失败则认为实例不健康,如果30秒内健康检查失败则剔除实例。
Zookeeper 和 Eureka 都实现了一种 TTL 的机制,就是如果客户端在一定时间内没有向注册中心发送心跳,则会将这个客户端摘除。Eureka 做的更好的一