If a software developer does not understand the evolution of software architecture, it will restrict the selection of technology and the survival and promotion space of developers. Here I list the four main software architectures and their advantages and disadvantages, hoping to help software developers expand their knowledge.
1、 Single structure
The single architecture is relatively elementary, typical three-level architecture, front-end (Web / mobile terminal) + intermediate business logic layer + database layer. This is a typical application of Java spring MVC or Python dragon framework. The frame composition is as follows:
The application of single architecture is relatively easy to deploy and test. At the beginning of the project, the single application can run well. However, with the increasing demand, more and more people join the development team, and the code base is also expanding rapidly. Gradually, the single application becomes more and more bloated, the maintainability and flexibility are gradually reduced, and the maintenance cost is higher and higher. The following are some disadvantages of single architecture application:
High complexity: take a single application with one million lines as an example, the whole project contains a lot of modules, the boundaries of modules are fuzzy, the dependency relationship is not clear, the code quality is uneven and disorderly piled together. It is conceivable that the whole project is very complicated. Every time you modify the code, you are scared. Even adding a simple function or modifying a bug will bring hidden defects.
Technical debt: as time goes on, requirements change and personnel change, the technical debt of the application will gradually form and accumulate. This is very common in software development, especially in single application. The used system design or code is difficult to modify because other modules in the application may use it in unexpected ways.
Low frequency of deployment: as the code increases, so does the time to build and deploy. In a single application, every function change or defect repair will lead to the need to re deploy the entire application. Full deployment takes a long time, has a wide range of influence and high risk, which makes the frequency of single application project online deployment low. The low frequency of deployment leads to a large number of functional changes and defect repair between the two releases, with a high error rate.
Poor reliability: an application bug, such as dead loop, memory overflow, may cause the whole application to crash.
Limited scalability: single application can only be expanded as a whole, and cannot be scaled according to the needs of business module. For example, some modules in the application are computationally intensive and need powerful CPU; some modules are IO intensive and need larger memory. Because these modules are deployed together, we have to compromise on the choice of hardware.
Hindering technological innovationSingle application often uses a unified technology platform or solution to solve all problems. Every member of the team must use the same development language and framework. It will be very difficult to introduce a new framework or technology platform.
2、 Distributed application
Intermediate architecture, distributed application, middle tier distributed + database distributed, is the concurrent extension of single architecture. A large system is divided into multiple business modules, which are deployed on different servers, and the data interaction between each business module is carried out through the interface.
Distributed databases are also widely used, such as redis, ES, solor, etc. Through LVS / nginx proxy application, user requests are balanced to different servers. The frame composition is as follows:
Compared with the single architecture, this architecture provides the ability of load balancing, greatly improves the system load capacity, and solves the demand of high concurrency of the website.
In addition, it has the following characteristics:
The coupling degree is reduced: split the modules and use the interface communication to reduce the coupling between modules.
Clear responsibilitiesThe project is divided into several subprojects, and different teams are responsible for different subprojects.
Easy to expand: when adding functions, you only need to add another sub project and call the interfaces of other systems.
Easy to deploy: flexible distributed deployment.
Improve the reusability of code: for example, the service layer, if we do not use the distributed rest service mode architecture, we will write a service layer logic at each end of WAP mall, wechat mall, PC, Android and IOS, which has a large amount of development and is difficult to maintain and upgrade together. At this time, we can use the distributed rest service mode and share a service layer.
Disadvantages:The interaction between systems needs to use remote communication, and the interface development increases the workload, but the advantages outweigh the disadvantages.
In addition, I will pay attention to the official account Java technology stack and reply in the background: interview can get my Java distributed series of interview questions and answers, which are very complete.
3、 Microservice architecture
Microservice architecture is mainly the middle layer decomposition, which splits the system into many small applications (microservices). Microservices can be deployed on different servers or on different containers of the same server. When the application failure will not affect other applications, the load of a single application will not affect other applications. The representative frameworks are spring cloud, Dubbo, etc.
The frame composition is as follows:
Easy to develop and maintain: a micro service only focuses on a specific business function, so it has clear business and less code. Developing and maintaining a single microservice is relatively simple. The whole application is constructed by several micro services, so the whole application will be maintained in a controllable state.
Single micro service starts faster: a single microservice has less code, so it starts faster.
Local modification is easy to deploy: as long as a single application is modified, the entire application has to be re deployed. Microservice solves this problem. Generally speaking, to modify a micro service, you only need to redeploy the service.
Unlimited technology stack: in the microservice architecture, the technology stack can be reasonably selected according to the characteristics of the project business and the team. For example, some services can use relational database mysql; some micro services can use neo4j for graphic computing; some micro services can even use Java for development and some micro services can use neo4j as needed Node.js development.
Although micro service has many attractions, it is not a free lunch. There is a price to use it. The challenges of using microservice architecture.
High operation and maintenance requirementsMore service means more operation and maintenance investment. In the single architecture, only one application needs to run normally. In micro services, it is necessary to ensure the normal operation and cooperation of dozens or even hundreds of services, which brings great challenges to the operation and maintenance.
The inherent complexity of distributed computingMicroservices are used to build distributed systems. For a distributed system, system fault tolerance, network delay and distributed transaction will bring great challenges.
High cost of interface adjustment: microservices communicate with each other through interfaces. If you modify the API of a microservice, all the microservices that use the interface may need to be adjusted.
Repetitive work: many services may use the same function, but this function does not reach the level of decomposition into a micro service. At this time, each service may develop this function, resulting in code duplication. Although the shared library can be used to solve this problem (for example, the function can be encapsulated as a common component, and the component needs to be referenced by the micro service of the function), the shared library may not work in a multilingual environment.
In addition, I will pay attention to the official account Java technology stack and reply in the background: interview can get my Java distributed, micro service series interview questions and answers, which are very complete.
4、 Serverless architecture
While we are still in the wave of containers, some revolutionary pioneers have quietly laid out another cloud computing battlefield: serverless architecture.
Compared with the above two, parse, which Facebook acquired in February 2014, focuses on providing a general background service. These services are called serverless or no sever. Think of PAAS, right? Much like this, users don’t need to care about infrastructure, they just need to care about business. This is a late PAAS and a more practical PAAS. This is likely to change the whole development process and the traditional application life cycle. Once developers get used to the automatic creation and allocation of resources on the cloud, they may never go back to the era of micro application configuration resources.
Serverless architecture enables developers to allocate computing resources on demand and ensure SLA (service level agreement) of application execution without paying attention to the acquisition and operation and maintenance of computing resources in the process of application construction, so as to effectively save application cost. The architecture of serverless is shown in the figure above. The advantages are as follows:
Low operating costs: in the scenario of high sudden business, in order to cope with the business peak, the system must be built to cope with the peak demand. This system is idle most of the time, which leads to a serious waste of resources and rising costs. In the microservice architecture, services need to run all the time. In fact, in the case of high load, each service has more than one instance, so as to achieve high availability. In the serverless architecture, services will be charged according to the number of calls of users. According to the pay as you go principle of cloud computing, if there is nothing to run, you do not have to pay, saving the cost of use. At the same time, users can share the network, hard disk, CPU and other computing resources, effectively cope with the business peak by elastic expansion in the business peak period, and share the resources to other users in the business trough period, which effectively saves the cost.
Simplify equipment operation and maintenance: in the original it system, the development team needs to maintain both the application and the hardware infrastructure; in the serverless architecture, the developers will face the API and URL developed or customized by the third party, the underlying hardware is transparent to the developers, the technical team no longer needs to pay attention to the operation and maintenance work, and can focus more on the application system development.
Improve maintainability: in the serverless architecture, the application program will call a variety of third-party function services to form the final application logic. At present, for example, login authentication service, cloud database service and other third-party services have been greatly optimized in terms of security, availability and performance. The development team directly integrates the third-party services, which can effectively reduce the development cost, make the operation and maintenance process of the application clearer, and effectively improve the maintainability of the application.
Faster development speed: This is well reflected in Internet start-ups now. Due to personnel and capital problems, it is impossible for start-ups to carry out each product line at the same time. At this time, we can consider the third-party baas platform, such as the user authentication of wechat, RDS provided by alicloud, Aurora’s message push, third-party payment and geographical location, etc., which can be used quickly The speed of product development, focus on business implementation, the product to the market faster.
However, the serverless architecture 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 the services specified by AWS, such as API gateway, dynamodb, S3 and so on. Once you develop a complex system on these services, you will stick to AWS, and then you have to let them increase their prices or take them off the shelves. It’s difficult to meet the personalized needs, and you can’t migrate at will, or the cost of migration is relatively high, which inevitably brings some losses . It’s a typical event in baas industry. On January 19, 2016, Facebook closed parse, which used to spend a huge amount of money to acquire. As a result, users have to migrate to this platform to generate more than one year’s data, which undoubtedly costs a lot of manpower and time.
There are few successful cases, and there is no industry standardThe current situation is only suitable for simple application development, lack of promotion of large successful cases. For the lack of a unified understanding of serverless and the corresponding standards, can not adapt to all cloud platforms.
At present, microservice architecture is in the mainstream among the four architectures, and many enterprises applying the first and second architectures are also slowly turning to microservice architecture.So far, the technology of microservice is more mature than two or three years ago. The fourth architecture will be a trend in the future.