Writing in the front

With the development of the Internet, the business of Internet enterprises is also developing rapidly, which leads to changes in the architecture of the system. Generally speaking, the architecture of the system has undergone the evolution of single application architecture > vertical application architecture > distributed architecture >SOA architecture > microservice architecture. Of course, the system architecture of many Internet enterprises has evolved into Service Mesh. Today, we are going to talk about the evolution of system architecture.

Single application architecture

In the early stage of enterprise development, the website traffic of general companies is relatively small, and only one application is needed. All the functional codes are packaged into a service and deployed to the server to support the company’s business. This also reduces development, deployment, and maintenance costs.

For example, we are familiar with the e-commerce system, which involves mainly: user management, commodity management, order management, payment management, inventory management, logistics management and other modules, we will write all modules in a Web project at the beginning, and then unified deployment to a Web server.

This architectural feature has its advantages:

  • Simple architecture, low cost of project development and maintenance.
  • All project modules are deployed together, which is easy to maintain for small projects.

However, its disadvantages are also quite obvious:

  • All modules are coupled together, although easy to maintain for small projects. However, for large projects, it is not easy to develop and maintain.
  • The modules of the project were so coupled that if one module failed, the whole project would become unusable.
  • Performance cannot be improved for a specific module.
  • Unable to scale the project horizontally.

It is because of the shortcomings of single application architecture that it gradually evolves into vertical application architecture. Next, let’s look at vertical application architectures.

Vertical application Architecture

As enterprise services grow, single applications on a node cannot support service development. Therefore, enterprises deploy multiple applications on different servers. However, at this point, you will find that not all modules will have a large number of visits. If you want to optimize and improve performance for certain modules in a project, you can’t do that for a single application. Hence, the vertical application architecture was born.

Vertical application architecture is to split the original application of a project into several applications that do not want to work with each other to improve the overall performance of the system.

Here, we also take the e-commerce system as an example. Under the vertical application architecture, we can divide the whole e-commerce project into e-commerce transaction system, background management system, CMS management system and so on.

Once we split the monolithic application architecture into vertical applications, once the volume of access increases, we can only add server nodes for the high-traffic business, rather than for the entire project.

Advantages of this architecture:

  • The system has been split, according to the access of different systems, targeted optimization.
  • Horizontal extension of applications can be achieved.
  • Each system can share the overall access traffic to solve the concurrency problem.
  • Failure of one system does not apply to the operation of other systems, improving the overall fault tolerance rate.

Disadvantages of this architecture:

  • After splitting, each system is relatively independent and cannot call each other.
  • Each system inevitably has overlapping business, there will be repeated development of business, later maintenance is difficult.

Distributed architecture

As we evolve the system into a vertical application architecture, as more and more vertical applications are applied, more and more business code is written repeatedly. At this point, we need to abstract out the repeated code to form a unified service for other systems or business modules to call. At this point, the system evolves into a distributed architecture.

In a distributed architecture, we split the system into a service layer and a presentation layer. The service layer encapsulates the specific business logic that is invoked by the presentation layer, which handles the interaction with the page.

Advantages of this architecture:

  • The repetitive business code is abstracted to form a common access service, which improves code reusability.
  • You can optimize system and service performance to improve overall access performance.

Disadvantages of this architecture:

The coupling degree between systems becomes high, and the call relationship becomes complex and difficult to maintain.

SOA architecture

In distributed architecture, as more and more services are deployed, there will be more and more duplicate code, and there will be serious problems such as capacity evaluation and waste of small service resources. At this point, we need to add a unified scheduling center to manage the cluster in real time. At this point, the system evolves into an SOA (service-oriented) architecture.

Advantages of this architecture:

The use of registries solves the automatic registration and discovery of service dependencies and invocation relationships between services.

Disadvantages of this architecture:

  • There are dependencies between services, and if a service fails, it may cause an avalanche of services. (For more information about penetration, breakdown, and avalanche, please refer to my previous article: ).
  • The dependency and invocation relationship between services is complex, so it is difficult to test and deploy.

Microservices Architecture

As the business grew, we expanded on the SOA architecture, splitting it completely into a microservices architecture. Under the microservices architecture, we split a large project into small, independently deployable microservices, each with its own database.

Advantages of this architecture:

  • Services are completely separated, and each service is packaged, deployed, and upgraded independently.
  • Each microservice is responsible for a relatively clear business, facilitating later expansion and maintenance.
  • Microservices can communicate with each other using REST and RPC protocols.

Disadvantages of this architecture:

  • Development costs are high.
  • The fault tolerance of each service is involved.
  • It involves data consistency.
  • It involves distributed transactions (see my ongoing distributed transactions section).

Ok, today we stop here, I am the glacier, we will see you next time!!

Write in the last

If you think glacier wrote good, please search and pay attention to “glacier Technology” wechat public number, learn with glacier high concurrency, distributed, micro services, big data, Internet and cloud native technology, “glacier technology” wechat public number updated a large number of technical topics, each technical article is full of dry goods! Many readers have read the articles on the wechat public account of “Glacier Technology” and succeeded in job-hopping to big factories. There are also many readers to achieve a technological leap, become the company’s technical backbone! If you also want to like them to improve their ability to achieve a leap in technical ability, into the big factory, promotion and salary, then pay attention to the “Glacier Technology” wechat public account, update the super core technology every day dry goods, so that you no longer confused about how to improve technical ability!