下载掌阅APP，畅读海量书库
立即打开
在微服务架构中，服务治理（Service Governance）可以说是最为关键的一个要素，因为各个微服务需要通过服务治理实现自动化的注册和发现。在本节中，我们将首先从服务治理的基本需求出发，给出注册中心的结构模型。而在本节最后，我们也会对业界主流的注册中心实现方案进行介绍，并引出本书中所要介绍的注册中心Nacos。
在微服务架构中，对于任何一个服务而言，既可以是服务提供者，也可以是服务消费者。围绕服务消费者如何调用服务提供者这个问题，需要进行服务的治理。
对于服务治理而言，可以说支持服务注册和服务发现就是它最基本也是最重要的功能需求。这个需求来源于微服务系统中复杂的服务实例状态变化。相较传统的分布式架构，在支持云原生的微服务架构中，面临的一大挑战就是服务实例的数量较多，而这些服务自身对外暴露的访问地址也具有动态性。而且，由于自动扩容、服务失败和更新等因素，服务实例的运行时状态也经常变化，如图2-2所示。
图2-2 服务实例管理中的动态性
图2-2展示的实际上就是一个服务治理的问题。我们需要管理系统中所有服务实例的运行时状态，并能够把这些状态的变化同步到各个服务中。在微服务架构中，你可以通过引入注册中心（Registration Center）轻松实现对大规模服务的高效治理。这样一来，对于服务提供者而言，就需要一个机制能够将自己的服务实例注册到服务注册中心，我们希望这个过程是自动化的而不是手工静态指定的。另外，对于服务消费者而言，我们也希望它能自动发现这些服务实例并进行远程调用。当服务实例的运行状态发生变化时，注册中心需要确保这些状态变更都能得到有效的维护和传递。
除了服务注册和发现之外，对于注册中心而言，我们还需要它具备高可用性。因为为了确保服务高可用性，也需要注册中心本身不能宕机。通过构建集群机制，服务只要连接集群中的任何一台注册中心服务器完成服务注册和发现即可，单台服务器的宕机不影响服务调用的正常进行。
在使用上，注册中心是一种服务器组件，而服务的提供者和消费者都是注册中心的客户端。这些客户端和注册中心之间需要进行交互，由于涉及服务的注册和发现、服务访问中的负载均衡等机制，需要确保交互过程简单而高效。同时，考虑到异构系统之间的交互需求，注册中心作为一种平台化解决方案也应该提供多种客户端技术的集成支持。这也是我们对比各个注册中心实现方案的考虑点之一。那么，注册中心到底应该是什么样的呢？我们一起来看一下。
注册中心是服务实例信息的存储仓库，也是服务提供者和服务消费者进行交互的媒介，充当着服务注册和发现服务器的作用。当具备服务注册中心之后，服务治理涉及的角色包括如下三种。
❑ 注册中心：提供服务注册和发现。
❑ 服务提供者：服务提供者将自身服务注册到注册中心，从而使服务消费者能够找到。
❑ 服务消费者：服务消费者从注册中心获取注册服务列表，从而实现服务消费。
微服务架构中的服务提供者和服务消费者都相当于注册中心的客户端，在服务内部都嵌入了客户端组件。在应用程序运行时，服务提供者的注册中心客户端组件会向注册中心注册自身提供的服务，而服务消费者的注册中心客户端组件则从注册中心通过一定机制获取当前订阅的服务信息。同时，为了提高服务路由的效率和容错性，服务消费者可以配备缓存机制以加速服务路由。更重要的是，当服务注册中心不可用时，服务消费者可以利用本地缓存路由实现对现有服务的可靠调用。图2-3展示了注册中心基本模型以及服务与注册中心的交互过程。
图2-3 注册中心基本模型以及服务与注册中心的交互过程
在图2-3中，基本的工作流程通过操作语义即可理解，而实现上的核心技术点在于当服务提供者实例状态发生变更时如何把变更信息同步到服务消费者。针对这一点，从架构设计上讲，比较容易想到的方式是采用轮询机制。轮询机制是一种主动拉取策略，即服务消费者定期调用注册中心提供的服务获取接口获取最新的服务列表并更新本地缓存，如图2-4所示。
图2-4 服务轮询机制
我们假定以一种分层结构来展示注册中心的内部组成，如图2-4所示，有服务A、服务B和服务C这三个服务，每个服务有两个实例节点。可以看到，轮询机制实现上就是一个定时程序，需要考虑定时的频率以确保数据同步的时效性。
还有一种确保状态信息同步的方式是推送机制。我们知道状态变更管理可以采用发布-订阅模式，体现在服务提供者可以根据服务定义发布服务，而服务消费者则通过对自己感兴趣的服务进行订阅并获取包括服务地址在内的各项元数据。发布-订阅功能还体现在状态变更推送，即当注册中心服务定义发生变化时，主动推送变更到该服务的消费者。基于发布-订阅设计思想，就诞生了一种服务监听机制。服务监听机制确保服务消费者能够实时监控服务更新状态，是一种被动接收变更通知的实现方案，通常采用服务监听机制以及回调机制，如图2-5所示。
服务消费者可以对具体的服务实例节点添加监听器，当这些节点发生变化时，注册中心就能触发监听器中的回调函数确保更新通知到每一个服务消费者。显然，使用监听和通知机制具备实时的数据同步效果。
以上关于服务治理解决方案的讨论为我们提供了理论基础。基于这些理论基础，目前市面上存在一批主流的实现工具，常见的包括Consul、Zookeeper、Eureka和Nacos等。其中Consul来自HashiCorp公司，是一款用来实现分布式环境下服务发现与配置的开源工具。而Zookeeper是Apache顶级项目，作为分布式协调领域的代表性框架被广泛用于注册中心、配置中心、分布式锁等的构建场景。Netflix的Eureka则采用了一套完全不同的实现方案，被集成到微服务开发框架Spring Cloud中。而Nacos则由阿里巴巴开发，其核心定位是一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台。目前主流的注册中心实现工具的实现机制和实现语言见表2-1。
图2-5 服务监听机制以及回调机制
表2-1 注册中心实现工具的实现机制和实现语言
在这些框架中，Zookeeper是基于监听和通知机制的典型框架，而Eureka则采用的是轮询机制来实现服务实例状态的同步，两者分别构成了这两大类实现机制中的代表性实现方案。在本章中，我们不会对所有这些注册中心都做详细展开，而是重点围绕阿里巴巴开源的Nacos框架展开讨论。事实上，本章要介绍的Nacos框架同时具备轮询机制和推送机制。