PAAs service path (2)

This article has been published by the author Yao piaohai to authorize the Netease cloud community.

Welcome to the Netease cloud community to learn more about the operation experience of Netease technology products.

The trend of the world is always the same, and the trend of social history is always quite similar. Applying this rule to the development direction of the software application architecture will also lead to the evolution of the software architecture when the production force and production relationship reach an irreconcilable contradiction, this evolution will further promote the development of software and bring about many problems. Therefore, at different stages, it is reasonable to adopt different architectures to adapt to business development, it is easy to hold the eggs, the step is too big, it is easy to hold the eggs.

From the development of Web application technology in the previous article, the Service Architecture of Web applications can be divided into monolithic (entire architecture) and MSA (microservice architecture ). In addition, many small and medium-sized applications still use the monolithic architecture model. Different architecture models will produce different effects for applications of different scales. Next we will analyze the two architectures in a simple way.

Monolithic architecture

With the development of mobile applications, server programs need to provide different capabilities to support desktop, browser, and mobile terminals. Early applications can be implemented through technologies such as CORBA and EJB. Recently, considering the compatibility and simplicity of various platforms, most messages are consumed and exchanged by a third party by exposing related service interfaces or message proxies. Applications are basically structured in layers or combinations, and different components perform relevant responsibilities.

• The presentation layer is mainly responsible for processing HTTP-related requests and then returning different response formats, including HTML and JSON.

• The business logic, that is, the control layer, is responsible for application logic processing.

• Database layer, responsible for data storage and organization at the model layer

The implementation of this architecture is as follows:

In the daily software development process, there is often such a non-functional requirement as to what kind of software model is used:

• A complete development team is required to ensure the application development progress.

• The new team is expected to quickly integrate into the team and get started quickly.

• Applications hope to be easily understood and modified

• Application support continuous deployment

• Better scalability, high availability, and other non-functional requirements

• Able to quickly leverage the dividends of new technologies

After developing and testing related functions, what kind of deployment methods will be used when launching the product? Most Java applications are implemented using jar or war. For other languages, the entire directory is packaged for deployment, most of the applications in our automatic deployment platform system adopt this method for deployment and launch.

The advantages of this architecture model are:

• Easy to develop the entire application can be directly completed using development tools or IDE. In addition to some dependent services, it can be basically completed on a single machine.

• Testing is simple because it does not involve the interaction of multiple systems, the corresponding testing process will become relatively simple, and a single process can complete relevant testing.

• The deployment is simple through some deployment tools or even shell scripts to complete the deployment of the entire application. Others are nothing more than standardized or customized.

• O & M is easy to scale out by replicating multiple copies, and Server Load balancer completes request routing.

Of course, with the development and expansion of the system, some problems of the monolithic architecture have also been exposed:

• A large amount of code often causes developers to be unable to easily refactor due to risks. At the same time, a complete test case is required to ensure the reconstruction is complete. In addition, for newcomers, unclear module division will also bring about a lot of frustration, basically for a period of time do not dare to modify the application function, rather add new methods to complete. A large part of people use new features, which makes the entire system more complex and becomes unmanageable soon.

• A large amount of code will lead to a very long co code time, And the Compilation Time and running time of the corresponding ide will become unpredictable, in the past, I encountered a problem where my colleague's code was too long and the bug was fixed when I went online, which caused eclipse to die and greatly reduced the work efficiency; in addition, the startup time of the Application container will also become longer due to the rapid increase of application code, and cannot be started quickly, resulting in longer debugging and testing time, affecting the application progress. The user's service time is also affected during deployment.

• Continuous deployment is also very difficult. If the application needs to be released from time to time, this will also be a disaster for the use of O & M. to modify a problem, the whole application will be re-packaged and deployed, compilation takes a long time to package, especially when the back-end application modifies the front-end code, which is a great waste of time for O & M personnel. If features such as scheduled tasks in an application may also affect business data, the O & M risks are getting higher and higher. In addition, developers complain about the O & M mode, as a result, O & M personnel are more and more resistant to publishing, resulting in more and more serious conflicts. In the feedback from colleagues on using the automatic deployment platform, developers and O & M personnel sometimes complain about each other.

• Expansion is also difficult. Although Web applications in most departments can support horizontal expansion, in fact, when the application scale is extended to the backend service, for example, a single backend database cannot be expanded when the connection resources are insufficient. In addition, competition for other resources will lead to the inability to truly expand, because the system will certainly have hot data when it reaches a certain scale, and this hot data will often lead to the failure of the entire system to provide normal services. Each module of the system uses different resources, some of which are CPU-intensive and some are io-intensive. Therefore, it cannot be expanded, but the system is not as big as it is.

• The obstacles to rapid development the entire application architecture will also lead to the dependency of the entire development team. Generally, an application will eventually develop into different engineer teams based on specific functions, for example, the UI group, interaction group, member group, front-end group, and other architecture forms, which make the teams of different jobs depend on each other, modifying a function independently will lead to system staff dependency and risk assessment, which also makes the product unable to be quickly iterated.

• Technical debt: This architecture forces developers to rely heavily on relevant technologies. For example, they can only use the Java language, or even rely on specific software versions, this will also make the software unable to adopt the latest version, but it can only be done through patches and patches, resulting in increasing technical debt. If the software version used does not provide maintenance, it can only be implemented by a specific person or team or the whole application rewrite method. This is very common in actual application development, large companies such as Microsoft cannot avoid this problem, which will lead to related risks.

In the above section, we analyze the advantages and problems of the monolithic architecture based on the problems encountered in actual application. However, this article does not mean that the monolithic architecture is useless, but only describes the applicable scenarios of this architecture model, in fact, it still works well in most systems by using this mode. If you reference the Old Wang Yuan master goolge, just work is good.

In order to avoid the long and smelly cloth in this article, we will continue to analyze the MSA service architecture in the next article. Coming soon.

PAAs Services (1)

Netease Cloud Computing Basic Services deeply integrate IAAs, paas, and container technologies to provide Elastic Computing, devops tool chain, microservice infrastructure, and other services to help enterprises solve it, architecture, O & M, and other problems, it enables enterprises to focus more on their businesses and is a new generation of cloud computing platform. Click here for free trial.

Related Articles:
[Recommended] Spring Distributed Transaction learning notes (2)
[Recommendation] what is the microservice architecture?

PAAs service path (2)