preamble
When a large project requires a large number of people to jointly develop and ensure that a large number of server nodes distributed in the network can run at the same time, as the project scale increases and the running time becomes longer, it will inevitably be mercilessly hit by Murphy's Law .
Murphy's Law: Anything that can go wrong will go wrong.
Murphy's Law: Anything that can go wrong will go wrong.
In order to obtain high-quality software products, we should focus more on improving the capabilities of developers, or on the overall process and architecture.
Both are important, the former focuses on surgery, and the latter focuses on Taoism. The former is determined at the level of individual developers, and the latter is determined at the level of technical decision makers.
Architecture is not "invented", but the result of continuous evolution.
The single layered architecture in springboot can download the project reference in gitclone
git clone https://gitclone.com/github.com/fenixsoft/monolithic_arch_springboot
After downloading, you can use docker to start the project or run BookStoreApplication directly, and then visit in the browser: http://localhost:8080, the system presets a user (user:icyfenix, pw:123456), you can also register a new user to tested. Note that I run this time because jekenis occupies port 8080, you can modify the port of jekenis or the port of this project.
When running docker, the input command docker versionoutputs docker version information by default, including two parts: client and server. The following is the client part. Refer to the Docker version command
large monolithic system
Monolithic architecture is a software architecture that most software developers have learned and practiced. In many books and technical materials introducing microservices, the application of this architectural style is often called "Monolithic Application". .
"Monolithic architecture" is an architectural style with the earliest appearance, the widest application range, the largest number of users, and the longest ruling history in the entire historical process of software architecture evolution. However, the name "monolithic" is in the The concept formed after the microservices became popular was "recognized after the fact". Previously, not many people regarded "monolithic" as a kind of architecture. If you look up the development materials of software architecture, you can easily find a large number of books and articles on the theme of microservices, but it is difficult to find Specially teach you how to develop any form of material for a monolithic system. On the one hand, it reflects the simplicity of the monolithic architecture itself. On the other hand, it also reflects that in a long time scale, everyone has become accustomed to software architecture. It should be like this.
Before analyzing the monolithic architecture, we need to clarify a conceptual misunderstanding. In many microservice materials, the monolithic system often appears as a "villain". For example, the famous microservice introductory book "Microservice Architecture Design Patterns" ", the name of the first chapter is "Escape from the Hell of the Single Body". The monomer systems mentioned in these materials actually have an implicit attributive that is not explicitly stated: "large monomer systems". For a small system—that is, a single machine is enough to support its good operation, the monomer is not only easy to develop, easy to test, and easy to deploy, but also because the calling process of each function, module, and method in the system is an in-process call, No inter-process communication (Inter-Process Communication, IPC. Broadly speaking, RPC can be considered a special case of IPC, but please note that the two "PC" are not the abbreviation of the same word), so it is also the most efficient An architectural style that should not be labeled as a "villain" at all. On the contrary, those microservice advocates who love to follow the technological trend but ignore the status quo of demand are more like villains.
Inter-process communication: Inter-Process Communication, IPC. RPC (Remote Procedure Call, remote procedure call) is a special case of IPC.
The lack of a single system must be based on the fact that the performance requirements of the software exceed that of a single machine, and the scale of software developers obviously exceeds the category of "2 Pizza Team". Therefore, the single system mentioned in the follow-up discussion of this article , both should refer specifically to "large-scale monolithic systems", and for this reason, this section says that "monolithic is the earliest architectural style", which is similar to the "using The idea and actual attempt of multiple independent distributed services to build a larger system together appeared earlier than the large single system that everyone knows today." There is actually no contradiction.
Detachable single system
Monolith means composed all in one
piece. The Monolithic application describes a single-tiered software application in which different components combined into a single program from a single platform. —— Monolithic
Application, Wikipedia
The procedure calls are all intra-process calls, no inter-process communication occurs, that's all.
The definition of a single system in Wikipedia is "All in One Piece", translated as "a single piece of iron", which is actually closer to the meaning of self-sufficiency (Self-Contained).
-
Vertical
perspective Layered Architecture (Layered Architecture) is now almost all information system construction, are generally recognized, commonly used software design method. Regardless of whether it is a single unit or a microservice, or other architectural styles, the code will be split vertically, and the received external requests will be transferred between the layers in different forms of data structures. The database returns responses in turn.
-
Horizontal perspective
Monolithic architecture can also support the splitting of software into various modules in terms of technology, function, and responsibility for reuse and team management.
After the load balancer, several copies of the monolithic system are deployed at the same time to achieve the effect of distributing the traffic pressure, so based on the monolithic architecture, it can be easily realized.
dependent monomer
However, in terms of "splitting", the real defect of the monolithic system is not actually how to split it, but that it will have a lack of isolation and autonomy after the split.
In the monolithic architecture, all codes run in the same process space, and all modules and method calls do not need to consider network partitions, object replication and other troublesome things, and do not worry about performance loss caused by data exchange loss. However, while obtaining the benefits of simplicity and high efficiency of in-process calls, it also means that if any part of the code in the monolithic architecture has defects and excessively consumes public resources in the process space, the resulting The impact is global and difficult to isolate.
Once problems such as memory leaks, thread explosions, blocking, and infinite loops appear in the architecture, they will affect the operation of the entire program, not just the normal operation of a certain function or module itself; Higher-level public resources, such as excessive port occupation or database connection pool leaks, will also affect the entire machine, and even the normal work of other single copies in the cluster.
Because all codes share the same process space, if the codes cannot be isolated, it means that we cannot stop, update, and upgrade a certain part of the codes independently, because it is impossible to have "stop half the process, restart 1/ 4 processes" such an illogical operation. Therefore, from the perspective of dynamic maintainability, the monolithic system is also insufficient. For work such as program upgrades and defect corrections, we often need to formulate special downtime update plans, and it is relatively easier to do grayscale releases. complex.
Due to the lack of isolation ability, in addition to the problems of difficulty in blocking error propagation and inconvenient dynamic update of programs, it will also bring difficulties such as difficulty in technology heterogeneity.
Technology heterogeneity
Martin Fowler (Martin Fowler) proposed 9 characteristics of microservices, technology heterogeneity is one of them. It means that each module of the system is allowed to freely choose different programming languages, different programming frameworks and other technology stacks to implement. The technology stack heterogeneity of a single system is not necessarily impossible. For example, JNI can allow Java to mix C/C++, but this is also very troublesome and is a forced choice.
Fundamentally speaking, the underlying concept of the monolithic architecture style is to hope that every part of the system, and even every piece of code, is as reliable as possible, with no errors and fewer mistakes, and is committed to building a 7×24 hours uninterrupted reliable system. This concept works well for small-scale software, but as the system grows larger, it becomes more and more challenging to deliver a reliable monolithic system. Remember a word, as the amount of code becomes larger and larger, the corruption of the system is inevitable.
In general, the development of the monolithic architecture and its advantages and disadvantages are shown in the figure below.
Reference link:
1. https://zhuanlan.zhihu.com/p/575500324
2. "Zhou Zhiming's Software Architecture Course" - Geek Academy