From Single Machines to Distributed Architecture: Tracing the Evolution of IT Systems

Evolution of Architecture

Architecture evolves according to the performance, security, continuity, and technological demands of the time.

I divide the development of architecture into roughly four stages:

1. Single‑Machine Mode

In the early, rapid‑construction phase of IT, organizations simply built whatever systems they needed—ERP, HIS, etc.—without high‑availability requirements.

2. Dual‑Machine Hot‑Standby and Mirroring

About twenty years ago, as systems grew, downtime became unacceptable. Active‑Standby configurations emerged, allowing a standby machine to take over quickly, reducing loss.

However, this introduced resource waste, reliance on storage, and single‑point data issues, leading to higher costs.

3. Multi‑Node Active (Active‑Active)

As business volume and data grew, single‑node solutions could no longer meet performance needs. Horizontal scaling became essential, leading to multi‑node active clusters such as Oracle RAC, Microsoft AlwaysOn, and Moebius.

These solutions distribute load, separate OLTP and OLAP workloads, and improve fault tolerance, though they also increase complexity.

4. Distributed Architecture

When even third‑generation horizontal scaling falls short, further “splitting” of data and services occurs—sharding, vertical/horizontal partitioning, separate databases, etc.—to keep each component lightweight and performant.

This fine‑grained design serves business needs but requires skilled personnel; many traditional enterprises lack the talent to implement it.

Other Technical Discussions

Across these four generations, many technologies appear, primarily for data replication and storage synchronization, such as DG, OGG, Log Shipping, and Replication. They serve different scenarios for read replicas or disaster recovery, each with its own trade‑offs.

Virtualization, hyper‑convergence, and storage active‑active solutions also play roles at the infrastructure layer, complementing database high‑availability strategies.

How to Choose an Architecture

First, decide which generation fits your needs. The four generations emphasize redundancy, splitting, and fine‑grained design.

Second, consider the trade‑offs: dual‑machine redundancy reduces downtime but wastes resources; multi‑node active clusters handle high load but increase complexity; distributed systems require significant expertise and resources.

Summary

The specific generation is less important than selecting an architecture that matches your business requirements, ensuring stability, security, efficiency, and continuity. Simple workloads may stay on single machines; critical services benefit from hot‑standby; high‑pressure applications may need active‑active clusters; and only enterprises with sufficient capability should adopt full distributed solutions.

Source: http://www.cnblogs.com/double-K/p/8970572.html