正文
Nacos
订阅服务，发起服务调用；
从上图可知，任何一个
Kubernetes
集群出现故障都不会影响整个系统的服务。因此，
Nacos
能大幅提升
K8s
体系微服务系统的可靠性。
面向失败设计
针对微服务系统常见的问题，
Nacos
做了多项面向失败的设计，帮助提升系统可靠性。本节重点介绍其中两个：客户端缓存和推空保护。
客户端缓存提高极端情况下系统可靠性
在
Kubernetes
系统中，
CoreDNS
是服务发现的核心组件，所有
DNS
请求都经过
CoreDNS
。一旦
CoreDNS
故障，所有服务调用都会受到影响。跟
Kubernetes
服务发现不同，
Nacos
客户端保存了缓存数据，在服务端故障无法更新服务
IP
列表的情况下，可以继续使用缓存提供服务，不会影响运行时服务调用。
推空保护防止服务实例被误下线
当
Nacos
服务端发现某个服务下的实例全部下线时，可以自动触发保护逻辑，不会给客户端推送空
IP
列表。推空保护策略能预防因网络抖动或运维失误等导致的服务实例全部异常下线问题，保障业务运行可靠性。
二、如何提升系统可伸缩性
信息系统不需要对本身进行大量修改，只需要通过增加软硬件资源使服务容量产生线性
(
理想情况下
)
增长的特性称为可伸缩性。
在微服务架构下，传统单体应用被切分为多个小应用提供某些独立功能。随着业务发展，服务数量可能会出现爆发式增长。以淘宝为例，仅仅
3
年时间微服务实例规模就从十万级别暴涨到了百万级别。微服务数量爆发式增长对注册配置中心的可伸缩性提出了很高的要求。
Kubernetes
服务发现的核心组件之一是
etcd
，系统所有微服务相关数据均存储于其中。但
etcd
是基于
raft
一致性协议开发的系统，
Raft
协议本身的特性决定所有写操作必须由
Leader
执行。因此，
etcd
可伸缩性较差，无法通过水平扩容解决微服务大规模增长带来的压力。
那如何提升系统的可伸缩性呢？一种方案是业务拆分，即把业务按照一定的逻辑拆分到多个
Kubernetes
集群，每个
Kubernetes
内部业务封闭，
但成本很高，可能会改变整个业务架构；另一种方案是引入可伸缩性好的注册配置中心。
与
etcd
不同，
Nacos
服务发现能力基于自研的
Distro
协议构建，每个服务端均可提供写服务，其性能随着系统的水平扩展而提高。因此，
Nacos
作为
Kubernetes
集群的注册配置中心，可以大幅提高整个系统的可伸缩能力。
三、如何提升系统性能
Kubernetes
系统内服务发现主要有两种方式：环境变量和
DNS
。默认情况下，
Kubernetes
会为每个服务自动生成一个环境变量，并注入到
Pod
中。如果业务规模很大，环境变量过多的问题就不可避免。环境变量过多会导致
Pod
启动过程很慢，笔者就多次遇到环境变量过多导致
Pod
无法启动的问题。
DNS
服务发现方式允许开发者像调用普通域名一样调用
Kubernetes
内的服务，为多语言技术栈开发带来了很大便利。但频繁的
DNS
解析一方面会导致请求响应时间变慢，另一方面也会有一定的资源消耗。笔者曾做过一个简单的实验，对比直接以
DNS
域名方式调用和以
IP
直连方式调用的响应时间。结果显示，平均每次调用
DNS
方式的
RT
比直连慢
3%-5%
。
3%-5%
的延迟看起来微不足道，复杂业务可能都会有多次甚至几十次的调用，累积起来的延迟对终端用户的体验影响还是比较大的。
而
Nacos
服务发现方式，通常和微服务框架（
SpringCloud/Dubbo
等）结合，推送
IP
列表给框架，然后框架用
IP
直连的方式发起调用，省去了
DNS
解析的消耗。
下图简要画出了
