An overview of the

How to better complete the development of a complex system is a topic that every senior programmer must think about.

For simple monomer applications, the concurrency is small and only needs to meet functional requirements. However, the larger the application, the more factors it needs to consider, generally speaking, the architecture should consider three key points:

High Availability

The high availability metric is usually a number of nines, which is a measure of the stable operation of the system. Five nines, or 99.999%, mean that an accident lasts no more than five minutes a year, and four nines, or 99.99, mean that an accident lasts no more than an hour a year. Generally speaking, the key modules of the system guarantee at least four nines.

Specific high availability can be divided into storage high availability, computing high availability, and service high availability.

High Performance

As the number of concurrent requests increases, more resources are consumed. CPU and storage represent the high performance of storage and CPU respectively.

Performance optimization is a big topic, and there are many ways to do it. I will write a separate article later when I have time.

Scalability

Unbundling is one of the most important ideas for improving system extensibility. It involves breaking a complex system into separate, single-responsibility modules. It is certainly easier to consider the extensibility of a small module as opposed to a large system. To simplify complex problems, that’s the idea.

other

In addition to the three key points mentioned above, architectural design should also consider cost (maintainability, labor costs, operating costs, etc.), security, etc., which will not be covered here.

Solid design principles

We know that Java has 23 design patterns that are difficult to remember all of them, but the ideas they reveal can be grouped into solid design principles.

Solid design principles are several important principles that Robert Martin advocates to follow in the process of object-oriented design and OOD&OOP.

  1. The Single Responsibility Principle: There should be only one reason to modify a class; if there is more than one, The class has more than one Responsibility and should be split as appropriate.
  2. The Open Closed Principle: Software entities should be Open to extension and Closed to modification. Do not modify library source code directly (even if you have the source code), extend it by inheritance, etc.
  3. The Liskov Substitution Principle: When instances of a subclass can be replaced with instances of any superclass, The relationship between them is truly IS-A.
  4. The Interface Segregation Principle: Do not force users to rely on interfaces they do not use. In other words, it is better to have multiple specialized interfaces than to have a single large, all-in-one interface.
  5. The Dependency Inversion Principle: high-level modules should not depend on low-level modules; both should depend on abstractions. In other words, rely on abstractions, not concrete implementations.

For a detailed introduction, please refer to my article design Principles and Life.

Principle of CAP

When it comes to distribution, CAP theory has to be mentioned.

According to CAP, a distributed system satisfies at most two of Consistency, Availability and Parition Tolerance at the same time.

  • Consistency: All nodes see the same data at the same time. That is, the update succeeds and all nodes have the same data at the same time.
  • Availability: Reads and writes always succeed, that is, the service is always available and the response time is normal.
  • Zoning tolerance: The system continues to operate despite arbitrary message loss or failure of part of the system. It is still able to provide services externally that satisfy consistency and availability.

In general, partition tolerance P must be met, and we have to choose between consistency C and availability A.

However, it is very difficult to achieve strong consistency, which is where the BASE theory comes in.

The BASE theory of

BASE theory is an extension of CAP theory. The core idea is that even if Strong Consistency cannot be achieved, an appropriate method can be adopted to achieve Eventual Consistency.

BASE refers to Basically Available, Soft State, and Eventual Consistency.

  • Basically Available: A distributed system allows the loss of part of its availability in the event of a failure, i.e. the core is guaranteed to be Available. Like service downgrades.
  • Soft State: Allows the system to have intermediate states that do not affect the overall availability of the system. Distributed storage generally stores at least three copies of a piece of data, and the delay of synchronization between different nodes is a manifestation of soft state.
  • Eventual Consistency: Indicates that all data copies in the system reach a consistent state after a period of time. Weak consistency is the opposite of strong consistency, and final consistency is a special case of weak consistency.

Conway law

In 1967 Melvin Conway proposed what is known as Conway’s Law, which states that there is an implicit mapping between organizational and system architecture: Organization which design system are constrained to produce designs which are copies of the communication structures of these organization.

The organization of a design system produces a design equivalent to a communication structure between organizations.

The other way around:

Conway’s law reversed: You won’t be able to successfully establish an efficient organization structure that is not supported by your system The design (architecture).

You can’t build an efficient organization if the system architecture doesn’t support it; Similarly, you can’t build an efficient system architecture if your organization doesn’t support it.