E-commerce Summary (iv) Picture server architecture based on shared storage

In the current era of the Internet, no matter what kind of web site, the demand for more and more pictures, especially in the e-commerce website, almost will face to the vast amount of image resources storage, access and other related technical issues. In the image server architecture, expansion, upgrade process, will certainly encounter a variety of problems, a variety of needs. Of course, this does not mean that you have to get a special NB Image service architecture, simple, efficient, stable on the line. So let's summarize today a particularly simple and efficient image service architecture: The Image Service architecture is implemented through shared storage.

However, there are some people ask me, now large web site Image server architecture is completely not so, others home picture system, than you this is much more, why not directly write that? The fact is: first, large-scale system I will not, second, and then the system is also a small structure evolved from the past, no one step. Here the picture server architecture is relatively simple, but also through the evolution of the single-machine era, basically can meet the needs of small and medium-sized distributed Web sites. This structure and the learning cost are very low, in line with the current "fast track approach" development model.

Shared storage is implemented through shared directories, and separate domain names are configured on the shared directory file server, separating the picture server from the application server to implement a standalone picture server.

Pros: 1 Detach the image service from the app service to mitigate the I/O load on the application server.

2. You can avoid synchronization-related issues between multiple servers by reading and writing through a shared directory.

3. Relatively flexible, also support expansion/expansion. Supports configuration as a standalone image server and domain name access for future expansion and optimization.

4. Compared to the more complex distributed NFS system, this approach is cost-effective, in line with the current Internet "fast track approach" development model.

　　Disadvantages: 1. Shared directory configuration is a bit cumbersome,

2. Will cause a certain (read and write and security) performance loss.

3. If there is a problem with the picture server, all apps will be affected. The performance requirements for storage servers are particularly high.

4. Image upload operation, or go through the Web server, which is still a great pressure on the Web server.

In fact, the architecture is very simple, as shown in the basic architecture:

1. Create a shared directory on the storage server (specifically, I will not repeat, I Baidu Bar, pay attention to the shared directory file security).

2. Each app directly uploads the image to the storage server via the shared directory (\\192.168.1.200).

3. Establish a Web site (i1.abc.com) to publish the shared directory through a Web site. This allows other applications to access the relevant images.

So, for each application, upload the file to the shared directory

       // Save Original
Full Address: \\192.168.1.200\lib\2016\03\04\10\IMG\4ugvvt6m9gdu.jpg
RelativePath = relativedir + fileName + imageextension;        var absolutepath = Confighelper.sharepath + relativepath;       Filedata.saveas (Absolutepath);                

After successful uploading, you can access it directly via the Web:

Http://i1.abc.com/lib/2016/03/04/10/IMG/4ugvvt6m9gdu.jpg

E-commerce Summary (iv) Picture server architecture based on shared storage