Spring Cloud + Nacos 引领服务治理新航向

目录

一、服务治理出现的原因

二、服务治理

三、Nacos

        3.1 领域模型

            服务

        集群

        实例

        3.2 数据模型

        3.3 服务架构

四、Nacos 与 Consul 对比

        上篇文章(探索云原生世界：Spring Cloud全方位解读——构建微服务架构的利器-CSDN博客)介绍了微服务的学习路线，以及 Spring Cloud 的组件，再来看下 Spring Cloud 的组件构成，如下图：

        本文将着重介绍 Spring Cloud Alibaba 的服务治理组件 Nacos，及其工作原理，最后在对 Nacos 与 Consul进行下对比，因为Spring Cloud 后续会逐渐去 Neflix，所以这里就不介绍 Eureka了。

一、服务治理出现的原因

        服务治理能解决什么问题呢？为什么会有服务治理的出现呢？先来看一个例子。

        假设一个系统由两个集群组成，分别是 A 和 B，每一个服务都有10个节点，如果服务 A 调用服务 B，那怎么发起调用呢？

        一种通用的做法：在服务 A 配置文件中添加服务 B 的地址，但这个地址不指向任何一台服务 B 集群中的节点，而是指向一个 VIP (虚拟 IP 地址)或者一个网关。这个 VIP 或网关背后维护了B 集群的服务节点列表，VIP 层通过负载均衡策略在将请求转到后面配置的某一台服务器，如下图：

        服务 A 与服务 B 并不直接通讯，服务调用完全依靠虚拟地址来完成。如果这时需要对服务进行扩容或缩容，必须将服务器的地址配置在虚拟地址列表中。如果你的服务有上百个，这个工作量可想而知。

        服务治理就是为了解决这个问题而诞生的，用服务治理来实现微服务中各个服务间的远程调用。

二、服务治理

        如果我们要解决中间代理的问题，那么最好的办法就是让双方直连。因此，服务治理要解决的首要任务就是服务注册与服务发现，通过这两项技术，就能让微服务之间发起面对面的直接调用。

        那么服务 A 怎么知道服务 B 中每台机器的地址呢？为了让服务 A 拿到服务 B 的地址清单，我们需要搭建一个中心化的服务注册中心，服务 B 只要将自己的信息添加到注册中心里，服务 A就能够从注册中心获取到服务 B 的所有节点列表，如下图：

        具体的步骤如下

1. 服务 B 集群向注册中心发起了注册，将自己的地址信息上报给注册中心，这个过程就是服务注册
2. 服务 A 从注册中心获取服务 B 的服务列表，或者由注册中心将服务列表的表推送给服务 A，这个过程叫做服务发现
3. 最后服务 A 根据负载均衡策略，从服务 B 的列表中选取某一个服务 B 的实例进行远程调用

        有个过程，注册中心的角色是一个中心化的信息管理者，所有的微服务节点在启动后都将自己的地址信息添加到注册中心。在启动阶段是中心化的，在运行阶段是去中心化的。在服务注册的过程中，有两个关键信息最为重要：

• 服务名称：服务名称通常默认是 spring.application.name 属性，在服务注册过程中，必须将应用服务名上报到注册中心，这样其他服务才能根据服务名称找到对应的服务节点列表。
• 地址信息：包括服务节点的IP和端口

        通过服务注册和服务发现，我们已经能够实现端到端的调用了，但是如果出现了异常怎么办？缺少容错机制。

  &