Software architecture is the basic structure of software.
Proper architecture is one of the most important factors for software success. Large software companies usually have a dedicated architect position (architect), only senior programmers can fill.
O'Reilly has published a free booklet , Software Architecture Patterns ( PDF ), which introduces the five most common software architectures and is a great primer. I benefited a lot from reading it, and the following are my notes.
1. Layered Architecture
Layered architecture is the most common software architecture and the de facto standard architecture. If you don't know what architecture to use, use it.
This architecture divides the software into several horizontal layers, each layer has a clear role and division of labor, and does not need to know the details of other layers. Layers communicate with each other through interfaces.
Although there is no clear agreement on how many layers the software must be divided into, the four-layer structure is the most common.
- Presentation: User interface, responsible for visual and user interaction
- Business layer (business): implement business logic
- Persistence layer (persistence): provide data, SQL statements are placed in this layer
- database (database): save data
Some software adds a service layer (service) between the logic layer and the persistence layer to provide some common interfaces required by different business logics.
The user's request will be processed through these four layers in turn, and any one of them cannot be skipped.
advantage
- Simple structure, easy to understand and develop
- Programmers with different skills can divide labor and be responsible for different layers, which is naturally suitable for the organizational structure of most software companies
- Each layer can be tested independently, and the interfaces of other layers can be solved by simulation
shortcoming
- Once the environment changes, it is usually cumbersome and time-consuming when code adjustment or function addition is required
- Deployment is cumbersome. Even if only a small place is modified, the entire software often needs to be redeployed, and it is not easy to do continuous release.
- During software upgrades, the entire service may be suspended
- Poor scalability. When a large number of user requests increase, each layer must be expanded in turn. Since each layer is internally coupled, it will be difficult to expand
2. Event-driven architecture
An event is a notification from the software when the state changes.
An event-driven architecture is a software architecture that communicates through events. It is divided into four parts.
- Event queue (event queue): the entrance to receive events
- Distributor (event mediator): Distribute different events to different business logic units
- Event channel: The communication channel between the dispatcher and the processor
- Event processor: implements business logic, and emits events after processing to trigger the next operation
For simple projects, event queues, dispatchers and event channels can be integrated into one, and the entire software is divided into event agents and event handlers.
advantage
- Distributed asynchronous architecture, highly decoupled between event processors, and good software scalability
- Wide applicability, various types of projects can be used
- Better performance, because of the asynchronous nature of events, the software is not prone to blockage
- Event handlers can be loaded and unloaded independently for easy deployment
shortcoming
- Involves asynchronous programming (to consider remote communication, loss of response, etc.), the development is relatively complex
- Difficult to support atomic operations, because the event pass involves multiple processors and it is difficult to roll back
- Distributed and asynchronous nature makes this architecture difficult to test
3. Microkernel Architecture
Microkernel architecture, also known as "plug-in architecture", refers to the relatively small core of the software, and the main functions and business logic are implemented through plug-ins.
The kernel (core) usually contains only the minimum functionality for the system to run. Plug-ins are independent of each other, and the communication between plug-ins should be minimized to avoid the problem of interdependence.
advantage
- Good function extensibility (extensibility), what function is needed, just develop a plug-in
- Functions are isolated, plugins can be loaded and unloaded independently, making it easier to deploy,
- High customizability to meet different development needs
- Can be developed incrementally, gradually adding features
shortcoming
- Poor scalability, the kernel is usually an independent unit, and it is not easy to make distributed
- The development difficulty is relatively high, because it involves the communication between the plug-in and the kernel, and the internal plug-in registration mechanism
4. Microservice Architecture
Microservices architecture is an upgrade of service-oriented architecture (SOA).
Each service is a separate deployed unit. These units are distributed, decoupled from each other, and connected through remote communication protocols (such as REST, SOAP).
The microservice architecture is divided into three implementation modes.
- RESTful API pattern: services are provided through APIs, cloud services fall into this category
- RESTful application mode: services are provided through traditional network protocols or application protocols, and behind them is usually a multi-functional application, which is often used in enterprises
- Centralized message mode: using message broker, can realize message queue, load balancing, unified log and exception handling, the disadvantage is that there will be a single point of failure, and the message broker may be clustered
advantage
- Good scalability and low coupling between services
- Easy to deploy, the software is split from a single deployable unit into multiple services, each of which is a deployable unit
- Easy to develop, each component can be developed continuously, can be deployed in real time, and upgraded continuously
- Easy to test, each service can be tested individually
shortcoming
- Due to the emphasis on mutual independence and low coupling, services may be split very finely. This results in a system that relies on a large number of microservices, becomes messy and bulky, and performs poorly.
- Once services need to communicate (i.e. one service uses another service), the whole architecture becomes complicated. A typical example is some generic Utility classes. One solution is to copy them into each service and trade redundancy for architectural simplicity.
- The distributed nature makes it difficult to achieve atomic operations in this architecture, and transaction rollback will be more difficult.
5. Cloud Architecture
Cloud architecture mainly solves the problems of scalability and concurrency, and is the easiest architecture to expand.
The main reason for its high scalability is that it does not use a central database, but instead copies all data into memory to become a replicable memory data unit. Then, the business processing capabilities are encapsulated into processing units. When the access volume increases, a new processing unit is created; when the access volume decreases, the processing unit is closed. Since there is no central database, the biggest bottleneck to scalability disappears. Since the data of each processing unit is in memory, it is best to perform data persistence.
This model is mainly divided into two parts: processing unit (processing unit) and virtual middleware (virtualized middleware).
- Processing unit: implement business logic
- Virtual middleware: responsible for communication, maintaining sessions, data replication, distributed processing, and deployment of processing units.
Virtual middleware contains four more components.
- Messaging Grid: Manage user requests and sessions, and decide which processing unit to assign to when a request comes in.
- Data middleware (Data Grid): Copy data to each processing unit, that is, data synchronization. It is guaranteed that a certain processing unit all gets the same data.
- Processing Grid: Optional, if a request involves different types of processing units, the middleware is responsible for coordinating the processing units
- Deployment middleware (Deployment Manager): Responsible for the startup and shutdown of processing units, monitoring load and response time, when the load increases, the processing unit is newly started, and when the load decreases, the processing unit is shut down.
advantage
- High load, high scalability
- Dynamic deployment
shortcoming
- Complex implementation and high cost
- Mainly suitable for website applications, not suitable for large database applications with large data throughput
- harder to test
(over)