Shulou(Shulou.com)06/03 Report--

I. definition of architecture

In the field of software development, since the word architecture has been widely spread, there have been a lot of architectural patterns and architectural concerns have increased. But back to the level of "Tao", the definition or essence of architecture is:

Architecture, also known as software architecture, is an abstract description of the overall structure and components of software, which is used to guide the design of all aspects of large-scale software systems.

-extracted from Baidu Encyclopedia

Second, what does the architecture do?

Many friends who feel boring when doing business function add, delete, change and development often think of doing architecture as a paradise, without noisy business sound interference, they can concentrate on doing some awesome technology. The architecture will be simply understood as the performance of Niu X, the TPS of Niu X, the high availability, the number of PV supported, and so on. But in fact, these are only a small part of the architecture, not all. Before the Internet era, Cramp S programs were all in the world. At that time, there was no such attention to performance as it is now, but there is already a theory of architecture. There is no structure in the world, but the bigger the team, the more it needs to make an agreement on the overall rules, so that everyone can work in the same direction, avoid fighting on their own, and produce a lot of internal friction, so the structure is gradually formed. This road is "there is no way in the world, just because more people walk into the road."

Why is a software architecture important? When our team has only two or three people, or even one person alone, the role of architecture prominence may not be so obvious, but if the team is bigger, I believe the following phenomena will be more common:

The new system often does not exist independently, and generally needs to interact with the existing system, but there may be many places that need to integrate and interact, which integration needs to be realized in this system? At the same time, it is generally divided into multiple stages of development, how to define the boundary of the system?

The software system is a whole composed of multiple modules. Therefore, when there is always something wrong with the connection between the upstream development and the module we are responsible for, more efforts can not be made to reverse the negative effects brought about by the poor quality of the upstream module. I think everyone must be freaking out at this time. )

Every time I see the code written by others, I always think that if I write it myself, I will definitely not write it this way. Better than he wrote. It is normal for us to feel good about ourselves when we are technical. )

In some scenarios, I have multiple plans in mind, but I don't have much feeling about which is better or worse. In the end, I basically slapped my head and chose one.

A piece of code is maintained more often, especially after it is taken over by multiple people in the middle, the style of the code is different and difficult to understand.

Similar code appears in several places, especially some non-business code, such as log processing. Moreover, in large-scale distributed systems, different subroutines use different types of middleware, which also leads to a great increase in maintenance costs.

The design at the boundaries of the two dependent projects is divided, and it makes sense from their own point of view.

Everything has two sides, it does not mean that the above problems, we have to go to the other extreme through the architecture. For example, in large distributed systems, it is indeed necessary for different subroutines to choose other middleware of the same type at some time. For example, Kafka and RabbitMQ are both MQ, but the value that can be played in a specific scenario can not be replaced by each other.

Therefore, it is also important for us to do the architecture, that is, to go to the Balance and choose a scheme with the best input-output ratio. A few more words will be said in the fourth paragraph on this point.

In addition, the main purpose of the architecture is to enable everyone to diverge and expand in the same direction and above the same standard. One is to control the hard lower limit standard, to improve the overall shortest version, and the other is to raise the upper level, that is, the ceiling position, to provide more room for development. It is like building a building, designing and setting up the frame structure, so that we can reach a consensus on what is a load-bearing wall that cannot be destroyed and what is a creative space that can be customized. On this basis, they develop separately. This may seem like a limitation, but it is the most important task of architecture. No matter how many documents there are, no amount of best practices can compare with a constraint. It is a real benefit to reduce complexity and difficulty of understanding. What I fear most is the excessive waste caused by empty assumptions.

What's more, the ideal country we pursue as a structure is a world in which we all share a consensus, and architecture is a habit that we all take for granted like eating and drinking water. When you understand or take over a project that someone else is responsible for, it's like you wrote it yourself. The architecture will be destroyed at this time, just as no one will teach you how to eat now. Just think of it as YY. )

Third, best practices for architecture

The above mentioned is more about the purpose of architecture, so to do a good architecture, the main thing is to do a good job of abstraction, the way of abstraction is analogy, the way of analogy can use use case diagrams. Therefore, it is recommended that we draw more pictures, through the drawing to directly reflect the abstract results in the brain in front, and then to further analyze the rationality. Two categories of diagrams are mainly recommended, one of which is the previously mentioned use case diagram. As shown below:

The other is a robust graph, as shown in the figure:

The main purpose of the whole process is:

Describes its interaction with external entities (systems and end users).

Identifies the information and control flow between the system and external entities.

There was a special article entitled "diagrams that will be used in software development". Interested friends can check it in my official account.

In an ideal world, the boundary design of our program happens to match the business boundary. However, as engineers, we first have to bear the pressure of business requirements, so we can only find time to do these non-business tasks. As a result, the business boundaries of old projects are not always as clear as those of new projects.

This means that priority should be taken into account in making any architectural changes, especially thinking carefully about business boundaries before splitting the business domain. Prioritize and consider the benefits and risks of the split. To demarcate the boundaries of the business, we need to think more about how to communicate and cooperate in the future after the split, and then consider the technical factors. Before the technical factors, the main considerations are as follows:

Whether there is an independent team to maintain, and whether it has the potential to develop into an independent business. (be sure to avoid shared kernel development unless it is necessary)

Around the domain rather than feature, there is a clear maintenance team to avoid being too fine-grained.

Whether the existing collaboration process can be improved after split or combination.

Whether it can help distinguish core business from non-core business and improve stability.

After the completion of the above, it is necessary to choose the appropriate middleware and technical framework to meet the technical requirements. The selection of this is mainly based on the following points:

If it is the direct introduction of third-party middleware, what is the maturity? Is there a big company using it? (those who have word-of-mouth endorsement from big companies definitely get a lot of points.)

How is the recent community activity? (used to consider whether there are more people stepping on the pit together, reducing the number and probability of each encounter.)

Hard indicator, whether the rigid requirements of the current scene are met. Such as performance, scalability for key parts or future, etc.

Soft indicators, complexity, maintainability, etc. Here you can list the advantages and disadvantages of several competing products.

The most important thing is to personally verify the above points, and do some simulation work.

If you have ever used it or have some experience that can be reused, this is an additional item. After all, it is disastrous to find that hold can not live in it in the process of using it.

IV. What is a good structure

I have heard a sentence before, which is summed up brilliantly. A good architecture must fit the business, so the evolution of the business + technology into a mathematical formula can be understood as: the sum of two numbers equals 10, and how to combine to get the maximum product. It's not 3-7, it's not 4-6, it's 5-5.

So architecture is not to copy mechanically, to build for the sake of architecture (causing trouble), to follow the fashion, or to install X. We should avoid leading through the subjective will of individuals. For example, if you think a certain middleware is good, you "take a hammer and look for nails everywhere". This knock down looks good, but the costs and risks are ignored. There may be a better solution, or there may be no need to hit the nail right now.

A good architecture needs to judge the input-output ratio, and a higher return is a better architecture, as shown in the following figure. Output can be understood as the benefits we get as a result (such as reliability, security, scalability, maintainability, scalability, performance, etc.), and the cost is the investment we spend on transformation, such as manpower and time. Special attention is paid to the point of risk, which is very important and easy to be overlooked, which plays an exponential role. No matter how good the choice is, if it is some hold technology, then the risk is infinite, causing the right side of the minus sign to approach 0 infinitely, and the end result is that the income is negative, the cost of input is wasted, and even other extra costs are added.

How to become an architect

The concerns mentioned above are the responsibility of the architect, and it is particularly important that the architect must be a "good farmer" with pursuit! (draw key points). Unlike architects, software architects are faced with an abstract thing, which is basically the same as talking on paper. Therefore, the difficulties and key points in the actual work should be clear, and the solution or direction can be given. In addition, only by being familiar with practical operation can we evaluate the cost more accurately.

Becoming a real "good farmer" takes the first step towards the architect. After that, we need to constantly expand our territory and expand our own field of knowledge in a deep-> wide-- > deep-- > broad rhythm. Of course, we need to give priority to knowledge close to the content of the current work. This is the second step. It's not over yet, and there are three ways to build it: business skills, communication skills, and personal charisma.

Beside the point, in China, pure technical architects are not as good as applied architects. Therefore, this article is based on the functional requirements of the application architect.

VI. Conclusion

Going back to the beginning of the article, there are many forms of architecture. In essence, the architectural design idea of a single application is the same as that of a distributed system. The so-called service is actually a modular idea, but the dimensions are different, resulting in different tools or environments used, but these are all "technical" things. These tricks of optics can never be learned. The road of architecture is long, continue to move forward, encourage together.

Author: Zachary_Fan

Source: https://blog.51cto.com/4596298/2147603

If you want to get the message of your own article in time, you are welcome to scan the QR code below.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.