Internet architecture development history
introduction
Since the development of the Internet, it has experienced monolithic architecture, vertical architecture, SOA, finally microservices, and recently popular server mesh and faas.
1 Monolithic architecture
1.1 Architectural thinking
All business modules are integrated into one application. At most, a war package, or even a war package as a whole, is used to publish the project. In actual deployment, horizontal scaling can be achieved through distributed shared sessions.
1.2 Advantages and disadvantages
advantage:
- The structure is simple, the initial cost is low, and it is suitable for small projects;
Disadvantages:
- For large-scale projects, there will be constraints on team collaboration without business separation;
- For large projects, the entire project needs to be developed before it can be released. No continuous integration;
- Due to tight coupling and later functional modification, the entire project needs to be tested. It can be published.
2 Vertical architecture
2.1 Architecture ideas
Aiming at the problem of monolithic architecture, in the vertical architecture, the system is divided into high-level business; and then sub-systems are separated; each subsystem is developed according to the monolithic architecture model.
2.2 Advantages and disadvantages
advantage:
- To a certain extent, the coupling problem of each module in the monolithic architecture is solved;
Disadvantages:
- Business splitting is crude and violent, and each subsystem has data and function redundancy;
- Since the subsystems are simply divided, there are many synchronization and consistency problems;
- Due to the close dependence of each subsystem, it is still unable to meet the continuous delivery of large projects.
3 SOA
3.1 Architectural thinking
SOA is a service-oriented architecture idea. Compared with the vertical architecture, it emphasizes the division of services as a unit to achieve reusability. In SOA, service is the core abstract means, and business is divided into some coarse-grained business services and business processes. The access between services is through ESB (Enterprise Service Bus), which isolates service providers and service consumers. Therefore, SOA only needs to solve the following problems:
- Information island
- interconnection
- Business reuse
- Heterogeneous integration
3.2 Advantages and disadvantages
advantage:
- Solve the problem of business reuse, avoid duplication of work, and improve efficiency;
- ESB is responsible for bridging each service, reducing the coupling between services and facilitating independent development
Disadvantages:
- The ESB standard is not uniform, resulting in ecological incompatibility, which is not conducive to the technical upgrade of the later infrastructure;
- Whether it is SCA (ESB is one of its implementation methods) or JBI, it is advocating the use of a unified technology platform to solve the entire project problem, which is not conducive to special technology selection for special sub-businesses;
- Although each service is isolated, it needs to be tightly coupled with the ESB.
4 microservices
4.1 Architecture ideas
Microservices are a refinement of traditional SOA, so some people say: Microservice architecture = 80% SOA service architecture ideas + 100% component architecture ideas + 80% domain modeling ideas. Compared with SOA, microservices emphasize fine-grained splitting , service autonomy , decentralization , and lightweight API . First, it requires all services to be reasonably fine-grained split based on the business; service split determines the division of teams, and each team decides its own technology selection; each service is no longer tied to the ESB and is independent, and service access is passed The service gateway is connected, and the service provider is independent of the gateway; the service provides a lightweight API to the outside, generally using HTTP as the carrier and restful as the design standard to provide services to the outside, because in various systems and languages, the HTTP ecological support is relatively the most robust of.
4.1.1 Design principles
AKF split principle
- Each service can be deployed on multiple nodes, making a cluster plus load balancing model. That is, horizontal expansion;
- Based on business splitting, each business is autonomous. That is vertical expansion;
- When the number of users surges, it can support data partitioning and fragmentation isolation. That is, data partition;
Service autonomy and exclusive resources
- Each service has its own independent design, development, testing, and release cycle;
- After the service is online, resources such as operation, caching, and persistence are all independent;
Restful communication style
- The API style is based on restful. Keep it simple and popular;
Front and rear separation
- The front-end access layer (including web, app, etc.) must be independent of each other, and cannot be a hodgepodge;
- The backend only provides standard APIs and is separated from the frontend. That is to say, the basic service is not coupled with the presentation layer;
Stateless service
- It needs to be designed as stateless delivery as much as possible, which is conducive to horizontal deployment;
- If the session data cannot be avoided, it needs to be migrated to the distributed cache;
4.2 Advantages and disadvantages
advantage:
- Each business module is autonomous. Independent technology selection, independent development, independent testing, etc., conducive to continuous integration;
- Abandoning the constraints of ESB is more conducive to the later technical upgrade of a small module; it is also conducive to special technical selection;
- Fine-grained splitting of services increases reusability in function iterations;
Disadvantages:
- Service split is too fine, resulting in too many network transfers, affecting efficiency;
- Too many services lead to high system operation complexity, which in turn increases the complexity of operation and maintenance;
- Service governance and business coupling;