This is the seventh day of my participation in the First Challenge 2022. For details: First Challenge 2022.

primers

Software architecture has been evolving and developing from the original single architecture, to the vertical architecture, to the SOA architecture, and now the popular microservice architecture. Evolutionary processes are essentially constantly meeting increasingly complex business requirements, which is why I prefer to call them “business architectures.”

Each architecture evolution is based on the features of the original architecture combined with the actual business scenarios, but this does not mean that the newer architecture is better, each architecture has its own applicable scenarios.

1 Single Architecture

Unit architecture, is all the functions in a project.

For small projects, single architecture has unique advantages, such as simple development and deployment, low cost, short cycle and high efficiency. Even in today’s microservice architecture, single architecture is still very suitable for small projects.

However, with the continuous increase of business functions, the single architecture of the project will become more and more large, bloated, development, operation and maintenance of all kinds of work will bring not a small negative impact: the project is large, more documents, if there is no strong development norms and constraints, the project will inevitably chaos; The project takes longer to compile and start, and the IDE may even lag when the work computer is not properly configured. The risk of fully replacing a project in a production environment (especially if it hasn’t been updated for a long time) is incalculable.

Monolithic architecture as a whole, compared with SOA architecture, microservices architecture such as split architecture, there are two obvious disadvantages: monolithic architecture has the risk of a bug to drag down the entire system; The hardware of a single architecture cannot be extended for a certain type of peak services, but can be extended as a whole.

2 Vertical Architecture

Vertical architecture, in fact, is to separate the original single architecture project into multiple projects according to the business characteristics. The principle of service separation should be that services can run independently without affecting each other.

The projects separated by the vertical architecture are reduced in size, but are still monolithic in nature, with inherent advantages and disadvantages of monolithic architecture.

The vertical architecture controls the volume of the project and distributes the flow of the original system into multiple subsystems, which can be individually extended. At the same time, vertical architecture brings new problems:

• Part of the function of the overlap, that is, we often say “repeat wheel”.

• Data redundancy, for example, any system needs user information, and these data often need to be synchronized, mainly by means of database level synchronization, such as Oracle DataGuard, sometimes can be directly solved through DBLink, Synonym, View, etc. Of course, there are also synchronous processing through the interface between systems.

• To avoid increasingly inescapable interactions between systems (the breaking of information silos), a system needs interfaces that integrate and interconnect with many different systems.

As a side note, from a theoretical architectural perspective, vertical architectures are the result of the fragmentation of individual architectures that are too large. Interestingly, in practice there are scenarios where, from a commercial project point of view, a large system is submitted for bidding and is already planned for multiple subsystems, which are awarded by different vendors, naturally forming a vertical architecture model.

3 the SOA architecture

Service-oriented Architecture (SOA) is a service-oriented Architecture.

Service-oriented Architecture (SOA) is a component model that separates different functional units of an application, called services, and connects them through well-defined interfaces and protocols. Interfaces are defined in a neutral manner and should be independent of the hardware platform, operating system, and programming language that implements the service. This allows services built on a variety of systems to interact in a unified and common way.

This concept is somewhat difficult to understand, and we can understand what SOA architecture does from the lack of vertical architecture.

SOA solves the problem of duplicate wheels by separating overlapping functions as common services on the basis of a vertical architecture. The separated systems or services use an Enterprise Service Bus (ESB) to implement standardized and unified information exchange and solve the problem of chaotic invocation.

Compared with vertical architecture, SOA has a clearer separation of services, a single responsibility for common component services, and high scalability. It is no longer forced to break through the barrier of the database level, so that the data is back to the isolation state, and the problem of isolated information is solved by the interface, which improves the security of the system. The ESB transforms the original point-to-point interaction pattern into a bus-integrated interaction pattern, reducing the coupling between systems and reducing the difficulty and cost of integrating with each other.

Every coin has two sides. Service extraction solves the problem of re-creating wheels, but is it really important for systems to be able to reuse wheels? Are you willing to pay the price? The extraction of wheels makes the system and service highly coupled; With the performance cost of mediating interactions through an ESB, and all the information between systems being delivered through the ESB, the ESB clearly becomes a bottleneck within the entire system, and when the ESB goes down, all systems suffer.

SOA requires enterprises to make both technical and business changes, yet it is difficult for them to see enough benefits. As a result, SOA has not been well promoted in the enterprise.

4 Microservice architecture

In the age when the Internet has been quite mature, the Internet business volume is increasing rapidly and changes very frequently. The Internet technology team pays close attention to topics such as agile development, continuous delivery, system elastic expansion and resource utilization optimization. In such conditions, the micro-service architecture has achieved good practical effects.

Microservices architecture breaks down a single application into a set of small services, each built around business capabilities that can be independently developed, tested, and deployed, using a lightweight communication mechanism between services.

Aside from the ESB, does microservice architecture feel a bit like SOA? We can think of microservices as a subset of SOA, which can be said to be a more granular implementation of SOA that better meets the needs of the current Internet. Finer granularity facilitates resource reuse and precise scaling, and lighter communication protocols between services provide better support for DevOps. Compared to SOA, the success of microservices is not only due to the architecture itself matching business pain points, but also due to the maturity of the entire Internet environment and supporting tool chains (such as cloud, container, etc.), resulting in the best practices of microservices architecture.

Don’t underestimate the complexity of microservices architecture! Microservice architecture has inherent complexity of distributed architecture, such as communication between services and possible distributed transaction problems. A micro service application deployment and operations is quite troublesome, you first need to cache, message, reverse proxy, monitoring platform, registry and so on the support of middleware, followed by a large number of application examples of planning and deployment, at the same time produce plenty of configuration information needed to manage, mature deployment operations need to seek the solution of highly automated; In the microservice system, the service invocation relationship is complex, which greatly increases the difficulty of troubleshooting and locating problems.