From Single‑Server to Distributed CDN: Evolving Image Server Architecture

Single-Server Image Server Architecture (Centralized)

In the early stage, a simple upload directory is created under the website root, files are stored with relative paths, and accessed via URLs like http://www.yourdomain.com/upload/qa/test.jpg. Upload is done by mapping a physical directory in web.config or using Server.MapPath, which is easy to implement but leads to poor scalability.

Problems include disk capacity limits, difficulty expanding storage, and challenges synchronizing files across multiple web servers during deployments or backups.

Cluster Era Image Server Architecture (Real‑time Sync)

Introducing a virtual upload directory allows multiple web servers to share the same path, but files must be synchronized in real time across nodes, which is inefficient and hard to guarantee consistency.

Typical solution uses rsync‑like tools for periodic synchronization, employing push or pull models, but high concurrency stresses bandwidth and system resources.

Improved Cluster Architecture (Shared Storage)

By pointing the virtual directory to a UNC network share, multiple servers read/write the same storage, eliminating real‑time sync issues. This approach offers flexibility and easier scaling, though it may introduce performance overhead and a single point of failure.

Benefits of a Dedicated Image Server / Domain

Reduces load on web/app servers, allowing them to focus on dynamic processing.

Facilitates expansion, disaster recovery, and data migration.

Avoids browser concurrency limits and cookie overhead.

Enables independent caching, load balancing, and CDN integration.

Current Architecture (Distributed File System + CDN)

Adopt FastDFS as the distributed file system, providing redundancy, automatic sync, linear scaling, and APIs for upload/download/delete. Legacy image paths are preserved by routing old URLs through ACL rules to the old image server.

FastDFS nodes are fronted by a lightweight web server (e.g., Nginx) and a CDN that CNAMEs the image domain, delivering cached content from the nearest edge node.

The overall design supports horizontal scaling, high concurrency, and can be deployed on cloud storage with CDN acceleration.

Key considerations when extending an image server include capacity planning, data synchronization and disaster recovery, hardware cost and reliability, file‑system choice, accelerated access via CDN or cache, and compatibility with existing image URLs.