preface

In previous articles, we analyzed the Nacos Configuration center. The core of the configuration center is the creation, read, and push of configurations.

The registry has one more service probe module than the configuration center. The similarity between them is very high, and even ali’s internal registry is called ConfigServer.

The Nacos registry is intended to be analyzed in several modules, and this article focuses on the outline design, based on version 2.0.0.

Environment set up

Nacos source code to build source reading and debugging environment, can refer to “Nacos configuration center module in detail” Nacos debug environment construction part.

The JVM parameter can be specified to start only the Naming module or not. By default, both modules are started.

Test a copy of NamingExample under the example module.

Design of the profile

Service discovery Model

The service discovery model from the client perspective (note: the model definition from the server perspective is different from the client perspective) includes the following:

  • Service: Service
  • Cluster: Cluster
  • Examples of the Instance:

Code comments: We introduce a ‘service –> cluster –> instance’ model, in which service stores a list of clusters, which contains a list of instances

Their relationship is as follows

Service

  • Name: indicates the service name
  • ProtectThreshold: protection threshold, which limits the maximum proportion of instances that can be removed by probe
  • AppName: indicates the application name of the service
  • GroupName: groupName
  • Metadata: indicates metadata

Cluster

  • ServiceName: indicates the name of the service
  • Name: indicates the cluster name
  • HealthChecker: Service checker configuration. This configuration takes effect only for active checker on the server. The options are TCP, HTTP, MySQL, or None
  • DefaultPort: indicates the defaultPort
  • DefaultCheckPort: Default probe port
  • UseIPPort4Check: Indicates whether to use port for probing
  • Metadata: indicates metadata

Instance

  • InstanceId: instanceId, the unique identifier provided by NacossimpleandsnowflakeTwo algorithms to generate. Default issimple, its generation mode isip#port#clusterName#serviceName
  • IP: indicates the IP address of the instance
  • Port: instance port
  • Weight: instance weight
  • Healthy: indicates the instance health status
  • ClusterName: indicates the name of the cluster
  • ServiceName: indicates the name of the service
  • Metadata: indicates metadata
  • Enabled: indicates whether to receive requests. This parameter can be used to temporarily disable or pick up streams
  • Ephemeral: Ephemeral or not, as described later
  • GetInstanceHeartBeatInterval: for instance the heart report time interval, the default 5 seconds, can be configured
  • GetInstanceHeartBeatTimeOut: get heartbeat timeout, 15 seconds, configuration
  • GetIpDeleteTimeout: Specifies the timeout period for an IP address to be deleted. The default value is 30 seconds
  • GetInstanceIdGenerator: Gets the ID generator

In addition to the above three-tier model, the Nacos registry and the configuration center have the same namespace design, which is bound to the client and can isolate the environment and tenants.

Interface design

  • RegisterInstance: Registers an instance
  • DeregisterInstance: deregisterInstance
  • GetAllInstances: getAllInstances of a service (including unhealthy)
  • SelectInstances: Retrieves an instance of a service based on a condition
  • SelectOneHealthyInstance: Obtain a healthy instance of the service based on the load balancing policy
  • I subscribe
  • Unsubscribe: Unsubscribe from a service
  • GetServicesOfServer: Obtains all services based on paging conditions

The interaction process

Nacos 2.0 provides two processes for ephemeral for different instances:

  • Ephemeral =false, a permanent instance, interacts with the server using HTTP requests, data is synchronized between server nodes using raft protocol, and health checks are made using active probing on the server
  • Ephemeral =true, ephemeral instances, GRPC requests for interactions with the server, distro protocol for data synchronization between server nodes, KeepAlive TCP connections for health checks

The interaction flow of temporary instances

  • The client initializes and establishes a connection with the server

    • Establish a persistent connection to only one server node

  • The client registers the service, packages data such as serviceName, IP, port, and clusterName, and sends GRPC requests

    • In addition, the client caches registered services. When the client is disconnected from the server and reconnects to the server, the client registers the data with the server again

  • The server receives the registration request from the client and stores the registration information in the client object (used to save all the data of the client). And trigger ClientChangedEvent, ClientRegisterServiceEvent, InstanceMetadataEvent

    • ClientChangedEvent triggers data synchronization between Server nodes (Distro protocol)
    • ClientRegisterServiceEvent triggered update publisherIndexes (save service = > clientId Map < service, Set >, which the client is registered the service index), It also fires a ServiceChangedEvent event, which is responsible for pushing to clients listening on the service
    • InstanceMetadataEvent handles metadata. Nacos separates metadata from basic data in 2.0 and divides it into different processing processes

  • Client Subscription Service

    • Generate a key based on serviceName, groupName, and clusters, create an eventListener, send a subscription request to the server, and cache the subscription information to send the information to the server again after the connection is disconnected and reconnected

  • The server receives a subscription request from the client. Procedure

    • Packaged subscription information to subscribers, and in the client object, triggering ClientSubscribeServiceEvent events
    • ClientSubscribeServiceEvent event update subscriberIndexes (save service = > clientId Map < service, Set >, what the client is subscribed to the service index), The ServiceSubscribedEvent event is also triggered
    • ServiceSubscribedEvent pushes the latest data of the service to the client 500ms later

  • The reverse operations, such as logout and unsubscription, are similar to the forward operations and are not described here

The last

This paper analyzes the model design, interface design and interaction process of Nacos 2.0 in general. After reading it, we have an overall understanding of Nacos service discovery. The following sections will cover the details, such as dubbo Nacos extensions, conformance protocols, probes, CMDB extensions, etc.

About the author: focus on back-end middleware development, public number “catch bug master” author, follow me, give you the purest technical dry goods