阿里巴巴 Dubbo Nacos 服务发现开发最佳实践

Nacos 是阿里巴巴在服务发现与配置管理领域开源的新产品，由在其内部生产上久经考验的相关产品如 Diamond，VIPServer 等演化而来。而其中的服务发现功能，在内部支撑着百万级的连接和亿级的 QPS 服务调用。开源的 Nacos 虽然为了能够符合开源质量的标准，在内部基础上做了一些代码的重构和精炼，但是整体架构和内部是一致的。阿里巴巴为什么选用目前 Nacos 所使用的架构，这不是本篇文章要讨论的，本文意在帮助大家找到一个使用 Nacos 服务发现的最佳姿势，用法优劣并无绝对，也希望 Nacos 社区积极将怎么使用 Nacos 服务发现功能开放交流及贡献代码，大家一起参与 Nacos 产品的开源演进，为国内自主的服务发现产品添砖加瓦。

Nacos 服务发现提供与其他服务发现产品不太一样的机制以及概念，在这里稍作介绍，下文中的内容都会多次提到这里介绍的概念，因此掌握这些概念，对于用好 Nacos 服务发现至关重要。

不同于 Consul, Eureka, Nacos 的服务发现使用的领域数据模型是服务 - 集群 - 实例这样的三层结构。最上面是服务，注册端（服务发布者）和订阅端（服务消费者）使用服务来与其他服务做区分，服务发现中，服务是必须指定的。集群则是中间一层，一个服务又会划分为多个集群，每个集群都有它的自定义配置，Nacos 提供了一个默认集群和相应的默认配置，在不需要多集群的场景下，可以不用指定集群。最下一层是实例，每个集群又会包含多个实例，这样对服务进行发现时，可以发现多个集群的所有实例，也可以指定集群，来发现特定集群的实例。

首先，需要有一个 Nacos Server 部署起来，目前 Nacos 支持单机模式，也支持集群模式，部署文档可以参考 Nacos 快速入门。然后添加 Nacos 客户端最新版本依赖：

<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
    <version>[latest-version]</version>
</dependency>

你可以配置从中央仓库直接依赖，也可以将 Nacos 最新源码下载下来，本地构建客户端版本。

我们先来进行一个最简单的服务注册与发现。Nacos 支持从客户端注册服务实例和订阅服务，具体步骤如下：

1. 配置 Nacos 客户端 Properties：

   Properties properties = new Properties();
   properties.setProperty(PropertyKeyConst.SERVER_ADDR, "127.0.0.1:8848");

2. 创建 Nacos Naming 客户端：

   NamingService namingService = NacosFactory.createNamingService(properties);

3. 注册一个实例：

   namingService.registerInstance("nacos.test.1", InetAddress.getLocalHost().getHostAddress(), 8080);

4. 查找这个服务的实例：

   System.out.println(namingService.getAllInstances("nacos.test.1"));

至此一个最简单的 Nacos 服务发现的使用已经完成了。这里要对一些细节稍作解释。首先在第一步中，属性 PropertyKeyConst.SERVER_ADDR 表示的是 Nacos 服务端的地址，这个地址的格式为 IP:port,IP:port。对于单机版，只需要指定一个 IP:port。甚至您可以将端口省略，这样将会访问 Nacos 的默认端口 8848。在第二步中，将创建一个 NamingService 实例，客户端将为该实例创建单独的资源空间，包括缓存、线程池以及配置等。Nacos 客户端没有对该实例做单例的限制，请小心维护这个实例，以防新建了多于预期的实例。第三步注册服务中，使用的是最简单的 API 注册方式，只需要传入服务名、IP、端口就可以。第四步是获取服务下的所有实例列表，包括健康和不健康的。

在一些场景中，我们希望注册的实例中，有一些能够被分配更多的流量，而另外一些分配较少的流量，或者能够传入一些实例的元信息存储到 Nacos 服务端，例如 IP 所属的应用或者所在的机房，这样在客户端可以根据服务下挂载的实例的元信息，来自定义负载均衡模式。别担心，我们有另外的注册实例接口，让你可以在注册的时候指定实例的属性：

    /**
     * Register a instance to service with specified instance properties
     *
     * @param serviceName name of service
     * @param instance    instance to register
     * @throws NacosException
     */
    void registerInstance(String serviceName, Instance instance) throws NacosException;

这个方法可以在注册服务的时候，传入一个 Instanc 实例，而在 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
     */
    @JSONField(name = "valid")
    private boolean healthy = true;

    /**
     * Cluster information of instance
     */
    @JSONField(serialize = false)
    private Cluster cluster = new Cluster();

    /**
     * Service information of instance
     */
    @JSONField(serialize = false)
    private Service service;

    /**
     * User extended attributes
     */
    private Map<String, String> metadata = new HashMap<String, String>();
    ....
}

其中，InstanceId 是由服务端生成返回给客户端，用于唯一标识该实例。IP、端口是实例的基本属性，除此之外，还有 weight 权重，可以设置该实例所分配流量的多少，这应该也比较好理解，权重越大，实例分配的流量就会越大。healthy 字段代表该实例是否健康，这个值也是由服务端返回给客户端的。cluster 和 service 分别表示该实例对应的集群和服务的一些信息，这些信息会在下面做介绍。最后是实例的元数据，这个元数据一个 String 对 String 的 Map。那么可以用如下代码来注册一个自定义实例：

Instance instance = new Instance();
instance.setIp(InetAddress.getLocalHost().getHostAddress());
instance.setPort(8080);
instance.setWeight(100);

Map<String, String> metadata = new HashMap<String, String>(16);
metadata.put("app", "nacos");
metadata.put("site", "beijing");
instance.setMetadata(metadata);

namingService.registerInstance("nacos.test.1", instance);

Nacos 引入了集群的概念，在服务这个维度下面，可以对服务下的实例列表再做个划分。这在阿里巴巴内部非常普遍。一个典型的场景是这个服务下的实例，需要配置多种健康检查方式，有一些实例使用 TCP 的健康检查方式，另外一些使用 HTTP 的健康检查方式。另一个场景是，这个服务下挂载的机器分属不同的环境，我们希望能够在某些情况下（包括演练）将某个环境的流量全部切走，这样可以通过配置一个环境属于一个集群，来做到一次性切流。

在客户端构建自定义集群，有一些陷阱需要小心。当前我们只有注册实例的接口，实例内部的 cluster 字段可以配置集群的属性。但是多个实例之间如果配置了不同的集群属性，这时候会发生什么呢？Nacos 只会接受第一次注册该集群所传入的集群属性，也就是说，先注册的实例，获得优先权，将它对应的集群信息注册到 Nacos 服务端。只有 Nacos 服务端已经存在该集群的配置，后续的注册请求里的集群信息，都会被忽略。为了确保你的应用保持预期的行为，请务必让同一个集群下的实例使用相同的集群配置。

下面来看看可以为集群定义哪些配置：

public class Cluster {

    /**
     * Name of belonging service
     */
    private String serviceName;

    /**
     * Name of cluster
     */
    private String name = "";

    /**
     * Health check config of this cluster
     */
    private AbstractHealthChecker healthChecker = new AbstractHealthChecker.Tcp();

    /**
     * Default registered port for instances in this cluster.
     */
    private int defaultPort = 80;

    /**
     * Default health check port of instances in this cluster.
     */
    private int defaultCheckPort = 80;

    /**
     * Whether or not use instance port to do health check.
     */
    private boolean useIPPort4Check = true;

    private Map<String, String> metadata = new HashMap<String, String>();
    ...
}

首先是集群对应的服务名，用来表示该集群所属的服务；然后是集群的名字、健康检查方式、默认的端口、默认的健康检查端口以及是否使用是的端口做健康检查。我们先来说简单的，默认端口表示注册时实例默认的端口，这个在客户端并没有体现，但是当使用 API 注册实例的时候，端口是可以不传入的，此时就会用这个默认端口作为实例的端口。然后是默认的健康检查端口，当健康检查方式中没有配置端口时，就会用这个端口来和实例通信，进行健康检查。下一个属性是是否使用实例端口做健康检查，如果设为 true，则会使用实例注册的端口来和实例进行通信。最后一个属性是集群的元数据，Nacos 支持多个维度的元数据，实例支持，集群支持，下面介绍的服务属性也支持。

健康检查方式，客户端心跳是一种模式，由客户端主动上报健康状态。服务端检测是另外一种模式，Nacos 目前支持三种：TCP、HTTP 和 MYSQL。TCP 方式会从 Nacos 服务端建立一个连接到实例，如果连接建立成功，则表示该实例健康。HTTP 方式则会从 Nacos 服务端想实例发起一个 HTTP 请求，可以配置的属性有访问的相对路径，访问的 HTTP 头部，这个头部使用竖线进行分割，以及预期的请求返回码，默认为 200：

private String path = "";
private String headers = "";
private int expectedResponseCode = 200;

MYSQL 健康检查方式，则可以让 Nacos 往实例执行一条 MySQL 命令，可以配置的属性有用户名、密码和执行的命令。执行结果如果不抛异常，则表示实例健康：

private String user;
private String pwd;
private String cmd;

同理，服务也可能需要自定义的配置，Nacos 的服务随着实例的注册而存在，并随着所有实例的注销而消亡。目前除了使用 HTTP API 可以修改服务的属性外（这将在未来的篇章中进行介绍），就只能使用注册实例时传入服务属性来进行服务的自定义配置。这里的服务与 Consul 或者 Eureka 不同，Consul 与 Eureka 的服务其实就是指的实例，而每个实例有一个服务名，通过这个服务名来获取相同服务名下的实例列表，服务本身并不是一个数据实体。在真正的生产环境中，我们认为服务本身也是具有数据存储需求的，例如作用于服务下所有实例的配置、权限控制等。虽然有一些配置可以放到实例级别，例如健康检查是否开启。但是当服务的规模成千上万后，想要整体修改这些实例的健康检查开关，就是一个繁重的运维操作。另一些配置，例如下文会提到的健康保护阈值，是一定是一个服务只有一个唯一的值的，多个值将会造成逻辑上的冲突。

    /**
     * Service name
     */
    private String name;

    /**
     * Protect threshold
     */
    private float protectThreshold = 0.0F;

    /**
     * Application name of this service
     */
    private String app;

    /**
     * Service group which is meant to classify services into different sets.
     */
    private String group;

    /**
     * Health check mode.
     */
    private String healthCheckMode;

    private Map<String, String> metadata = new HashMap<String, String>();

服务的属性存储在 Service 类中，自上而下，依次是服务的名称、服务的健康保护阈值、服务的应用名、服务的分组、服务的健康检查模式以及服务的元数据。相关概念这里不再做一一陈述，你可以参考 Nacos 官网 概念介绍。这里要提到的是服务的健康保护阈值，在阿里巴巴内部，这个值被广泛的设置和调优。在这里对该属性的初衷做一个简单的介绍。分布式服务场景下的一个问题是在部分实例不健康的情况下，是否能够将流所有流量引向其他健康实例？在一些情况下，这可能造成雪崩效应。即本来健康的实例被多余的流量冲击，也变得不健康，然后导致健康的实例越来越少，最后整个服务崩溃。此时可以使用这个健康保护阈值，当健康实例与所有实例的比例小于这个值的时候，则认为所有实例都是健康的，这样虽然部分流量流向了不健康的实例，但是剩余健康的实例还是能够正常访问的。

Nacos 的服务发现，有主动拉取和推送两种模式，这与一般的服务发现架构相同。在拉取方式中，提供了三个方法，一个是查询所有注册的实例，一个是只查询健康且上线的实例，还有一个是获取一个健康且上线的实例。一般情况下，订阅端并不关心不健康的实例或者权重设为 0 的实例，但是也不排除一些场景下，有一些运维或者管理的场景需要拿到所有的实例。目前的版本同时还支持根据服务端设定的负载均衡策略，来查询单个可用的实例。就好像 DNS 解析一样，虽然每次都返回一个后端 IP，但是整体可以保证域名挂载的所有 IP 会按照一定的策略都能够被客户端解析到。

/**
 * Get all instances of a service
 *
 * @param serviceName name of service
 * @return A list of instance
 * @throws NacosException
 */
List<Instance> getAllInstances(String serviceName) throws NacosException;

/**
 * Get qualified instances of service
 *
 * @param serviceName name of service
 * @param healthy     a flag to indicate returning healthy or unhealthy instances
 * @return A qualified list of instance
 * @throws NacosException
 */
List<Instance> selectInstances(String serviceName, boolean healthy) throws NacosException;

/**
 * Select one healthy instance of service using predefined load balance strategy
 *
 * @param serviceName name of service
 * @return qualified instance
 * @throws NacosException
 */
Instance selectOneHealthyInstance(String serviceName) throws NacosException;

前两个查询方法会返回所有实例的列表，这允许用户通过额外的工作，将实例的权重或者元数据运用到负载均衡中。对于一般的微服务场景，针对每个实例轮询，这样已经足够了。事实上，不管是在 Eureka 还是 Consul 里，其原生客户端都是只负责服务的发现，并不支持负载均衡。这样就需要第三方的 ribbon 或者 fabio 来完成负载均衡工作，此时它们的负载均衡，是完全放在客户端的。

Nacos 也会支持客户端侧的负载均衡，并支持用户扩展的负载均衡策略。不过在阿里巴巴内部，通常只需要由服务端来配置负载均衡策略，所有的调用端不区分业务的使用同一套负载均衡策略。因为实际上，调用端往往并不关心自身访问的服务的流量分配，而只需要一个可用的服务节点就可以了。而服务提供端，则由于其部署规模很大和部署环境的复杂，需要对环境信息敏感的流量分配以及对流量的绝对控制权。这时，往往需要提供端审慎的配置好统一的负载均衡策略，来保证所有订阅端按照这个策略来进行访问。

除了主动查询实例列表，Nacos 还提供订阅模式来感知服务下实例列表的变化，包括服务配置或者实例配置的变化。可以使用下面的接口来进行订阅或者取消订阅：

/**
 * Subscribe service to receive events of instances alteration
 *
 * @param serviceName name of service
 * @param listener    event listener
 * @throws NacosException
 */
void subscribe(String serviceName, EventListener listener) throws NacosException;
/**
 * Unsubscribe event listener of service
 *
 * @param serviceName name of service
 * @param listener    event listener
 * @throws NacosException
 */
void unsubscribe(String serviceName, EventListener listener) throws NacosException;

Nacos 0.3.0 版本上线了控制台，作为生产环境基本的运维工具，服务发现也通过控制台释放了部分的运维能力。虽然控制台承担的是运维为主的工作，但是开发人员也需要通过控制台来查看当前服务的注册状态和健康状态等，服务发现的控制台页面介绍可以参考 https://nacos.io/en-us/blog/discovery-console.html。虽然这篇文章中的一些页面通过社区的反馈而做了细微的调整，但是通过这篇文章应该可以掌握怎么使用服务发现的控制台了。控制台的启动方式也很简单，将 Nacos 安装包下载安装启动（安装教程）之后，直接访问：http://localhost:8848/nacos/index.html 即可打开最新的控制台界面。

Nacos 目前的版本，集成了服务发现和配置管理的基本能力以及部分高级特性。作为最小生产可用版本，Nacos 未来还会继续开放新特性，结合 SpringCloud、K8S、Dubbo 等生态，为开发者提供极致易用和稳定的服务管理和配置管理能力。在可预期的几个版本内，将会支持元数据的管理及 DNS 的服务发现。争取将使用 Nacos，作为服务发现和配置管理选型的最佳实践。