Designing Scalable System Architecture: From Access Chains to Cloud‑Native Infrastructure

1. Access Chain

The access chain describes the end‑to‑end flow from a user request to the final response returned by production servers. Understanding this chain is essential for performance tuning, fault isolation, and monitoring. Two main paths are presented: an external public‑network chain (Public DNS → GSLB → CDN → Firewall/IPS → WAF → Soft Load Balancer → Production Servers) and an internal private‑network chain (Internal DNS → Soft Load Balancer → Production Servers). Diagrams illustrate a typical midsize company where the external chain serves an e‑commerce platform and the internal chain serves core business systems. Potential bottlenecks such as hardware firewalls/WAF under heavy traffic and insufficient internal DNS protection are identified, with mitigation suggestions including soft firewalls, WAF policy tuning, endpoint antivirus, and adding security rules at the load‑balancer layer. An open‑source Nginx+Lua WAF (https://github.com/loveshell/ngx_lua_waf) is recommended for internal protection.

2. Infrastructure

2.1 Network

Key aspects include multi‑ISP access, DNS‑based routing, network segmentation (DMZ, office, test, production), topology design, traffic management, and security monitoring. A clear network topology diagram is essential for rapid fault diagnosis.

2.2 Basic Hardware

Servers, memory, CPUs, storage, power, firewalls, switches, and routers should be provisioned with redundancy (dual or multiple units) and tracked in a CMDB to avoid single‑point failures.

2.3 Basic Software

Operating‑system ISOs, database installers, application‑server packages, and common office tools should be centrally stored on a static‑resource server (e.g., an Nginx host) with a dedicated sub‑domain such as soft.example.com to simplify distribution and version control.

2.4 Data Center

Both cloud services and self‑built data centers are discussed. While public cloud offers rapid deployment, large‑scale usage can increase costs, making a hybrid or fully on‑premise data center economically attractive for growing enterprises. Construction must follow national and industry standards (e.g., GB50174‑2017, GB50462‑2015, TIA‑942). A link to a Baidu‑pan archive is provided for detailed documentation.

2.5 Infrastructure Management & Optimization

Asset lifecycle management via CMDB, automated provisioning, and unified scripts are recommended. Virtualization (VMware, FC‑SAN) improves resource utilization but introduces challenges such as high upfront cost, backup complexity, and VM migration latency. Containerization (Kubernetes) is positioned as the future primary deployment model, with virtualization retained for Windows services and Oracle databases that lack mature container support.

3. Layered Architecture

The system is divided into four layers: Access (DNS, CDN, Load Balancer, Static Resources), Application, Common Services (caching, messaging, session, file storage, scheduling), and Data Storage. Load balancing can be hardware (F5, A10) or software (LVS, Nginx, HAProxy). High‑availability is achieved via virtual IPs and keepalived, while load‑balancing strategies include round‑robin, weighted round‑robin, and IP‑hash. Session handling options are shared application‑server storage, cookie‑based storage, or dedicated session servers (e.g., Redis).

4. Segmented Architecture (Business Splitting)

Business functions are modularized into independent services following high cohesion and low coupling principles. Service frameworks such as Dubbo, Spring Cloud, and Spring Boot are mentioned. The split must be holistic, covering both code and database layers, to avoid hidden cross‑database load. Planning considerations include cost, risk, timeline, and ensuring the split granularity balances maintainability with performance.

5. System Assurance

Operational reliability relies on a robust CMDB, comprehensive monitoring, disaster‑recovery planning, and security hardening. Current challenges include alert fatigue and storm due to imprecise thresholds; future work will explore machine‑learning‑driven dynamic thresholding. References to several Chinese‑language articles on automation, monitoring, and disaster recovery are listed for deeper study.

6. Q&A and Open‑Source CMDB Recommendations

Community members asked for open‑source CMDB tools; several GitHub projects are listed (e.g., https://github.com/hequan2017/autoops, https://github.com/pengzihe/cmdb). The answer notes that while ITOP is a ready‑made solution, most organizations need to customize CMDB to fit their environment.