1. Introduction

Architectural style describes components that contain various architectural characteristics. It is essential for the children of advanced architectural design to be familiar with various architectural styles in the face of various complex requirements. Such as the characteristics of these architectural styles, deployment models, data policies, and so on. Architectural style main can be divided into single and two kinds of distributed architecture, the difference between the two is the code deployment and operation mode as the key differentiator, including monomer architecture is to pack all the code in a unit to deploy and run, and distributed architecture is put the code on the multiple deployment units, through the remote access protocol to connect to. Typical individual architectures include layered architecture, pipeline architecture, microkernel architecture, etc., while typical distributed architectures include service-based architecture, event-driven architecture, space-based architecture, service-oriented architecture, microservice architecture, etc.

2. Common architectural styles

2.1 Layered Architecture

Layered architecture is a typical single architecture. It is simple, efficient and low-cost. Each component is organized as a logical level of hierarchy, and each hierarchy plays a specific role in the architecture. There are three common deployment modes:

  • The presentation layer, business layer and persistence layer constitute a deployment unit, and the database layer is deployed separately

  • The presentation layer, business layer, and persistence layer, and the data layer are separate deployment units

  • The four layers form a deployment unit

Each of these layers has specific roles and responsibilities within the architecture, such as the presentation layer, which handles all user interface and browser communication logic, the business layer, which executes specific business rules associated with requests, and the data layer, which handles storage and transactions. This separation of concerns later in the layered architecture makes it easy to build effective role and responsibility models in the architecture, and components in a particular layer only deal with business logic, which can also be useful for technology stacks or component upgrades in that layer.

Each layer in a layered architecture can be either closed or open. Closed means that when a request passes from top to bottom from one layer to another, the request cannot skip any layer, but must go through the layer below it to reach the next layer. For example, a request from the presentation layer must first go through the business layer, then to the persistence layer, and finally to the database layer. Hierarchical isolation means that changes made in one layer of the architecture do not affect components in other layers.

Layered architecture is a good choice for small applications, applications, websites, and for situations where time and cost are tight. Layered architecture is a simple, common, low-cost architectural style that can improve the development efficiency of small applications. But as applications evolve, maintainability, agility, testability, and deployability decrease dramatically, and larger applications and systems that use layered architectures may be better suited to other modular architectural styles.

2.2 Pipeline Architecture

Pipeline architecture styles are common in data-processing related application styles, where there are four types of filters in pipeline architecture:

  • Producer: the starting point of a process, only for output;

  • Converter: Receives input, selectively converts some or all of the data, and then forwards it to an output pipeline;

  • Tester: receives input, tests one or more conditions, and selectively generates output based on the tests;

  • Consumer: End point of pipeline flow. Consumers sometimes save the end result of pipeline processing to a database or reality the end result in the user interface.

Pipeline architecture patterns are common in ETL tools (extract/transform/load) for data flow and modification from one database or data source to another. The following figure uses a pipeline architecture to process the different types of Kafaka data. The service Information capture subscribes to the Kafafa topic to receive the service information, and then sends the captured data to a duration test filter to determine whether the data captured from Kafaka is related to the duration of the service request. The service metric capture filter is only concerned with how to connect to the Kafaka topic and receive stream data, while the duration filter is only concerned with how to qualify the data and selectively forward it to the next pipe. If the data is related to the duration of the service request, the duration filter passes the data to the duration calculator. Because the pipeline architecture is deployed singleton, elasticity and scalability are very low.

Pipe-based architectures are monolithic in nature and do not have the complexity of distributed architectures, making them simpler to understand and less costly to build/maintain, enabling architectural modularization by separating concerns between various filters and converters. This architectural style is not very fault-tolerant overall, and may affect the entire application unit because a small number of elements appear.

2.3 Microkernel architecture

Microkernel architecture is mainly composed of core system and plug-in component. Logic can be divided into independent plug-in component and basic core system, providing good scalability, adaptability, and isolation of program characteristics and custom processing logic.

In our frequent use of VIM editor is a good example, the core system is just a text editor: open file -> edit file -> save file, developers can add a lot of plug-ins, such as navigation bar, menu, color and other plug-ins, make VIM more cool. The core system can also be understood as a common process without customization, thus eliminating the complexity of the core system, achieving better scalability and maintainability by plugging and removing components, and enhancing testability.

Microkernel architecture has the advantages of simplicity, low overall cost, testability, deployability and good reliability, especially the isolation of plug-in components, which can reduce the overall test scope and deployment cost. However, the scalability, fault tolerance and scalability of the architecture are low, mainly because the microkernel architecture is a single application architecture.

2.4 Service-based Architecture

Service-oriented architecture is a mixture of micro service architecture style, has the very good flexibility, is considered to be one of the most practical architectural style, although the architecture is a kind of distributed architecture based on service, but it does not have the complexity of distributed architecture and other costs, makes it a business related applications.

Domain services in a service-based architecture are coarse-grained, so each domain service is typically designed in a utility layered architecture style consisting of an API layer, a business logic layer, a persistence layer, and a utility subdomain similar to the modular overall architecture style that partitions each domain service.

No matter how the service is designed, the domain service must contain an API layer to interact with users and perform business functions. Domain services are coarse-grained, where multiple components may be shared databases, and integrity in a domain service can be ensured through commit and rollback through regular ACID database transactions, but ultimate consistency can only be achieved through BASE distributed transactions in a microservice architecture. Therefore, the same level of database integrity as ACID transactions is not supported in a service-based architecture.

Under this kind of architectural style, will be separate application into deployment domain services, to achieve faster change (agility), better test coverage, less risk, bring more frequently update deployment, these features make the enterprise can take market as early as possible, and at a relatively high speed delivery features and fix defects. Service-oriented architecture, fault tolerance is very high and the overall application availability, under this kind of architectural style, usually one of the service is down, will not affect the other services, can achieve the scalability and flexibility on the project implementation, but compared to the more granular micro service, function of repeat degree is higher, so the machine utilization rate is not high, the overall cost efficiency is not high also.

2.5 Event-driven architecture style

Event-driven architecture is a popular distributed heterogeneous architectural style for building highly scalable and high-performance applications that are adaptable to small applications as well as large, complex ones. Event-driven architectures consist of decouple event processing components that asynchronously take over and process events and can be used independently of architectural styles or embedded into other architectural styles.

        

There are two implementations in event-driven architecture: mediation and broker. Broker is the most common, such as RocketMQ/RabbitMQd distributed messaging middleware, which has initial event, event broker, event handler, and event components to be processed.

        

Take the order processing flow as shown in the figure below. Here all event handlers are highly decoupled and independent of each other, agent topology can be understood as a relay race, processing after a certain event, no longer involved in the specific event processing, and can be for other initial or pending events to respond, each event handler can independently adjustable, If a processor becomes faulty or slow during service processing, the entire service process is affected.

Event mediation addresses some of the shortcomings of the broker topology, such as workflow control, processing error handling, recoverability, event task restart, data inconsistency, etc., mainly represented by Apache Camel, ESB and other frameworks.

Often occurs in event-driven architecture data loss, you can use a variety of technical assurance, message persistent storage in the physical data storage (such as file system or database), if the message broker goes down, will be physically stored in the disk, the synchronous execution obstruction in news production waiting, until the agency confirmation message is persistence, With these two basic techniques, messages between producers and queues are never lost.

Event-driven architectures respond to requests asynchronously, but some scenarios require asynchronous transfer to “synchronous” to make it feel like a synchronous request. A common way to achieve synchronous request-reply messaging is to include the association ID in the message header. The principle of this technology is as follows:

  • The event producer sends a message to the request queue and records a unique message ID;

  • The event producer uses a filter to perform a blocking wait on the reply queue, where the association ID in the message header is equal to the original message ID(35),

  • The event receiver receives the message (ID 35) and processes the request;

  • The event receiver creates the reply request and sets the correlation ID(CID) in the message header to the original message ID(35);

  • The event producer receives the message (ID 90), and the association ID(CID)35 matches that in Step 2.

Based on the event-driven architecture is a kind of architecture based on the technology to distinguish, in more than one event handler through events mediation/agent, queues and topics binding together, on the high performance, scalability, fault tolerance performance is very good, through the combined with highly parallel processing implementation architecture of high performance, highly scalable by the event handler can control the load balance, Fault tolerance is through highly decoupled and asynchronous event handler, the flow of events has been provided for the processor eventual consistency and final treatment, but the architectural style also has low testability shortcomings, mainly due to the often uncertainty in architecture and dynamic flow of events, and under the asynchronous processing scene debugging is very difficult.

2.6 Service-oriented Architecture

Service-oriented architecture (SOA) is a distributed architecture with no definite boundaries, with enterprise-level reuse as the ultimate goal of the architecture, and the style of the architecture changes from organization to organization in the enterprise. The following figure illustrates the topology of a typical service-oriented architecture, with specific layers and service classifications established within the architecture. Each layer has specific responsibilities, including business services/enterprise service Bus/enterprise services/application services/infrastructure services, etc.

  • Business services: These services are defined with no code, only inputs and outputs, and are usually defined by business users, hence the name business services;

  • Enterprise services: Atomic behavior built around specific business domains that are components of coarse-grained business services, usually bound together through orchestration engine integration;

  • Application services: Are one-off, single services that may require a location within an application, usually solved by the application services team;

  • Infrastructure services: Provides operations and maintenance concerns such as monitoring, logging, authentication, and authorization, and is the responsibility of the shared facilities services team closely related to operations and maintenance.

  • Orchestration engine: The orchestration engine includes functions such as transaction coordination and message transformation to group business service implementations together. This architecture is usually bound to one or several relational databases, rather than one database per service as in microservice architectures. The behavior of transactions is handled declaratively in the orchestration engine.

Service-oriented architectures are flexible and extensible, but because the whole is a large set of services, changes to one place may affect multiple services, so the architecture is not deployable and testable.

2.7 Microservices Architecture

Microservices architecture is a popular distributed architecture style. Each microservice entity model is completely decoupled from the database, and each service runs in its own process.

In the traditional service-oriented architecture, system operation and maintenance functions such as monitoring, logging and circuit breakers are reused as much as possible. In the microservice architecture, the same concept is followed. In order to maximize reuse, the sidecard mode is developed as shown in the figure below. Common operations concerns appear as separate components that can be owned by a single team or infrastructure team, and each microservice can use this new capability when updating the sidecar.

When each service uses a sidecar component, a network of services can be built, allowing unified control of the architecture to address issues such as logging and monitoring. When common sidings are connected together, a consistent o&M interface is formed across all microservices. This service plane provides a consistent interface to the services, allowing development or operations personnel to access the services as a whole.

Micro service architecture is a kind of centering on the domain architecture, each service corresponding to the boundary and domain, at the same time is a kind of scalability, high flexibility and have better evolution of architectural style, but the architecture is heavily dependent on the automation and intelligent integrated operations, in a request in the service architecture are require multiple calls to complete, can lead to high performance overhead,

3. Architectural decisions

The above introduces the current mainstream common architectural styles, usually in the selection of architecture also need to consider some overall factors such as business domain specific and corresponding characteristics, data architecture, organizational factors, development collaboration and so on.

4. Summary

This article is a summary of some architectural design related knowledge in the complex business field. An application will use one or more of these architectural features, and choosing the right architectural style will get you more bang for your ass.