Architecture Design 1 - Infrastructure

Introduction: The "Architecture Design" series is the course notes of "Learn Architecture from 0" by Mr. Li Yunhua of Geek Time. This article is the first part, which mainly introduces the historical background, related concepts, purpose, complexity, principles and processes of architecture design. Have an understanding of architectural design as a whole.

Scan the QR code at the end of the article, follow the official account and reply to "architecture design" to get the complete mind map of architecture design notes

Historical Background of Architecture Design

Machine language (before 1940)

The main problem with machine language is the trilemma: too hard to write, too hard to read, and too hard to change!

Assembly Language (1940s)

It is still machine-oriented in nature, because writing assembly language requires us to accurately understand the underlying knowledge of the computer.

High-level languages (1950s)

The First Software Crisis and Structured Programming (1960s-1970s)

• Typical manifestations are low software quality, project can not be completed on schedule, serious project overrun, etc. Major accidents caused by software occur from time to time.
• Software engineering also cannot eradicate the software crisis, but can only alleviate the software crisis to a certain extent.
• The main feature of structured programming is to abandon the goto statement and adopt the guiding ideology of "top-down, gradual refinement and modularization". Structured programming is essentially a process-oriented design idea, but through the method of "top-down, gradual refinement and modularization", the complexity of the software is controlled within a certain range, thereby reducing the overall The complexity of software development.

The Second Software Crisis and Object Orientation (1980s)

• The root cause of the second software crisis is that software productivity is far behind the development of hardware and business. The root cause of the first software crisis is that the "logic" of the software becomes very complicated, while the second software crisis is mainly reflected in the "expansion" of the software becoming very complicated.
• Although structured programming can solve the complexity of software logic (perhaps it is more appropriate to use "mitigation"), it cannot do anything about software expansion brought about by business changes. The software field is eager to find a new silver bullet to solve the software crisis. In this context, object-oriented thinking became popular.

Historical Background of Software Architecture

As software systems increase in size, computation-related algorithms and data structures no longer constitute a major design problem; when a system consists of many parts, the organization of the entire system, known as "software architecture," leads to a series of New design issues.

• The scale of the system is huge, the internal coupling is serious, and the development efficiency is low;
• The system coupling is serious, and the whole body is affected, and subsequent modification and expansion are difficult;
• The system logic is complex and prone to problems, and it is difficult to troubleshoot and repair after a problem occurs

Three groups of easily confused concepts

Systems and Subsystems

system

• A system generally refers to a group consisting of a group of related individuals that operate according to certain rules and can perform tasks that individual components cannot do alone. It means "total", "whole" or "union"
• Relationship: The system is composed of a group of related individuals, and the unrelated individuals cannot be a system when piled together.
• Rules: Individuals in the system need to operate according to specified rules, rather than individual individuals acting in their own way. Rules specify how individuals within the system divide and collaborate.
• Capability: There is an essential difference between system capability and individual capability. System capability is not the sum of individual capabilities, but produces new capabilities.

subsystem

A subsystem is also a system composed of a group of related individuals, most likely part of a larger system.

Summarize

The architecture of a system includes only the architecture at the top level, not the architecture at the subordinate subsystem level. Therefore, the WeChat architecture refers to the architecture of the WeChat system at this level. Of course, WeChat's subsystems, such as the payment system, also have their own architecture, again including only the top layer.

Modules and Components

module

A software module is a set of consistent and closely related software organizations. It contains two parts, the program and the data structure respectively. Modern software development often utilizes modules as the unit of composition. A module's interface expresses the functionality provided by the module and the elements required to invoke it. Modules are units that can be written separately. This makes them reusable and allows people to collaborate, write and study different modules at the same time.

components

Software components are defined as self-contained, programmable, reusable, language-independent software units that can be easily used to assemble applications.

Summarize

• Modules and components are both part of the system, just splitting the system from different perspectives.
• After splitting the system from the perspective of business logic, the obtained unit is "module"; after splitting the system from the perspective of physical deployment, the obtained unit is "component". The main purpose of dividing modules is separation of duties; the main purpose of dividing components is unit reuse.
• Suppose we want to make a student information management system. This system can be split from a logical point of view and can be divided into "login registration module", "personal information module" and "personal achievement module"; from a physical point of view, it can be split Divided into Nginx, Web server and MySQL.
• The architect of a business system needs to think about how to split the system into module roles from the perspective of business logic, and secondly, how to split the system into component roles from the perspective of physical deployment, such as choosing MySQL as the storage system. But for MySQL's internal architecture (you don't need to pay attention, and you don't need to show these in your business system architecture.

Framework and Architecture

frame

Software framework usually refers to a software component specification for implementing a certain industry standard or completing a specific basic task, and also refers to a software product that provides the basic functions required by the specification when implementing a software component specification.

Architecture

Software architecture refers to the "infrastructure" of a software system, the principles for creating these infrastructures, and the description of those structures.

Summarize

• Frameworks are concerned with "specs", architectures are concerned with "structures".
• The framework is a set of development specifications, and the architecture is a specific implementation plan under a certain set of development specifications, including the combination relationship between various modules and the operation rules for them to work together to complete functions.

Redefining Architecture: The 4R Architecture

• Software architecture refers to the top-level (Rank) structure of a software system, which defines which roles (Role) the system consists of, the relationship between the roles (Relation) and the operating rules (Rule)
• Rank: It means that the software architecture is hierarchical, corresponding to the hierarchical relationship between "system" and "subsystem". Usually, we only need to pay attention to the architecture of one layer, and show the architecture of two adjacent layers at most, without mixing the architecture of each layer together. Whether it is architectural design or architectural drawing, a "top-down, gradual refinement" approach should be adopted.
• Role: It refers to which roles are included in the software system, and each role is responsible for part of the system's functions. One of the most important jobs of architectural design is to split the system into roles. The most common microservice split is actually to split the overall complex business system into multiple microservices according to the business domain, and each microservice is a role of the system.
• Relation: It refers to the relationship between the roles of the software system. Corresponding to the architecture diagram, it is actually a connection line. The relationship between roles cannot be connected randomly. Any relationship needs to be realized by code, including connection methods (HTTP, TCP, UDP and serial ports, etc.), data protocols (JSON, XML, binary, etc.), and specific interfaces, etc.
• Rule: It refers to how the software system roles cooperate to complete system functions.

The purpose of architectural design

Architecture is also a solution to deal with the complexity of software systems, that is, the main purpose of architecture design is to solve the problems caused by the complexity of software systems.

• Following this guideline will give "novice" architects some insight, rather than confusion .
• Following this guideline allows the "old bird" architect to have a purpose, rather than being greedy for everything.

source of complexity

high performance

The complexity brought by high performance in a software system is mainly reflected in two aspects. On the one hand, it is the complexity brought by a single computer for high performance ; on the other hand, it is the complexity brought by multiple computer clusters for high performance .

Single machine complexity

• The operating system and performance are most related to processes and threads
• If we want to complete a high-performance software system, we need to consider technical points such as multi-process, multi-threading, inter-process communication, multi-thread concurrency, etc., and these technologies are not the latest or the best, nor are they either. choose.

Cluster complexity

• Task distribution, load balancing

• Task decomposition, microservices

  • Simple systems are easier to achieve high performance
  • Can be scaled for individual tasks

index

Measuring software performance includes objective indicators such as response time, TPS, server resource utilization, etc.

High availability

The ability of a system to perform its functions without interruption represents the degree of availability of the system and is one of the criteria for system design.
There are various high-availability solutions for the system, but all changes are inseparable. Essentially, high availability is achieved through "redundancy".

• High-performance augmented machines are designed to "extend" processing performance;
• High availability adds machines to "redundant" processing units.

Computing high availability

"Calculation" refers to the logical processing of a business. One of the characteristics of computing is that no matter which machine is used for computing, the same algorithm and input data will produce the same results.

storage high availability

• The key point and difficulty of the high-availability design of the entire system is "storage high-availability". There is an essential difference between storage and computing: moving data from one machine to another requires transmission over wires.
• The difficulty of high availability of storage is not how to back up data, but how to reduce or avoid the impact of data inconsistency on business.

High Availability Decision

Whether it is computing high availability or storage high availability, the basis is "state decision", that is, the system needs to be able to determine whether the current state is normal or abnormal, and if there is an abnormality, it must take action to ensure high availability

• authoritarian
• negotiated
• democratic

Scalability

Scalability refers to an expansion capability provided by the system in order to cope with future changes in demand. When new requirements appear, the system can be supported without or with only a small amount of modification, without the need for reconstruction or reconstruction of the entire system.
To design a system with good scalability, there are two basic conditions:

• Correctly predict changes

  • Principle: only predict possible changes in 2 years, don't try to predict changes in 5 or even 10 years.

• Perfect for change

  • Option 1: Extract the "change layer" and "stable layer", the core idea is to isolate changes through the change layer
  • Option 2: Extract the "abstract layer" and "implementation layer". The core idea is to encapsulate changes through the implementation layer.
  • Principle: 1 write 2 copy 3 refactoring principle

other sources

cost

Often only "innovation" can achieve low-cost goals

• Introduce new technology
• Self-developed new technology

Low cost is inherently in conflict with high performance and high availability, so low cost is often not the primary goal of architectural design, but an additional constraint of architectural design.

Safety

• Functional safety: in fact, "anti-thief"
• Architectural Security: It's "Anti-Bandit"

scale

• The main reason why scale brings complexity is that "quantitative change leads to qualitative change"
• With more and more data, the system complexity has changed qualitatively

Architecture Design Principles

The fit principle, "fit is better than industry-leading"

Not suitable

• Not so many people, but want to do so much work
• I don't have so much accumulation, but I want to go to the sky in one step
• There is no such excellent business scene, but the fantasy flashes to become a genius

The principle of simplicity, "simple is better than complex"

complex performance

• the complexity of the structure

  • Phenomenon

    • The number of components that make up a complex system is greater
    • At the same time, the relationship between these components is also more complex

  • question

    • The more components there are, the more likely it is that one of them will fail
    • Changes to a component will affect all associated components
    • Locating problems in a complex system is always more difficult than in a simple system

• the complexity of logic

  • A single component takes on too many functions
  • using complex algorithms

Evolution principle, "Evolution is better than one step"

For software, change is the theme

Software architecture design is actually more similar to nature "designing" a creature, allowing creatures to adapt to the environment through evolution and gradually become more powerful

avoid pit

• Always remind yourself not to be greedy
• Avoid blindly copying the practices of big companies

Best Practices

• It is necessary to carefully analyze the characteristics of the current business, clarify the main problems faced by the business, design a reasonable structure, and quickly implement the business to meet the needs of the business.
• Continuously improve the architecture during operation, and continuously evolve the architecture with the business

Architecture Design Process

recognition complexity

• List the main complexity problems, and then sort them according to the comprehensive situation of business, technology, team, etc., and give priority to solving the most important complexity problems currently facing.
• Design goals should be calculated in terms of peaks. The peak value is generally 3 times the average value,
• The design target is set at 4 times the peak value, which is estimated based on the speed of business development. It is not fixed at 4 times. Different services can be 2 times or 8 times, but generally do not set more than 10 times. Don't estimate it by 100 times as soon as it comes up.

Design Alternatives

New technologies are developed on the basis of existing technologies. ` `

Common mistakes

• Design the best solution

• only one plan

  • disadvantages

    • The mental assessment is too simple and may not be comprehensive
    • A single plan design will be overly defended,
    • No matter how good an architect is, experience, knowledge and skills are also limited

  • practice

    • The optimal number of alternatives is 3 to 5
    • The difference between the alternatives is more obvious
    • Alternative technologies should not be limited to already familiar technologies

• Alternatives are too detailed

  • Spent a lot of time and effort
  • Focusing on the details and ignoring the overall technical design results in insufficient number of alternatives or little difference.
  • During the review, other people will be surrounded by many details, and the review effect is very poor.
  • The correct approach is to focus on technical selection in the alternative stage, not technical details, and the difference in technical selection should be more obvious

Evaluate and select alternatives

Common guiding ideology

• minimalist
• The best
• most familiar
• leadership

Evaluation strategy

• List the quality attribute points we need to pay attention to, and then evaluate each scheme from the dimensions of these quality attributes, and then comprehensively select the optimal scheme suitable for the current situation
• Common solution quality attribute points are: performance, availability, hardware cost, project investment, complexity, security, scalability, etc.
• Usually, if the evaluation of a quality attribute is related to business development (for example, performance, hardware cost, etc.), when it is necessary to evaluate the scale of future business development, a simple way is to multiply the current business scale by 2~4 That is, if the current base is low, you can multiply by 4; if the current base is high, you can multiply by 2.
• That is, the architect takes the current business development situation, team size and skills, business development forecast and other factors into consideration, and prioritizes the quality attributes. First select the one that meets the first priority. If all the solutions are satisfied, then look at the second one. Priority...and so on.

Detailed design scheme

An extreme situation that may be encountered during the detailed design phase is when an alternative solution is found to be infeasible during the detailed design phase.

• Architects not only need to design and select alternatives, but also have a deeper understanding of the key details of alternatives
• The complexity of the scheme can be reduced as much as possible by means of steps, stages, and systems. The higher the complexity of the scheme itself, the higher the possibility of overturning the entire scheme by a particular detail. Appropriately reducing the complexity can reduce this risk.

reference

1. Learn Architecture from 0