Evolution of Image Server Architecture: From NFS to Distributed Storage and Cloud OSS

Modern web and mobile applications rely heavily on image services, requiring careful planning of image servers to ensure upload/download speed, scalability, and stability.

Because image servers consume significant I/O resources, separating them from application servers into dedicated clusters improves performance, enables targeted caching, and enhances scalability.

The architecture has evolved through three stages: an initial NFS‑based approach, a development stage with distributed storage and load balancing, and a cloud storage stage leveraging services such as Alibaba OSS.

Initial Stage : NFS (Network File System) allows multiple servers to share files, but suffers from performance bottlenecks, single‑point failures, limited scalability, uneven storage usage, and security concerns. Alternatives like FTP or rsync can provide redundancy but introduce latency.

Development Stage : To handle larger traffic, a distributed image storage system is introduced. Images are posted from web servers to a pool of image servers, which store files locally, generate thumbnails, apply watermarks, and record metadata in a database. Load balancing (hardware F5 or software LVS) distributes requests, while caching layers (Squid, Varnish, Traffic Server) improve read performance. The article compares cache solutions, noting Varnish’s memory efficiency, Traffic Server’s reliability, and Squid’s stability.

File system choices (XFS, ext3/4, ReiserFS) and inode sizing are discussed to optimize storage for large numbers of small image files.

Cloud Storage Stage : Alibaba Cloud OSS provides a scalable, secure, low‑cost object storage service with REST APIs and SDKs for Java, Python, and PHP. Advantages include abstracted hardware, no path management, no maintenance, and built‑in backup and disaster recovery.

Architecture Modules :

1) KV Engine – stores object metadata and data. 2) Quota – tracks bucket and user resource usage. 3) Security – manages Access Key ID/Secret for authentication.

OSS Terminology includes Access Key, Service, Bucket, and Object. Example Java code to upload an image:

OSSClient ossClient = new OSSClient(accessKeyId,accessKeySecret);
PutObjectResult result = ossClient.putObject(bucketname, bucketKey, inStream, new ObjectMetadata());

Object URLs follow the pattern http://bucketname.oss.aliyuncs.com/bucketKey .

Distributed File System : Alibaba’s Pangu system, similar to Google GFS, uses a master‑slave architecture with Paxos‑based multi‑master for high availability, chunk servers for data, and triple replication across racks.

HAProxy Load Balancing : An HAProxy‑based hash architecture routes requests through Nginx to cache nodes, improving high‑availability and performance for static assets like favicons and logos.

CDN : Alibaba Cloud CDN caches content across nationwide nodes, reducing latency and handling traffic spikes without manual bandwidth scaling.

Separating upload and download paths ensures upload reliability, with quota servers handling metadata and CDN or OSS serving downloads. Anti‑hotlinking can be enforced via Nginx/Squid referer checks or signed URLs; Python code for generating a signed URL is:

h=hmac.new("OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV", "GET\n\n\n1141889120\n/oss-example/oss-api.jpg",sha);
urllib.quote_plus (base64.encodestring(h.digest()).strip());

Image Processing API : GraphicsMagick (a fork of ImageMagick) offers extensive image manipulation functions via SDKs for multiple languages, supporting over 88 formats. Alibaba OSS also provides built‑in image processing APIs for thumbnails, watermarks, and pipelines.