06 Challenges in Managing Multiple Services and Breaking Service Registry & Discovery #

After a systematic introduction to the Spring Cloud and Spring Cloud Alibaba projects in the previous article, I believe you now have a general understanding of these two projects. In this article, we will officially enter the second part of this course and start developing our business.

Service Invocation Problem #

When analyzing business requirements, there is a simple feature: members can open a monthly card, and at the same time, they need to add corresponding points. The feature of opening a monthly card is maintained in the member service module, while the feature of adding points is maintained in the points service module. This involves the problem of service invocation between two modules.

Single instance situation: Point-to-point HTTP direct invocation can be used by using the IP + Port + interface format. WebService services can also be exposed to be called by external modules, but WebService is slightly heavier than HTTP in terms of form. In the actual business development process, more and more product developments are using lightweight HTTP protocol for data interaction. If there are more modules, it will form a spider web, which is very unfavorable for development and maintenance.

Multiple instance situation: To deal with the pressure of services, using multiple instance cluster deployment has become a simple and convenient solution. However, after deploying multiple instances, there is a direct problem: how does the caller know which instance to call? If one instance fails, how to move the request to another instance? If load balancing is used, it is often static. In the case of service unavailability, how can the load balancing list be dynamically updated to ensure normal invocation by the caller?

Faced with these two situations, the need for a service registry center is urgent, to centrally and dynamically manage all services.

Service Registry Center #

The service registry center is the core module of the distributed service framework. The functions that need to be implemented include service registration, subscription, deregistration, and notification.

All services connect to the registry center and are centrally configured and managed by the registry center, rather than being directly called by the instance itself. The process of service management is roughly as follows:

1. When the service provider starts, it actively submits the information of the service provider to the registry center for service registration.
2. When the service caller starts, it downloads the information of the service provider from the registry center to the caller’s local machine. The caller selects a service instance from the local service provider list based on some load balancing strategy and initiates a remote call. This is a point-to-point call.
3. The registry center can perceive that a service provider instance goes offline. It will clear the information of that instance from the registry center and notify every instance in the service caller cluster, telling them not to call this instance anymore to avoid call failures.

There are many products to choose from when developing a service registry center:

• Consul
• ZooKeeper
• Etcd
• Eureka
• Nacos

For example, when developing with Dubbo, ZooKeeper is often used, and when developing with Spring Cloud, Eureka is used. The community also provides mature implementation solutions for all of these registry centers. In this case, we will use Nacos as the service registry center. If you are interested, you can research other registry centers on your own, as the basic applications are relatively simple.

Nacos Application #

Official website: https://nacos.io/en-us/. Nacos is an open-source project from Alibaba, which is an easy-to-use platform for building cloud-native applications with dynamic service discovery, configuration management, and service management. It is integrated as a subproject of Spring Cloud Alibaba to better integrate with Spring Cloud. You can open the official website for detailed information about Nacos. Here, we will directly enter the application section.

Installing Nacos #

We will be using version 1.1.4: nacos-server-1.1.4.tar.gz (the latest version includes permission management). We will deploy the standalone version for testing. After downloading, unzip the file and start it using the corresponding command.

tar -xvf nacos-server-$version.tar.gz cd nacos/bin sh startup.sh -m standalone (standalone means running in standalone mode, not in cluster mode)

The startup log is as follows:

Starting Nacos...
Picked up _JAVA_OPTIONS: -Xverify:none
Picked up _JAVA_OPTIONS: -Xverify:none
Nacos is starting with standalone
Nacos is starting, you can check the /path/to/nacos/logs/start.out

If the log shows “starting,” it means that the startup was successful. Open http://127.0.0.1:8848/nacos and enter the default username “nacos” and password “nacos.” You will see the following interface:

You can see the main functions provided by Nacos on the left menu. In this case, we will only use the service management function. We will talk about configuration management in the next section.

To shut down the service, simply execute the provided script.

For Linux / Unix / Mac platforms, use sh shutdown.sh in the terminal.

For Windows platforms, use cmd shutdown.cmd in the command prompt, or double-click shutdown.cmd.

At this point, the service registry center is ready. Now we will register our service with the registry center.

Applying Nacos in the Service #

1. First, add the Spring Cloud and Spring Cloud Alibaba jar dependencies to the parent project, following the same way as adding Spring Boot dependencies.

Considering the version issue between the three projects, we will use Greenwich.SR4 version this time.

Add the following configuration to the pom.xml file of the parent project parking-project:

<properties>
    <spring-cloud.version>Greenwich.SR4</spring-cloud.version>
    <spring-cloud-alibaba.version>2.1.0.RELEASE</spring-cloud-alibaba.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>${spring-cloud-alibaba.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

2. Add Nacos jar package in the sub-module service. Add the following configuration to the pom.xml file of the sub-module:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    <version>0.2.2.RELEASE</version>
</dependency>
<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
</dependency>

Add @EnableDiscoveryClient annotation to the startup class of the module. This is consistent with using Eureka, and this annotation is based on spring-cloud-commons, which is a common solution.

Add configuration items to the corresponding project configuration file application.properties:

# Must fill in application.name, otherwise the service cannot be registered to Nacos
spring.application.name=card-service/member-service
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848

Start the project and check if the service is registered to Nacos on the Nacos console. Under normal circumstances, two service instances should be found:

Since the current service is running in a single-instance form, the number of clusters of the service in the image is 1, the number of instances is 1, and the number of healthy instances is 1. If we start two instances for the same service, the registry can detect it immediately and display it. The “Sample Code” link in the operation bar provides us with usage methods for different programming languages, which is quite user-friendly. It can be seen here that Nacos will definitely be cross-language in the future, not limited to the Java domain, which aligns with the language-agnostic nature of microservices.

Let’s do a test. Modify the server port in the application.properties configuration file of the Eclipse project, ensuring that the same service ports do not conflict.

server.port=9090

Start 3 instances to form a small cluster for the card-service service. You can configure the weight of each instance on the console. With different weights, the number of responses in processing requests will also be different. With more instances, the response efficiency of the service is greatly improved.

By now, we can register a service to the service registry center for unified configuration management. Other services in the future can refer to this method, complete the basic configuration, and register the services to the Nacos registry center for unified management and maintenance, laying the foundation for subsequent service invocation.

A Thought-provoking Exercise #

In the article, we deployed the Nacos service in single-machine mode, but in a production environment, single-machine mode cannot be used as it would cause a single point of failure. Can you set up a real multi-machine instance cluster?