Problems with monolithic application architecture
An archive package (such as war format) contains all functional applications, usually called a monolithic application. The methodology of architecture monolithic applications is monolithic application architecture.
Take a movie ticketing system as an example, the architecture is shown in the figure.
Although the application has been modularized, the UI and several service modules are finally packaged in a war package, which contains all the business functions of the entire system. Such an application system is called a monolithic application.
I believe that many projects start from a single application. Monolithic applications are easier to deploy and test. In the early stages of the project, monolithic applications can run well. However, as the demand continues to increase, more and more people join the development team, and the code base is also rapidly expanding. Slowly, single applications become more and more bloated, maintainability and flexibility are gradually reduced, and maintenance costs are getting higher and higher. Listed below are some of the problems with monolithic applications.
- High complexity: Take a single million-line application as an example. The entire project contains a lot of modules, the boundaries of the modules are blurred, the dependencies are not clear, the code quality is uneven, and they are piled up chaotically... The whole project is very complex. Every time you modify the code, you are frightened, even adding a simple function or modifying a bug will bring hidden defects.
- Technical debt: With the passage of time, changes in requirements and personnel turnover, technical debt of the application will gradually form, and it will accumulate. "Not broken, don not fix", which is very common in software development, and even more so in monolithic applications. The used system design or code is difficult to modify because other modules in the application may use it in unexpected ways.
- Deployment frequency is low: As the code increases, the time to build and deploy will also increase. In a monolithic application: each function change or defect repair will lead to the need to redeploy the entire application. The full deployment method takes a long time, has a large scope of influence, and has high risks, which makes the frequency of online deployment of a single application project relatively low. The low deployment frequency has led to a large number of feature changes and defect repairs between two releases, and the probability of errors is relatively high.
- Poor reliability: A bug in an application, such as infinite loop, OOM, etc., may cause the entire application to crash.
- Restricted scalability: A single application can only be extended as a whole, and cannot be scaled according to the needs of business modules. For example, some modules in the application are computationally intensive and require a powerful CPU; some modules are IO-intensive and require more memory. Since these modules are deployed together, compromises have to be made in the choice of hardware.
- Obstructing technological innovation: A single application is born to use a unified technology platform or solution to solve all problems. Each member of the team must use the same development language and framework. It will be very difficult to introduce new frameworks or new technology platforms. . For example, a monolithic application built with Struts 2 with 1 million lines of code, if you want to switch to Spring MVC, the cost of switching is undoubtedly very high.
In summary, with the development of business requirements and the continuous increase of functions, it is difficult for a single architecture to meet the needs of rapid business changes in the Internet era.