Traditional deployment architecture based on Zookeeper and Nacos for deploying Dubbo applications in a virtual machine environment
The following diagram illustrates a typical Dubbo microservice deployment architecture using Nacos and Zookeeper as the registration center.
Install Nacos
Please refer to the following documentation for how to install Nacos locally.
Deploy Application
We will continue to use the project in Quick Start as an example to demonstrate the detailed steps for application packaging and deployment.
Clone the sample project locally:
$ git clone -b main --depth 1 https://github.com/apache/dubbo-samples
Switch to the sample directory:
$ cd dubbo-samples/11-quickstart
Here are two packaging and deployment modes:
Method 1: Local Process
Local packaging process:
$ mvn clean package
Start the Dubbo process:
$ java -jar ./quickstart-service/target/quickstart-service-0.0.1-SNAPSHOT.jar
Tip
To ensure the program runs correctly, please make sure the registration center address in theapplication.yml file is correctly pointing to the desired registration center.Method 2: Docker Container
$ docker build -f ./Dockerfile -t quickstart
$ docker run quickstart -p port1:port2
# Some port or connection details to the registration center need to be clarified
Tip
In a Docker container environment, special attention is needed for the addresses used for network communication between different containers. Therefore, you may need to set the address that the Dubbo process listens to or registers with the registration center. Please refer to the following link for more information.
See dubbo sets host through environment variables
Some deployment scenarios require dynamically specifying the service registration address, such as specifying the host machine IP to enable external communication in the Docker bridge network mode. Dubbo provides two pairs of system properties for the startup phase to set the external communication IP and port addresses.
- DUBBO_IP_TO_REGISTRY: IP address registered with the registration center
- DUBBO_PORT_TO_REGISTRY: Port registered with the registration center
- DUBBO_IP_TO_BIND: IP address to listen on
- DUBBO_PORT_TO_BIND: Port to listen on
The above four configuration items are optional. If not configured, dubbo will automatically obtain IP and port. Please flexibly choose configurations based on specific deployment scenarios. Dubbo supports multiple protocols, and if an application exposes multiple different protocol services at the same time and needs to specify IP or port for each service separately, please prefix the above properties with the protocol prefix. For example:
- HESSIAN_DUBBO_PORT_TO_BIND: Port bound for the hessian protocol
- DUBBO_DUBBO_PORT_TO_BIND: Port bound for the dubbo protocol
- HESSIAN_DUBBO_IP_TO_REGISTRY: IP for registering the hessian protocol
- DUBBO_DUBBO_IP_TO_REGISTRY: IP for registering the dubbo protocol
PORT_TO_REGISTRY or IP_TO_REGISTRY will not be used as the default PORT_TO_BIND or IP_TO_BIND, but the reverse is true. For example:
- Setting
PORT_TO_REGISTRY=20881andIP_TO_REGISTRY=30.5.97.6does not affectPORT_TO_BINDandIP_TO_BIND. - Setting
PORT_TO_BIND=20881andIP_TO_BIND=30.5.97.6, then by defaultPORT_TO_REGISTRY=20881andIP_TO_REGISTRY=30.5.97.6.
Check Deployment Status
Install and run dubbo-control-plane to check the local service deployment status:
Download the installation package
$ curl -L https://raw.githubusercontent.com/apache/dubbo-kubernetes/master/release/downloadDubbo.sh | sh - $ cd dubbo-$version/binRun the following command to start the dubbo-control-plane process
$ ./dubbo-cp run
Tip
To ensure dubbo-control-plane runs properly, please modifyconf/dubbo-cp.yml to ensure it points to your desired registration center.Visit http://xxx to view service deployment details.
Graceful Online and Offline
In the case of using a traditional registration center, we need to control the timing of when instances are published to the registration center and when instances are removed from the registration center to achieve a graceful online and offline:
- In the online phase, control the timing of instance registration to the registration center through the delayed release mechanism and ensure that traffic is gradually forwarded to the new nodes through enabling consumer preheating.
- In the offline phase, configure
prestopto ensure that instance registration information is first removed from the registration center, and then enter the process of destruction.
Before going offline, it is recommended to call the following http port to remove the instance from the registration center first, then attempt to stop the process.
$ curl http://offline
$ sleep 10
$ kill dubbo-pid