How to use uwsgi to run web services is not covered here
See nginx configuration directly

# No load balancing
server {                                                                        
    listen 9000;
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Headers Authorization,Origin,X-Requested-With,Content-Type,Accept;
    #add_header Access-Control-Allow-Methods POST,GET,PATCH,PUT,DELETE,OPTIONS,VIEW;
    add_header Access-Control-Allow-Methods POST,GET,PATCH,PUT,DELETE;
    add_header Access-Control-Allow-Credentials true;
    client_max_body_size 100m;
 
    location  / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Protocol $scheme;
    }
   
}  

# Use normal http links
upstream test01 {
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
}  
server {
    listen 9001;          
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Headers Authorization,Origin,X-Requested-With,Content-Type,Accept;
    #add_header Access-Control-Allow-Methods POST,GET,PATCH,PUT,DELETE,OPTIONS,VIEW;
    add_header Access-Control-Allow-Methods POST,GET,PATCH,PUT,DELETE;
    add_header Access-Control-Allow-Credentials true;
    client_max_body_size 100m;
     
    location  / {         
        proxy_pass http://test01;
    }   
}
# If uwsgi is used
upstream mycom{
    ip_hash;
    server 127.0.0.1:8003;  #Load balancing server group
    server 127.0.0.1:8004;
}

server {
    listen 9002;
    # Represents the maximum allowable body size
    client_max_body_size 100m;
     
    location  / {         
        include uwsgi_params;
    	uwsgi_pass mycom; #Connect the load balancing configured above
    }   
}

Dry goods: a common strategy of nginx load balancing
1. Poll (default)
Each request is allocated to different back-end servers in chronological order. If the back-end servers are down, they can be automatically eliminated.

upstream backserver { 
server 192.168.0.14; 
server 192.168.0.15; 
} 

2. Assign weights
Specifies the probability of polling, weight is proportional to the access ratio, and is used in the case of uneven performance of the back-end server.

upstream backserver { 
server 192.168.0.14 weight=10; 
server 192.168.0.15 weight=10; 
} 

3. IP binding IP hash
Each request is allocated according to the hash result of the access ip, so that each visitor accesses a back-end server, which can solve the session problem.

upstream backserver { 
ip_hash; 
server 192.168.0.14:88; 
server 192.168.0.15:80; 
} 

4. fair (third party)
Requests are allocated according to the response time of the back-end server, and those with short response time are allocated preferentially.

upstream backserver { 
server server1; 
server server2; 
fair; 
} 

5. url_hash (third party)
The requests are allocated according to the hash results of the access url, so that each url is directed to the same back-end server, which is more effective when the back-end server is cached.

upstream backserver { 
server squid1:3128; 
server squid2:3128; 
hash $request_uri; 
hash_method crc32; 
}