Scalable .NET Application Architecture: From Single Server to Distributed Cluster

Initially, the author notes that .NET lacks many open‑source components for parallel databases and foundational services, so technologies such as Hadoop, Spark, ZooKeeper, and Dubbo are not considered.

1. Single‑Server Model – The first assumption places the web application, files, and database on one server, a "one‑size‑fits‑all" approach.

2. Multi‑Server Deployment – As business grows, a single server cannot meet performance needs; the application, database, and files are deployed on separate servers with hardware tuned to each role for optimal performance.

3. Clustered Architecture – When a single database, website, or file server can no longer handle massive data and high concurrency, clustering becomes necessary. Application servers are placed behind load balancers (hardware like F5 or software such as LVS, Nginx, HAProxy). Database bottlenecks are addressed via read/write separation, horizontal/vertical sharding, and historical table partitioning.

File systems are organized hierarchically (e.g., \AppName\Module\Date) and, when a single file server is insufficient, a distributed file system such as NFS or Microsoft DFS is used.

Stateless design is required for clustered application servers; session, cache, and view state data are moved to dedicated caching services (initially AppFabric, later Redis).

For government or branch‑office scenarios where internet deployment is prohibited, a distributed deployment is used: either each branch runs a full system with periodic data sync, or branches run middleware while data remains centralized.

4. Business‑Level Service Separation – As the application becomes bulky, it is split into independent business modules (portal, incident handling, business info, metrics, data analysis, etc.) that communicate via message queues. Databases are also partitioned by domain, and static resources (CSS, JS, images) are served from a dedicated static‑resource server.

5. NoSQL and Search Engines for Massive Data – To improve query performance on huge datasets, NoSQL databases (MongoDB, Redis) and search engines built on Lucene (Solr, Elasticsearch) are introduced, often deployed as clusters.

6. Service Layer and SOA – To serve various front‑ends (web, Android, iOS), an application service layer exposing SOA interfaces (DTO, WebService, WCF, RESTful WebAPI) is built. Transaction consistency across MQ and SOA is ensured via compensation mechanisms, and load‑balancing decisions consider server pressure, resources, and connection counts.

7. CDN and Multi‑Center Deployment – Further scaling introduces CDNs and multiple data centers, with users routed to the nearest center and data kept synchronized across centers.

8. Data Warehouse and Analytics – As data grows, a data warehouse is constructed using ETL/ELT processes. Small systems may combine relational and multidimensional databases; large systems use column‑store or parallel databases. Analytics are delivered via reports, KPIs, dashboards, or advanced techniques like data mining and machine learning.

9. Cloud Services – For organizations lacking resources to build the above themselves, cloud providers (Azure, Alibaba Cloud, AWS) offer virtual servers (ECS), load balancers (SLB), managed databases (RDS), object storage (OSS), distributed databases (DRDS), big‑data compute (MaxCompute), messaging (RocketMQ), caching (OCS), CDN, etc.

Docker is also highlighted as a convenient tool for packaging services such as Redis, Memcached, RabbitMQ, and Solr.

Source: http://www.cnblogs.com/tuyile006/p/8980428.html

Copyright statement: Content originates from the web and belongs to the original author. Attribution is provided; please notify us of any infringement.

Architecture Digest

ID: ArchDigest

Internet Application Architecture | Architecture Technology | Large‑Scale Websites | Big Data | Machine Learning