Background data analysis:

1. Problem generation

• If the data passed from the front end to the background is an object, it will be converted into a json object by default
• json objects can only be received by a single object on the server side
• For example, if the front end passes param and ids data, they will be converted into unified json objects by default. When the background receives them with @ RequestBody or @ RequestParam, only one object can be received as a whole. The objects we need to split are ids and param

2. Solution

• Using QS plug-in, you can parse and convert json objects and query strings
• Use steps:
  – install QS plug-in: npm install qs --save
  – bind QS to JS object: Vue prototype.$ qs = qs
  – use QS plug-in to convert json object: data: this$ qs. stringify(params)
  – receiving object: (param param, @ requestparam ("CIDS") list < long > CIDS)

Form verification:

1. Skill 1

• use!! Indicates the current position input status: C = >!! c
• When c is null, a! Indicates true, two! Indicates the real situation false
• When c has a value, one! Indicates false, two! Indicates the true situation
• When c is null, if not!! As a prefix, the value can only be null instead of boolean

Upload pictures:

1. Precautions

• Uploading a picture means uploading a file, which needs to be received with MultiFile: @ RequestParam ("file") MultiFile file
• Uploading pictures will cause high bandwidth pressure and increase the pressure of microservices. Therefore, it is necessary to create an upload file microservice separately so as not to affect the normal work of other microservices

2. The background service saves and uploads pictures to the local service

• Verify the file type, and judge whether the current file type exists by creating a white list of file types
• Verify the file content and judge whether the file content is a picture through ImageIO
• Save the file to the local server using the transferTo method
• Return the url and echo it. Users can access the picture through the corresponding address

@Service
public class UploadService {
    private static final List<String> CONTENT_TYPE = Arrays.asList("image/gif","application/x-jpg");    // Picture type whitelist
    private static final Logger LOGGER = LoggerFactory.getLogger(UploadService.class);
    /**
     * Upload pictures
     * @param file
     * @return
     */
    public String uploadImage(MultipartFile file) {
        String filename = file.getOriginalFilename();
        // Check file type
        String contentType = file.getContentType();
        if (!CONTENT_TYPE.contains(contentType)){
            LOGGER.info("Illegal file type:{}", filename);
            return null;
        }

        try {
            // Verify file content
            BufferedImage bufferedImage = ImageIO.read(file.getInputStream());
            if (bufferedImage == null){
                LOGGER.info("Illegal file content:{}", filename);
                return null;
            }
            // Save to file server
            file.transferTo(new File("F:\\study\\project\\leyou\\uploadImage\\" + filename));
        } catch (IOException e) {
            LOGGER.info("Server internal error:{}", filename);
            e.printStackTrace();
        }
        // Return url for echo
        return "http://image.leyou.com" + filename;
    }
}

3. Configure echo through Nginx

• Configure nginx Conf file
• Configure directly through the local root + path without using an agent
• Finally, modify the local host mapping: 127.0.0.1 image leyou. com

server {
        listen       80;
        server_name  image.leyou.com;

        proxy_set_header X-Forwarded-Host $host;
		proxy_set_header X-Forwarded-Server $host;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		
		location / {
			root F:\\study\\project\\leyou\\uploadImage;
		}
    }

4. Configure Nginx to bypass zuul gateway for image upload

• Configure exact address mapping
• Rewrite path, filter / api
• matters needing attention:
  – the exact path mapping should be placed on it to prevent all filtering without passing the exact path mapping
  – when rewriting the path, the regular matching original path () represents the grouping
  – the rewritten path uses $1 to represent the first set of matching values in regular matching, which means / upload/image
  – there are two final instructions: last (after rewriting the path, you need to enter Nginx for mapping) and break (after rewriting the path, you can directly exit Nginx and redirect)

	server {
        listen       80;
        server_name  api.leyou.com;

        proxy_set_header X-Forwarded-Host $host;
		proxy_set_header X-Forwarded-Server $host;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		
		location /api/upload {
			proxy_pass http://127.0.0.1:8082;
			proxy_connect_timeout 600;
			proxy_read_timeout 600;
			
			rewrite	"^/api/(.*)$" /$1 break;
		}
		location / {
			proxy_pass http://127.0.0.1:10010;
			proxy_connect_timeout 600;
			proxy_read_timeout 600;
		}
    }

5,FastDFS

• Distributed File System
  – files managed by the traditional file system are stored locally
  – files managed by the distributed file system are stored in many machines, which are uniformly managed through network connection. Whether uploading or downloading, they are accessed through the management center
• FastDFS
  – lightweight, high-performance distributed file management system
  – it has the functions of file storage, file synchronization, file access (upload, download), access load balancing and online capacity expansion
  – applications or systems suitable for mass storage requirements
• FastDFS architecture
  – there are two main roles: Tracker Server and Storage Server
  – Tracker Server: the tracking server is responsible for scheduling the communication between the storage node and the client, playing the role of load balancing in access, recording the operation status of the storage node, and is the hub connecting the client and the storage node
  – storage server: a storage server that stores files and their meta data. Each storage server will start a separate thread to actively report its status information to each tracker server in the track cluster, including disk usage, file synchronization, statistics of file upload and download times, etc
  – Group: filegroup, a cluster of multiple storage servers. Upload a file to a machine in the Group. FastDFS will synchronize the file to all other machines in the same Group for backup. Different groups of servers save different data and are independent of each other without communication
  – Tracker Cluster: tracking server cluster, which is composed of a group of tracker servers
  – Storage Cluster: a Storage Cluster consisting of multiple groups
• Upload and download process
  – the client sends a request to the tracker - >
  – the IP and port number of the available storage in the tracker response
  – the client uploads or downloads files from the corresponding storage according to the tracker response information