The nginx implementation has the real world experience of forwarding requests based on URL

preface

Because this long to complete a distributed file system outside the network deployment, use fastdfs, deploy the application to port 8088, its background management system deployed in 8089 port () with a network server, the service of the background management system to request fastdfs service, you can directly request (with one server resources), but we now only in the background management system (Springboot project), not through the public network distribution IP can only access to the background management system, to directly access fastdfs service interface must connect server public, But this limits our users' access (I can't go to your server every time, but I think it can be accessed from other places)

[

Proxy server: SockerServer listens on a port, connects to the specified server port according to the http message, and makes a data request
- HTTP agent
The http request passes through the proxy server, which is only responsible for forwarding the corresponding http response body.
- HTTPS agent
After the request of https passes through the proxy server, an CONNECT message will be sent to establish the tunnel with the proxy server. If the proxy server returns HTTP 200, the establishment will be successful, and the subsequent proxy server will only be responsible for forwarding the data. In fact, the SSL/TLS handshake still takes place in the client and the real server.

]

ProxyServlet

Since port 8089 of this background project can access the server fastdfs service, the first thing that came to my mind was to proxy the specified request to port 8088 of the server using ProxyServlet of Springboot

[

Spring boot Lord Servlet SpringMVC DispatcherServlet, its default url - pattern as "/", if we want to add different calls to a url (other server interface), then you need to create a new agency servlet, will use to ServletRegistrationBean, create a new ProxyServlet to handle different port of monitoring and data to send, and register it to management springboot servletContext (set the specified server and port, the forward requests interface)

]

Rely on

<dependency>
 <groupId>org.mitre.dsmiley.httpproxy</groupId>
 <artifactId>smiley-http-proxy-servlet</artifactId>
 <version>1.7</version>
 </dependency>

configuration

###  Configure the agent 
# request resource When the agent forwards to the port 8088 In the project 
proxy.test.servlet_url_one= /resource/*
proxy.test.target_url_one= https://localhost:8088

@Component
@Data
public class ProxyFilterServlet {
 @Value("${proxy.test.target_url_one}")
 private String targetUrl;
 @Value("${proxy.test.servlet_url_one}")
 private String servletUrl;
}

Change config to add

@Configuration
public class ProxyServletConfig {
 @Autowired
 private ProxyFilterServlet proxyFilterServlet;
 // Multiple agents servlet You can configure multiple bean
 @Bean
 public ServletRegistrationBean servletRegistrationBean(){
 ServletRegistrationBean servletRegistrationBean = new ServletRegistrationBean(new ProxyServlet(), proxyFilterServlet.getServletUrl());
 // this setName Must be set, and when multiple, the name needs to be no 1 sample 
 servletRegistrationBean.setName("go_backend");
 servletRegistrationBean.addInitParameter("targetUri", proxyFilterServlet.getTargetUrl());
 servletRegistrationBean.addInitParameter(ProxyServlet.P_LOG, "false");
 return servletRegistrationBean;
 }
}

[

Connect to the target server via the servlet container, which is not as strong as a professional proxy server like nginx

]

nginx - proxy forwarding

At this point I thought of adding a layer of nginx between servers to forward different service requests to different ports of api for processing

Reroute requests from the requested extranet to the same server Intranet port

server {
 listen 80;
 server_name 127.0.0.1;
 
 location / {
 proxy_pass http://127.0.0.1:3000;
 }
 
 location ~ /api/ {
 proxy_pass http://172.30.1.123:8081;
 }
}

Reference blog:

https://www.ofstack.com/article/174382.htm

https://www.ofstack.com/article/174383.htm

conclusion