下载掌阅APP，畅读海量书库
立即打开
作为一款流行的注册中心开源框架，Nacos为开发人员提供的不仅仅是基础的服务注册和发现机制，同时也开放了一组服务治理的高级特性。在本节中，我们将从服务路由机制和服务实例健康检测这两大高级特性出发继续剖析Nacos框架。
针对Nacos服务路由机制，我们重点介绍就近访问、保护阈值和权重这三个功能特性。
1.就近访问
在2.4节讨论Nacos分级模型时，我们提到了集群的概念，而这里介绍的就近访问就和集群概念有关。所谓的就近访问，指的是在服务调用时，Nacos会优先选择同一个集群内的实例进行调用。
我们知道在Nacos中，一个服务可以有多个实例，每个实例都可以被分配到特定的集群中。当一个服务A需要调用另一个服务B时，Nacos会首先查看服务A实例所属的集群。然后，在调用服务B时，Nacos会倾向选择与服务A相同集群的服务B实例进行调用。这种就近访问的机制可以减少网络延迟，并且提高服务调用的效率。图2-19展示的就是就近访问的执行效果。
在图2-19中可以看到，对于provider-service这个服务而言，存在Hangzhou和Shanghai这两个集群。基于就近访问机制，作为消费者的consumer-service会优先访问位于同一Hangzhou集群中的provider-service服务实例。只有当同集群中的目标服务实例不可用时，consumer-service才会去访问位于另一个shanghai集群中的provider-service服务实例。在这个时候，Nacos会报警提示，并在确定可用实例列表后采用一定的负载均衡策略挑选目标服务实例。开发人员可以基于com.alibaba.cloud.nacos.ribbon.NacosRule类中定义的负载均衡策略实现这一目标。
图2-19 Nacos就近访问的执行效果
通过使用就近访问，Nacos在服务调用时能够更智能地选择相同集群内的实例，这有助于提高整体的系统性能和可靠性。同时，它也适用于一些特定的场景，例如在分布式部署的集群环境中，可以将相互依赖的服务部署在同一个集群内，以降低跨集群通信的成本和风险。
2.保护阈值
在一般情况下，当服务消费者执行服务发现时，Nacos会返回给消费者一组可用的服务实例列表。然后服务消费者从这些实例中选择目标实例进行调用，通常做法是通过负载均衡算法选择一个健康的实例。这种做法可以确保请求被分散到各个健康实例上，实现负载均衡和高可用性。但有些时候系统会出现异常而导致很多服务实例变得不可用，这时候Nacos应该怎么办呢？
保护阈值是设置集群中健康实例占比允许的最小值，它需要设置一个0～1的浮点值，默认值为0，如图2-20所示。当集群中的健康实例占比小于所设置的保护阈值时，就会触发阈值保护功能。而当触发阈值保护功能后，如果当前服务的健康实例数量低于该阈值，那么在服务发现过程中，Nacos会将所有实例（包括健康和不健康的实例）都返回给消费者。
图2-20 Nacos保护阈值设置
当服务消费者执行对服务的远程调用时，负载均衡算法会确定目标服务实例。这意味着有可能选择到健康的实例，也可能选择到不健康的实例。这时候会有一定的调用风险，因为不健康的实例可能无法正常处理请求或返回错误响应。但这样做的好处是可以避免将大量请求发送到少数健康实例上，导致它们压力过大而无法正常处理请求。换句话说，尽管会有失败响应，但保护阈值能避免因为服务依赖导致的雪崩效应（Avalanche Effect）。关于雪崩效应我们在本书第9章中还会有详细讨论。
3.权重
在现实环境中，服务器设备性能存在差异，部分实例所在机器性能较好，另一些则相对较差。我们希望性能好的机器能够承担更多的用户请求，但默认情况下NacosRule（负载均衡策略）是同集群内随机挑选，不会考虑机器的性能问题。为此，Nacos专门提供了权重这个概念来控制访问频率。我们可以在Nacos控制台中设置权重，如图2-21所示。需要注意的是，权重是针对服务实例进行设置的，而前面介绍的保护阈值则是作用于服务级别。
图2-21 Nacos权重设置
权重值大小在0～1之间，权重越大则访问频率越高。如果权重被设置为0，则该实例永远不会被访问。另外，在服务升级的时候，我们也可以通过调整权重进行平滑升级。例如，我们可以先把order-service的第一个服务实例权重调节为0，让用户先流向order-service的其他实例。等到order-service的第一个实例升级完毕之后，再把它的权重从0调到0.1，让一部分用户先体验，用户体验稳定后就可以继续往上调权重。
对于一个注册中心而言，不仅仅需要提供服务注册和发现功能，还应该维护服务实例的生命周期并实现对服务可用性进行监测，对注册中心中不健康或过期的服务进行标识或剔除，以保证服务的消费者尽可能地查询到可用的服务列表。这就是服务实例健康检测的作用和价值，在本节中，我们将围绕Nacos的这项高级特性展开讨论。
1.健康检测基本思路
通常，验证一个服务是否健康的基本思路有两种。
❑ 客户端主动上报机制（心跳机制）：客户端主动上报，告诉服务端自己的健康状态，如果一段时间没有上报则就认为服务已不健康。
❑ 服务端主动探测机制：服务端主动对客户端发起探测，看看客户端是否有响应，如果没有响应则认为该服务已不健康。
图2-22展示了这两种机制的基本运行过程。在当前主流的注册中心中，客户端主动上报机制主要采用的是TTL（Time To Live，存活时间），即客户端在一定时间没向注册中心发送心跳，注册中心就认为此服务不健康，进而触发后续剔除逻辑。而对于主动探测，根据不同场景，不同注册中心采用的实现策略也有所不同。
图2-22 健康检测的两种机制的基本运行过程
2.Nacos健康检测机制
理解了健康检测的两种基本实现思路之后，让我们来到Nacos框架，看看这个框架采用的是哪一种思路。要想明确这一点，我们首先需要分析Nacos提供的两种服务实例类型，即临时实例和永久实例。
❑ 临时实例：临时实例临时存在于注册中心，在服务下线或不可用时被注册中心剔除。临时实例会与注册中心保持心跳，注册中心在一段时间内没有接收到来自客户端的心跳后就将实例设置为不健康，然后在一段时间后进行剔除。
❑ 永久实例：永久实例在被删除之前会永久留存于注册中心，且不会主动向注册中心上报心跳，这时就要注册中心主动探活。
基于Nacos所具有的两种不同服务实例，我们明确了该框架实际上综合采用了客户端主动上报和服务端主动探测这两种机制，如图2-23所示。
对于临时实例而言，Nacos客户端会维护一个定时任务，每隔5s发送一次心跳请求。Nacos服务端在15s内如果没有收到客户端的心跳请求，会将该实例设置为不健康。更进一步，Nacos服务端在30s内没有收到心跳，就会剔除这个临时实例。当然，这里的15s和30s都是可以配置的参数，配置方法如代码清单2-10所示。
图2-23 Nacos健康检测机制
代码清单2-10 Nacos心跳参数配置代码
而针对永久实例探测，采用的是服务端主动健康检测方式，检测周期为（2000+5000）ms内的一个随机数。请注意，永久实例被检测异常后只会标记为不健康，并不会物理删除。因为永久实例在被主动删除前将一直存在，因此定时任务会不断探测服务健康状态，造成浪费。因此对于那些不希望校验其健康状态的服务，Nacos也提供白名单配置。当用户将服务配置到该白名单中，Nacos就会放弃对其健康检查，服务实例的健康状态始终为用户传入的健康状态。