If a software developer does not understand the evolution of the software architecture, it will restrict the selection of technology and the survival and promotion space of the developer. Here I have listed the four main software architectures and their advantages and disadvantages, hoping to help software developers expand their knowledge.
1. Monolithic architecture
Monolithic architecture is relatively rudimentary, a typical three-level architecture, front-end (Web/mobile terminal) + intermediate business logic layer + database layer. This is a typical Java Spring mvc or Python Drango framework application. The architecture diagram is as follows:
Monolithic architecture
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 rapidly expanding. Slowly, single applications become more and more bloated, maintainability and flexibility are gradually reduced, and maintenance costs are getting higher and higher. Here are some disadvantages of 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. It is conceivable that the whole project is very complicated. Every time you modify the code, you are frightened, even adding a simple function or modifying a bug will bring hidden defects.
Technical debt: Over time, demand changes and personnel turnover will gradually form technical debt of the application, and it will accumulate. "No damage, no repair", this is very common in software development, and this idea is even worse 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.
Low deployment frequency: As the code increases, the time to build and deploy will also increase. In a monolithic application, each function change or defect repair will result in the need to redeploy the entire application. The full deployment method takes a long time, has a large impact area, and has high risks, which makes the frequency of online deployment of a single application project lower. The low deployment frequency has led to a large number of feature changes and defect repairs between the two releases, and the error rate is relatively high.
Poor reliability: A bug in an application, such as an infinite loop, memory overflow, 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: Monolithic applications often 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.
2.
Intermediate architecture for distributed applications, distributed applications, middle-tier distributed + database distributed, is a concurrent expansion of a single architecture, a large system is divided into multiple business modules, and the business modules are deployed on different servers. , The various business modules exchange data through interfaces.
The database also uses distributed databases, such as redis, ES, and solor. Through the LVS/Nginx proxy application, the load of user requests is balanced to different servers. The architecture diagram is as follows:
Distributed architecture
Compared with the monolithic architecture, this architecture provides load balancing capabilities, greatly improves the system load capacity, and solves the high concurrency requirements of the website.
There are also the following features:
Reduced coupling: split the modules and use interface communication to reduce the coupling between modules.
Clear responsibilities: split the project into several sub-projects, and different teams are responsible for different sub-projects.
Convenient extension: When adding functions, you only need to add another sub-item and call the interfaces of other systems.
Easy to deploy: Distributed deployment can be carried out flexibly.
Improve code reusability: For example, the service layer, if the distributed rest service architecture is not adopted, a service layer logic will be written on each end of the mobile wap mall, WeChat mall, pc, android, and ios, and the amount of development is large. It is difficult to maintain and upgrade together. At this time, the distributed rest service method can be used to share a service layer.
Disadvantages: The interaction between systems requires remote communication, and interface development increases the workload, but the advantages outweigh the disadvantages.
In addition, pay attention to the Java technology stack of the official account, and reply in the background: Interview, you can get the Java distributed interview questions and answers that I have compiled, which is very complete.
3. Microservice architecture The
microservice architecture is mainly the decomposition of the middle layer, which splits the system into many small applications (microservices). The microservices can be deployed on different servers or on different containers on the same server. When the failure of the application will not affect other applications, the load of a single application will not affect other applications. Its representative frameworks are Spring cloud, Dubbo, etc.
The architecture diagram is as follows: 
microservice architecture
Easy to develop and maintain: A microservice will only focus on a specific business function, so it has clear business and less code. It is relatively simple to develop and maintain a single microservice. The entire application is built by several microservices, so the entire application will also be maintained in a controllable state.
A single microservice starts faster: a single microservice has a small amount of code, so it starts faster.
Partial modification is easy to deploy: As long as a single application is modified, the entire application has to be redeployed. Microservices solve this problem. Generally speaking, to modify a microservice, you only need to redeploy the service.
Unrestricted technology stack: In the microservice architecture, the technology stack can be selected reasonably according to the characteristics of the project business and team. For example, some services can use the relational database MySQL; some microservices have graph computing requirements, and Neo4j can be used; even as needed, some microservices can be developed using Java, and some microservices can be developed using Node.js.
Although microservices have many attractive places, they are not a free lunch, and there is a price to use it. Challenges in using microservice architecture.
Higher operation and maintenance requirements: more services mean more investment in operation and maintenance. In a monolithic architecture, only the normal operation of an application needs to be guaranteed. In microservices, it is necessary to ensure the normal operation and collaboration of dozens or even hundreds of services, which brings great challenges to operation and maintenance.
The inherent complexity of distributed: the use of microservices to build a distributed system. For a distributed system, system fault tolerance, network delay, distributed transactions, etc. will bring huge challenges.
Interface adjustment costs are high: microservices communicate through interfaces. If you modify the API of a certain microservice, all microservices that use the interface may need to be adjusted.
Duplicated work: Many services may use the same function, but this function does not reach the level of decomposition into a microservice. At this time, each service may develop this function, which leads to code duplication. Although you can use shared libraries to solve this problem (for example, you can encapsulate this function into a common component, and the microservices that need this function refer to the component), the shared library may not work in a multilingual environment.
In addition, pay attention to the Java technology stack of the official account, and reply in the background: Interview, I can get the Java distributed, microservice series of interview questions and answers I have compiled, which is very complete.
4. Serverless architecture
While we are still advancing in the container wave, some revolutionary pioneers have quietly laid out another cloud computing battlefield: Serverless architecture.
Serverless architecture
On November 14, 2014, Amazon AWS released a new product Lambda. At that time, Lambda was described as: a computing service that runs the user's code according to time without worrying about the underlying computing resources. In a sense, Lambda is long overdue, it is like the PaaS concept of cloud computing: customers only care about the business, without worrying about storage and computing resources. Not long before, on October 22, 2014, Google acquired Firebase, a real-time back-end database startup. Firebase claims that developers only need to refer to an API library file to read and write data using various interfaces of the standard REST API. They only need to write HTML+CSS+JavaScrip front-end code, without server-side code (if integration is required, it is extremely simple).
In contrast to the above two, Parse, which Facebook acquired in February 2014, focuses on providing a common back-end service. These services are called serverless or no sever. Think of PaaS (Platform as a Service), right? Much like, users don’t need to care about infrastructure, they only need to care about business. This is a late PaaS and a more practical PaaS. This is likely to change the entire development process and the traditional application life cycle. Once developers get used to this fully automatic creation and allocation of resources on the cloud, they may never get back to those who need micro-application configuration resources. The times are gone.
The Serverless architecture allows developers to avoid the need to pay attention to the acquisition and operation of computing resources in the process of building applications. The platform allocates computing resources on demand and guarantees the SLA (service level agreement) for application execution, and billing is based on the number of calls, which is effective Save application costs. The architecture of ServerLess is shown in the figure above. The advantages are as follows:
Low operating costs: In a scenario with extremely high business emergencies, in order to cope with business peaks, the system must build a system that can cope with peak demand. This system is idle most of the time, which leads to serious waste of resources and costs rise. In the microservice architecture, the service needs to run all the time. In fact, under high load conditions, each service has more than one instance, so that high availability can be achieved; under the serverless architecture, the service will be billed according to the number of calls made by the user, according to the cloud Calculate the pay-as-you-go principle, if nothing is running, you don’t have to pay, saving usage costs. At the same time, users can effectively respond to business peaks by sharing computing resources such as networks, hard drives, and CPUs, and through flexible expansion during peak business periods, and sharing resources with other users during business peak periods, effectively saving costs.
Simplify equipment operation and maintenance: In the original IT system, the development team needs to maintain applications and hardware infrastructure at the same time; in the serverless architecture, developers will face third-party development or custom APIs and URLs. The underlying hardware is transparent to developers, and the technical team no longer needs to focus on operation and maintenance work, and can focus more on application system development.
Improve maintainability: In the serverless architecture, applications will call a variety of third-party functional services to form the final application logic. At present, third-party services such as login authentication services and cloud database services have been greatly optimized in terms of security, availability, and performance. The development team directly integrates third-party services, which can effectively reduce development costs and enable application operations. The maintenance process has become clearer, effectively improving the maintainability of the application.
Faster development speed: This is now well reflected in Internet startups. Startups often start due to personnel and capital issues, and it is impossible for each product line to proceed at the same time. At this time, third-party Baas platforms can be considered , Such as the use of WeChat user authentication, RDS provided by Alibaba Cloud, Aurora’s message push, third-party payment and geographic location, etc., can quickly develop products, focus on business realization, and make products faster To the market.
But ServerLess architecture also has its disadvantages:
Vendor platform binding: The platform will provide serverless architecture for big players, such as AWS Lambda. To run it, you need to use services specified by AWS, such as API gateway, DynamoDB, S3, etc. Once you develop a complex system on these services, you will Sticking to AWS will have to allow them to increase prices or remove them from the shelves in the future. It is difficult to meet individual needs, and it is impossible to perform random migration or the cost of migration is relatively high, and it will inevitably bring some losses. A typical incident in the Baas industry, on January 19, 2016, Facebook shut down Parse, which used to spend a huge amount of money to acquire Parse, causing users to have to migrate to this platform to generate more than a year of data, which undoubtedly requires a lot of manpower and time. cost.
There are relatively few successful cases and no industry standards: the current situation is only suitable for simple application development and lacks the promotion of large-scale successful cases. The lack of a unified understanding and corresponding standards for Serverless makes it impossible to adapt to all cloud platforms.
At present, the microservice architecture is in the mainstream of the four architectures, and many enterprises that use the first and second architectures have also begun to slowly turn to the microservice architecture. So far, the technology of microservices is relatively mature compared to two or three years ago, and the fourth architecture will be a trend of future development.
Reference: "2020 latest Java basics and detailed video tutorials and learning routes! 》
Original link: https://zhuanlan.zhihu.com/p/343457113