Here we expose the services of the Pod in Kubernetes to the outside world by means of NodePort, and configure the ip mapping of the Kubernetes cluster node before starting the test.
```sh
# Please adjust with the public ip of your K8S node
120.24.xxx.xxx integrated-frontend
120.24.xxx.xxx gateway-service
120.24.xxx.xxx integrated-mysql-web
120.24.xxx.xxx nacos-mysql-web
120.24.xxx.xxx nacos-svc
```
## Start the test
Go to the ``spring-cloud-alibaba-examples/integrated-example`` directory and execute the following command to deploy the application using Helm.
With the above command we have completed the deployment of the best practice project via Helm with one click based on the Helm Chart documentation provided by the project.
You can check the deployment status of each container resource through the `kubectl` command provided by Kubernetes, and wait patiently for **all containers to finish starting** to experience the usage scenarios and capabilities of each component on the corresponding page.
If you want to stop the experience, enter the following command.
```shell
helm uninstall integrated-example
```
### Distributed Transaction Capabilities
#### Scenario Description
For the distributed transaction capability, we provide a scenario **where a user places an order to purchase goods** and after placing the order.
- First request the inventory module and deduct the inventory
- Deduct the account balance
- Generate order information to return a response
##### Start test
Visit `http://integrated-frontend:30080/order` to experience the corresponding scenario.
By clicking directly on the order button to submit the form, we simulate the client sending a request to the gateway to create an order.
- The user's userId is admin
- The user places an order with item number 1
- The number of items purchased in this order is 1
In this demo example, the unit price of each item is 2 for demonstration purposes.
While initializing the `integrated-mysql` container, **initializing the business database table** creates a new user userId = admin with a balance of $3; and a new item numbered 1 with 100 units in stock.
So by doing the above, we will create an order, deduct the number of items in stock corresponding to item number 1 (100-1=99), and deduct the balance of the admin user (3-2=1).
If the same interface is requested again, again the inventory is deducted first (99-1=98), but an exception is thrown because the admin user's balance is insufficient and is caught by Seata, which performs a two-stage commit of the distributed transaction and rolls back the transaction.
You can see that the database still has 99 records in stock because of the rollback.
### Fused flow limiting, peak shaving capability
#### Scenario Description
For service fusion limiting and peak and valley cutting in the context of high traffic, we provide a scenario** where users make likes for products**. In this scenario, we provide two ways to deal with high traffic.
- Sentinel binds specified gateway routes on the gateway side for fusion degradation of services.
- RocketMQ performs traffic clipping, where the producer sends messages to RocketMQ under high traffic requests, while the consumer pulls and consumes through a configurable consumption rate, reducing the pressure of high traffic direct requests to the database to increase the number of likes requests.
#### Startup test
- Sentinel Service Meltdown Degradation
Visit `http://integrated-frontend:30080/sentinel` to experience the corresponding scenario.
The Gateway routing point service has a flow limit rule of 5, while 10 concurrent requests are simulated on the front end through asynchronous processing.
Therefore, we can see that Sentinel performs a service fusion on the Gateway side to return the fallback to the client for the extra traffic, while the number of likes in the database is updated (+5).
Since we have previously configured the consumption rate and interval of the `integrated-consumer` consumer module in Nacos, we simulate 1000 like requests at the click of a button, and for 1000 like requests, `integrated_provider`
will deliver 1000 requests to the Broker, and the consumer module will consume them according to the configured consumption rate, and update the database with the product data of the likes, simulating the characteristics of RocketMQ to cut the peaks and fill the valleys under high traffic.
You can see that the number of likes in the database is being dynamically updated.
This example **is just a selection of typical features for each component to serve the application scenario**.
Of course, there is more to each component than just what is demonstrated in the best practices, so if you are interested or want to go deeper, feel free to study the individual example documentation for each component.
## Spring Cloud Alibaba Containerized Deployment Best Practices | Local Deployment Version
# Spring Cloud Alibaba Containerized Deployment Best Practices | Local Deployment Edition
## Preparation
### Environment declaration
### Environment Declaration
Before running the local example, you need to ensure that the following base environment is available locally. If you do not have a current environment locally, the following step-by-step build will demonstrate the build process.
Before running the local example, you need to ensure that the following base environment is available locally. If you do not have a current environment locally, the following step-by-step build will be done to demonstrate the build process.
- Nacos server
- Seata server
@ -13,51 +13,65 @@ Before running the local example, you need to ensure that the following base env
### Component Service Versions
To download and unpack the component versions of this project, please go to the release pages of the respective communities.
For each component version of this project, please go to the release page of each community to download and unpack.
- [Nacos: version 2.1.0](https://github.com/alibaba/nacos/releases)
- [Seata: version 1.5.1](https://github.com/seata/seata/releases)
- [RocketMQ: version 4.9.4](https://github.com/apache/rocketmq/releases)
- MySQL: version 5.7
### host configuration
To ensure that the code can start properly, please configure the local host mapping first, add the following mapping to the configuration file.
```sh
# for integrated-example
127.0.0.1 integrated-mysql
127.0.0.1 nacos-server
127.0.0.1 seata-server
127.0.0.1 rocketmq
127.0.0.1 gateway-service
127.0.0.1 integrated-frontend
```
### Database configuration
The following starts the local environment build preparation, before the database configuration starts, please make sure that the MySQL server is turned on.
Before you start the database configuration, please make sure the MySQL server is on.
#### Initializing Business Tables
#### Initialize business tables
For the first scenario, the orders, accounts and inventory microservices all need their own databases, while the second scenario simulating likes also needs a database to store the likes information.
For the first scenario, the order, account, and inventory microservices all need their own databases, while the second scenario simulates a database for storing like information as well.
Run the sql script `spring-cloud-alibaba-examples/integrated-example/sql/init.sql` to create the environment required for the business and the Seata-related tables in one click.
### Nacos configuration
### Nacos Configuration
Now that the database services are configured, you need to configure the Nacos configuration centre with all the microservice configuration files.
At this point, the database services are configured and you need to configure the Nacos configuration center for all the microservice configuration files.
#### Nacos startup
For the purpose of this example, Nacos is started in ``standalone'' mode. Go to the Nacos unpacked directory and execute the following command.
For the sake of example, here we use the ``standalone`` mode of Nacos, go to the unpacked directory of Nacos and execute the following command.
```sh
#Linux/Mac environment
sh bin/startup.sh -m standalone
#If you are in Ubuntu and the above command gives you an error saying [[symbol not found, you can run the following command
#If you are in Ubuntu and the above command gives you an error [[symbol not found, you can run the following command
bash bin/startup.sh -m standalone
#Win environment
. \bin\startup.cmd -m standalone
```
````
#### Adding configuration files
Before bulk importing the configuration, change the datasource configuration (username and password) in `integrated-example/config/datasource-config.yaml`.
Before bulk importing the configuration, please modify the datasource configuration (username and password) in `integrated-example/config/datasource-config.yaml`.
Afterwards, run `spring-cloud-alibaba-examples/integrated-example/scripts/nacos-config-quick.sh` to complete the one-click import of all microservice configurations.
After that, run `spring-cloud-alibaba-examples/integrated-example/scripts/nacos-config-quick.sh` to complete the one-click import of all microservice configurations.
### Seata configuration
### Seata Configuration
Once the Nacos service registry and configuration centre have been deployed, here is the configuration of the Seata server.
After the Nacos service registry and configuration center are deployed, here is the configuration of the Seata server.
Seata's db mode requires additional configuration of the database information and modification of the Seata Server configuration file, which has been merged in the new version compared to the old one.
Seata's db mode requires additional configuration of database information and modification of the Seata Server configuration file, and the configuration file has been merged in the new version compared to the old version, so for demonstration purposes, Seata Server is started in `file` mode on Seata standalone.
#### Start Seata Server
@ -72,7 +86,7 @@ bin\seata-server.bat
### RocketMQ configuration
Once the Seata service is started, you can start the RocketMQ NameServer and Broker services.
After the Seata service starts, you can start the RocketMQ NameServer and Broker services.
Go to the unpacked rocketmq directory after the release and execute the following command.
@ -94,98 +108,98 @@ sh bin/mqbroker
. \bin\mqbroker.cmd
```
## Run the demo
## Run the demo example
After the preparation work is done, you can run the demo to experience the user order (distributed transaction capability) and simulate the high traffic volume (meltdown limit and peak shaving capability) depending on different usage scenarios.
After the preparation work is done, you can run the demo, mainly according to different usage scenarios, you can experience the user order (distributed transaction capability) and simulate the high traffic point (meltdown and limit the flow as well as the ability to cut the peak and fill the valley) respectively.
The first step is to start the `integrated_frontend` and `integrated_gateway` projects respectively.
First, you need to start the `integrated_frontend` and `integrated_gateway` projects separately.
- The gateway module is the gateway to the entire best practice instance.
- frontend is the simple front-end page for the best practice.
### Distributed transaction capability
### Distributed Transaction Capabilities
#### scenario description
#### Scenario Description
For the distributed transaction capability, we provide a scenario **where a user places an order for goods** and after placing the order.
For the distributed transaction capability, we provide the scenario **where a user places an order for goods** and after placing the order.
- First request the inventory module and deduct the inventory
- Deducts the account balance
- Deduct the account balance
- Generate order information to return a response
##### start test
##### Start test
Start the `integrated_storage`, `integrated_account`, `integrated_order` microservices separately.
In this demo, for demonstration purposes, the unit price of each item is 2.
In this demo example, the unit price of each item is 2 for demonstration purposes.
In the previous preparation, when **initialising the business database table** we created a new user userId = admin with a balance of $3 and a new item numbered 1 with 100 items in stock.
And in the previous preparation, **initialize business database table** we created a new user userId = admin with a balance of $3, and a new item numbered 1 with 100 units in stock.
So by doing the above, we create an order, deducting the number of units in stock for item number 1 (100-1=99) and deducting the balance of the admin user (3-2=1).
So by doing the above, we will create an order, deduct the number of items in stock corresponding to item number 1 (100-1=99), and deduct the balance of the admin user (3-2=1).
If the same interface is requested again, again the stock is deducted first (99-1=98), but an exception is thrown because the admin user's balance is insufficient and is caught by Seata, which performs a two-stage commit of the distributed transaction and rolls back the transaction.
If the same interface is requested again, again the inventory is deducted first (99-1=98), but an exception is thrown because the admin user's balance is insufficient and is caught by Seata, which performs a two-stage commit of the distributed transaction and rolls back the transaction.
You can see that the database still has 99 records in stock because of the rollback.
### Melt limit, peak shaving capability
### Fused flow limiting, peak shaving capability
#### Scenario description
#### Scenario Description
For service fusion limiting in the context of high traffic and peak and valley reduction, we provide a scenario where **users like an item**. In this scenario, we provide two ways to deal with high traffic.
For service fusion limiting and peak and valley cutting in the context of high traffic, we provide a scenario **where users make likes for products**. In this scenario, we provide two ways to deal with high traffic.
- Sentinel binds a specified gateway route on the gateway side for fusion degradation of the service.
- RocketMQ performs traffic clipping, where the producer sends messages to RocketMQ during high traffic requests, while the consumer pulls and consumes at a configurable consumption rate, reducing the pressure of high traffic direct requests to the database to increase the number of likes requested.
- Sentinel binds specified gateway routes on the gateway side for fusion degradation of services.
- RocketMQ performs traffic clipping, where the producer sends messages to RocketMQ under high traffic requests, while the consumer pulls and consumes through a configurable consumption rate, reducing the pressure of high traffic direct requests to the database to increase the number of likes requests.
#### startup tests
#### Startup test
Start the `integrated_provider` and `integrated_consumer` modules separately.
- Sentinel service meltdown downgrade
- Sentinel service meltdown degradation
Visit `http://127.0.0.1:8080/sentinel` to experience the corresponding scenario.
Visit `http://integrated-frontend:8080/sentinel` to experience the corresponding scenario.
The Gateway routing point service has a flow limit rule of 5, while 10 concurrent requests are simulated on the front-end through asynchronous processing.
The Gateway routing point service has a flow limit rule of 5, while 10 concurrent requests are simulated on the frontend through asynchronous processing.
So you can see that Sentinel is fusing the service on the Gateway side to return a fallback to the client for the extra traffic, while the number of likes in the database is updated (+5).
Therefore, we can see that Sentinel performs a service fusion on the Gateway side to return the fallback to the client for the extra traffic, while the number of likes in the database is updated (+5).
- RocketMQ is performing peak and valley reduction
Visit `http://127.0.0.1:8080/rocketmq` to experience the corresponding scenario.
Visit `http://integrated-frontend:8080/rocketmq` to experience the corresponding scenario.
As we have previously configured the consumption rate and interval of the `integrated-consumer` consumer module in Nacos, we simulate 1000 requests for likes at the click of a button, and for 1000 requests for likes, the `integrated_provider`
In the consumer module, we consume at the configured consumption rate and update the database with the product data, simulating the RocketMQ peak-shaving feature in heavy traffic.
Since we previously configured the consumption rate and interval of the `integrated-consumer` consumer module in Nacos, we simulate 1000 requests for likes at the click of a button, and the `integrated_provider`
will deliver 1000 requests to the Broker, and the consumer module will consume them according to the configured consumption rate, and update the database with the product data of the likes, simulating the characteristics of RocketMQ to cut the peaks and fill the valleys under high traffic.
You can see that the number of likes in the database is being dynamically updated.
This example **is just a selection of the typical features of each component to serve the application scenario**.
This example **is just a selection of typical features for each component to serve the application scenario**.
Of course, there is more to each component than what is demonstrated in the best practices, so if you are interested or want to go deeper, you are welcome to study the individual example documentation for each component.
If you are interested or want to go deeper, you are welcome to study the individual example documentation for each component.
Steve Rao
2 years ago
committed by
GitHub