189 8069 5689
本篇文章给大家分享的是有关服务模型该如何理解，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
十年的天水网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。营销型网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整天水建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。成都创新互联从事“天水网站设计”,“天水网站推广”以来，每个客户项目都认真落实执行。
按照目前市场上的主流使用场景，Nacos 被分成了两块功能：服务注册发现（Naming）和配置中心（Config）。在之前的文章中我介绍了 Nacos 配置中心的实现原理，今天这篇文章所介绍的内容则是与 Nacos 服务注册发现功能相关，来聊一聊 Nacos 的服务模型。
说到服务模型，其实需要区分视角，一是用户视角，一个内核视角。即 Nacos 用户视角看到的服务模型和 Nacos 开发者设计的内核模型可能是完全不一样的，而今天的文章，是站在用户视角观察的，旨在探讨 Nacos 服务发现的最佳实践。
一般我在聊注册中心时，都会以 Zookeeper 为引子，这也是很多人最熟悉的注册中心。但如果你真的写过或看过使用 Zookeeper 作为注册中心的适配代码，会发现并不是那么容易，再加上注册中心涉及到的一致性原理，这就导致很多人对注册中心的第一印象是：这个东西好难！ 但归根到底是因为 Zookeeper 根本不是专门为注册中心而设计的，其提供的 API 以及内核设计，并没有预留出「服务模型」的概念，这就使得开发者需要自行设计一个模型，去填补 Zookeeper 和服务发现之间的鸿沟。
微服务架构逐渐深入人心后，Nacos、Consul、Eureka 等注册中心组件进入大众的视线。可以发现，这些”真正“的注册中心都有各自的「服务模型」，在使用上也更加的方便。
为什么要有「服务模型」？理论上，一个基础组件可以被塑造成任意的模样，如果你愿意，一个数据库也可以被设计成注册中心，这并不是”夸张“的修辞手法，在阿里还真有人这么干过。那么代价是什么呢？一定会在业务发展到一定体量后遇到瓶颈，一定会遇到某些极端 case 导致其无法正常工作，一定会导致其扩展性低下。正如刚学习数据结构时，同学们常见的一个疑问一样：为什么栈只能先进后出。不是所有开发都是中间件专家，所以 Nacos 设计了自己的「服务模型」，这虽然限制了使用者的”想象力“，但保障了使用者在正确地使用 Nacos。
花了一定的篇幅介绍 Nacos 为什么需要设计「服务模型」，再来看看实际的 Nacos 模型是个啥，其实没那么玄乎，一张图就能表达清楚：
与 Consul、Eureka 设计有别，Nacos 服务发现使用的领域模型是命名空间-分组-服务-集群-实例这样的多层结构。服务 Service 和实例 Instance 是核心模型，命名空间 Namespace 、分组 Group、集群 Cluster 则是在不同粒度实现了服务的隔离。
为了更好的理解两个核心模型：Service 和 Instance，我们以 Dubbo 和 SpringCloud 这两个已经适配了 Nacos 注册中心的微服务框架为例，介绍下二者是如何映射对应模型的。
Dubbo。将接口三元组（接口名+分组名+版本号）映射为 Service，将实例 IP 和端口号定义为 Instance。一个典型的注册在 Nacos 中的 Dubbo 服务：providers:com.alibaba.mse.EchoService:1.0.0:DUBBO
Spring Cloud。将应用名映射为 Service，将实例 IP 和端口号定义为 Instance。一个典型的注册在 Nacos 中的 Spring Cloud 服务：helloApp
下面我们将会更加详细地阐释 Nacos 提供的 API 和服务模型之间的关系。
需要部署一个 Nacos Server 用于测试，我这里选择直接在
https://mse.console.aliyun.com/ 购买一个 MSE 托管的 Nacos，读者们可以选择购买 MSE Nacos 或者自行搭建一个 Nacos Server。
MSE Nacos 提供的可视化控制台，也可以帮助我们更好的理解 Nacos 的服务模型。下文的一些截图，均来自 MSE Nacos 的商业化控制台。
先来实现一个最简单的服务注册与发现 demo。Nacos 支持从客户端注册服务实例和订阅服务，具体代码如下：
Properties properties = new Properties(); properties.setProperty(PropertyKeyConst.SERVER_ADDR, "mse-xxxx-p.nacos-ans.mse.aliyuncs.com:8848"); String serviceName = "nacos.test.service.1"; String instanceIp = InetAddress.getLocalHost().getHostAddress(); int instancePort = 8080; namingService.registerInstance(serviceName, instanceIp, instancePort); System.out.println(namingService.getAllInstances(serviceName));
上述代码定义了一个 service：nacos.test.service.1；定义了一个 instance，以本机 host 为 IP 和 8080 为端口号，观察实际的注册情况：
并且控制台也打印出了服务的详情。至此一个最简单的 Nacos 服务发现 demo 就已经完成了。对一些细节稍作解释：
属性 PropertyKeyConst.SERVER_ADDR 表示的是 Nacos 服务端的地址。
创建一个 NamingService 实例，客户端将为该实例创建单独的资源空间，包括缓存、线程池以及配置等。Nacos 客户端没有对该实例做单例的限制，请小心维护这个实例，以防新建多于预期的实例。
注册服务 registerInstance 使用了最简单的重载方法，只需要传入服务名、IP、端口就可以。
上述的例子中，并没有出现 Namespace、Group、Cluster 等前文提及的服务模型，我会在下面一节详细介绍，这个例子主要是为了演示 Nacos 支持的一些缺省配置，其中 Service 和 Instance 是必不可少的，这也验证了前文提到的服务和实例是 Nacos 的一等公民。
通过截图我们可以发现缺省配置的默认值：
Namespace：默认值是 public 或者空字符串，都可以代表默认命名空间。
Group：默认值是 DEFAULT_GROUP。
Cluster：默认值是 DEFAULT。
为了展现出 Nacos 服务模型的全貌，还需要介绍下实例相关的 API。例如我们希望注册的实例中，有一些能够被分配更多的流量；或者能够传入一些实例的元信息存储到 Nacos 服务端，例如 IP 所属的应用或者所在的机房，这样在客户端可以根据服务下挂载的实例元信息，来自定义负载均衡模式。Nacos 也提供了另外的注册实例接口，使得用户在注册实例时可以指定实例的属性：
/** * register a instance to service with specified instance properties. * * @param serviceName name of service * @param groupName group of service * @param instance instance to register * @throws NacosException nacos exception */ void registerInstance(String serviceName, String groupName, Instance instance) throws NacosException;
这个方法在注册实例时，可以传入一个 Instance 实例，它的属性如下：
public class Instance {
/**
* unique id of this instance.
*/
private String instanceId;
/**
* instance ip.
*/
private String ip;
/**
* instance port.
*/
private int port;
/**
* instance weight.
*/
private double weight = 1.0D;
/**
* instance health status.
*/
private boolean healthy = true;
/**
* If instance is enabled to accept request.
*/
private boolean enabled = true;
/**
* If instance is ephemeral.
*
* @since 1.0.0
*/
private boolean ephemeral = true;
/**
* cluster information of instance.
*/
private String clusterName;
/**
* Service information of instance.
*/
private String serviceName;
/**
* user extended attributes.
*/
private Map metadata = new HashMap();
} 有一些字段可以望文生义，有一些则需要花些功夫专门去了解 Nacos 的设计，我这里挑选几个我认为重要的属性重点介绍下：
healthy 实例健康状态。标识该实例是否健康，一般心跳健康检查会自动更新该字段。
enable 是否启用。它跟 healthy 区别在于，healthy 一般是由内核健康检查更新，而 enable 更多是业务语义偏多，可以完全根据业务场景操控。例如在 Dubbo 中，一般使用该字段标识某个实例 IP 的上下线状态。
ephemeral 临时实例还是持久化实例。非常关键的一个字段，需要对 Nacos 有较为深入的了解才能够理解该字段的含义。区别在于，心跳检测失败一定时间之后，实例是自动下线还是标记为不健康。一般在注册中心场景下，会使用临时实例。这样心跳检测失败之后，可以让消费者及时收到下线通知；而在 DNS 模式下，使用持久化实例较多。在《一文详解 Nacos 高可用特性》中我也介绍过，该字段还会影响到 Nacos 的一致性协议。
metadata 元数据。一个 map 结构，可以存储实例的自定义扩展信息，例如机房信息，路由标签，应用信息，权重信息等。
这些信息在由服务提供者上报之后，由服务消费者获取，从而完成信息的传递。以下是一个完整的实例注册演示代码：
