Many people have tried to define "architecture", but these definitions themselves are difficult to unify. There are two points that can be unified: one is "the highest level of system decomposition", and the other is "decisions that are not easy to change in the system." However, there is more than one way to express a system architecture.
Architecture is a subjective thing, it is some shareable understanding of system design by expert developers. Generally, this sharable understanding is manifested in the main components of the system and the relationships between these components. It also includes some decisions, developers hope that these decisions can be made early, because in the eyes of developers, they are difficult to change.
The architecture is actually how to organize enterprise applications into different levels, and how these levels work together. Most important enterprise applications are designed according to some form of hierarchy.
Mainly solve high concurrency, massive data, complex business logic
Before we discuss how to design enterprise applications and which models to use, it is very important to make it clear that enterprise applications are diverse and different problems will lead to different approaches. If someone says, "Always do this", it should sound the alarm. In my opinion, the most challenging part of design is to understand what design methods are available and the pros and cons of different design methods.
***Response time*** is the time required for the system to complete an external request processing.
***Throughput rate*** is the amount of requests that can be processed in a given time. For enterprise applications, throughput is usually measured in transactions per second (TPS).
When optimized through a certain technology, the throughput rate of the system is increased, but the response time is reduced. At this time, it is hard to say that the performance of the system is improved, and it is better to use more accurate terms.
***Load*** is an expression about the current system load, and may be expressed by how many users are currently connected to the system. Load is sometimes used as the background for other indicators (such as response time). Therefore, we can say that in the case of 10 users, the request response time is 0.5 seconds, and in the case of 20 users, the request response time is 2 seconds.
Load sensitivity*** refers to the degree of response time varying with load. Assumption: when system A has 10 to 20 users, the request response time is 0.5 seconds, system B has 10 users, the request response time is 0.2 seconds, and when there are 20 users, the request time increases To 2 seconds. At this time, the load sensitivity of system A is lower than that of system B; we can also use the term *** degradation, which means that system B attenuates faster than system A.
***Efficiency*** is performance divided by resources. If the performance of a dual-CPU system is 30TPS and the other system has 4 identical CPUs and the performance is 40TPS, the former is more efficient than the latter.
The ***capacity*** of the system refers to the index of the maximum effective load or throughput rate. It can be an absolute maximum or a critical point before performance decays below an acceptable threshold.
***Scalability*** measures the impact of adding resources (usually hardware) to the system on system performance. A scalable system allows a reasonable increase in performance after adding hardware. For example, how many servers should be added in order to double the throughput rate. Vertical scalability is called vertical expansion, and is usually to improve the performance of a single server, such as adding content. Horizontal scaling is called horizontal scaling and usually only increases the number of servers.
When building enterprise application systems, it is often more important to pay attention to hardware scalability than to pay attention to capacity and efficiency. If needed, scalability can give you better performance, and scalability can also be easier to achieve. Sometimes, it takes a lot of effort for the designer to increase the capacity a little, and the cost is not as good as buying more hardware. Similarly, adding more servers is cheaper than adding more programmers—as long as your system is sufficiently scalable.
mode
Each pattern describes a recurring problem around us and the core of the solution to that problem. In this way, you can use the program again and again without having to do repeated work.