命名空间

命名空间的目的就是了实现服务隔离，支持多应用的目的

命名空间在客户端和服务端都有体现，下面就分别来介绍下

服务端

服务端的命名空间体现在 ServerConfiguration 中的 serverName 字段，在服务注册时会使用到该字段，起到实例分组的作用。

也就是说同一个 serverName 命名空间下的不同实例会组成一个服务集群，

例如 serverName 为 open-job-worker 的实例 127.0.0.1:5200 和同样 serverName 为 open-job-worker 的实例 127.0.0.1:5201 会形成一个集群

@Data
@ConfigurationProperties(prefix = "com.saucesubfresh.rpc.server")
public class ServerConfiguration {
    /**
     * The server address
     */
    private String serverAddress = "localhost";
    /**
     * The server port
     */
    private int serverPort = 5200;
    /**
     * The name of the service registered to the nacos or zookeeper
     * if you use nacos，You should be named like this: job-server-services
     * if you use zookeeper, You should be named like this: /JobServer
     */
    private String serverName;
}

客户端

我们知道服务端的命名空间是在服务注册时会用到，起到实例分组的作用，但是命名空间在客户端这里却有两处体现：

在服务启动之后立即开始订阅所有命名空间各自实例的变化，例如实例上线、实例下线
在使用智能调用的时候用户需要指定命名空间，这样就可以在服务发现的时候通过指定的命名空间拿到该命名空间下所有健康的实例了

这里我们着重说明下客户端命名空间的加载策略，客户端的命名空间默认是从配置文件中加载的，但是你也可以自定义加载策略。

以下是命名空间从配置文件中加载的例子，这里以 Open-Crawler 为例

com:
  saucesubfresh:
    rpc:
      client:
        server-names:
          - clawlerWorker

再来看下自定义的命名空间加载策略的例子，这里以 Open-Job 为例，在 Open-Job 中我们将应用名称作为命名空间从数据库中加载

@Component
public class OpenJobNamespaceService implements NamespaceService {

    private final OpenJobAppMapper openJobAppMapper;

    public OpenJobNamespaceService(OpenJobAppMapper openJobAppMapper) {
        this.openJobAppMapper = openJobAppMapper;
    }

    @Override
    public List<String> loadNamespace() {
        List<OpenJobAppDO> openJobAppDOS = openJobAppMapper.selectList(Wrappers.lambdaQuery());
        if (CollectionUtils.isEmpty(openJobAppDOS)){
            return Collections.emptyList();
        }
        return openJobAppDOS.stream().map(OpenJobAppDO::getAppName).collect(Collectors.toList());
    }
}

Previous使用Grpc通信 Next服务注册