1. Evolution of system architecture

With the development of the Internet, the scale of website applications is also constantly expanding, which leads to continuous changes in the system architecture. From the early days of the Internet to the present, the system architecture has roughly gone through the following processes:
Monolithic application architecture—>vertical application architecture—>distributed architecture—>SOA architecture—>microservice architecture—>Service Mesh (service grid) .

1.1 Monolithic Application Architecture

In the early days of the Internet, the traffic of general website applications was small, and all functional codes were deployed in one application, which could reduce the cost of development, deployment and maintenance.
For example, an e-commerce system will contain many modules such as user management, commodity management, order management, logistics management, etc. We will make them into a web project and deploy them on a tomcat server.

Advantages:
The project structure is simple, and for small projects, the development cost is low. The project is deployed on one node, which is easy to maintain.
Disadvantages:
All functions are integrated in one project. For large-scale projects, it is not easy to develop and maintain tight coupling between project modules. The single-point fault tolerance rate is low and it is impossible to optimize and horizontally expand different modules.

1.2 Vertical Application Architecture

As the number of visits gradually increases, a single application can only rely on adding nodes to deal with it, but at this time it will be found that not all modules will have relatively large visits, and the increase in user visits may only affect the user and order modules , but the impact on the message module is relatively small, so at this time we hope to only add a few more order modules instead of message modules. At this time, the single application is impossible, and the vertical application comes into being.
The so-called vertical application architecture is to split an original application into several independent applications to improve efficiency. For example, we can split the e-commerce single application above into:

E-commerce system (user management, product management, order management)
Background system (user management order management customer management)
CMS system (advertising management marketing management)

After the split is completed, once the number of user visits increases, it is only necessary to increase the nodes of the e-commerce system without increasing the nodes of the background and CMS.

Advantages:
System splitting realizes traffic sharing, solves concurrency problems, and can be optimized and horizontally expanded for different modules.
Problems in one system will not affect other systems, which improves fault tolerance.
Disadvantages:
Systems are independent of each other and cannot be interconnected The calling
systems are independent of each other, and there will be repeated development tasks

1.3 Distributed architecture

When there are more and more vertical applications, there will be more and more duplicate business codes. At this time, we thought about whether it is possible to extract the repeated code and make a unified business layer as an independent service, and then the front-end control layer calls different business layer services?
This leads to new distributed system architectures. It will split the project into two parts, the presentation layer and the service layer, and the service layer contains business logic. The presentation layer only needs to process the interaction with the page, and the business logic is realized by calling the services of the service layer.

Advantages:
extract common functions as service layer, improve code reusability.
Disadvantages:
The degree of coupling between systems becomes high, the calling relationship is intricate, and it is difficult to maintain.

1.4 SOA architecture

Under the distributed architecture, when there are more and more services, problems such as capacity evaluation and waste of small service resources gradually appear. At this time, it is necessary to add a scheduling center to manage the cluster in real time. At this point, the resource scheduling and governance center (SOA Service Oriented Architecture, service-oriented architecture) is the key.

Advantages:
Using the registration center solves the automatic adjustment of the calling relationship between services.
Disadvantages:
There will be dependencies between services. Once a certain link goes wrong, it will have a great impact (service avalanche), service concerns are complicated, and operation and maintenance, test deployment are difficult.

1.5 Microservice Architecture

Microservice architecture is to some extent the next step in the continued development of service-oriented architecture SOA, which places more emphasis on the "complete separation" of services.

Advantages:
Atomized splitting of services, independent packaging, deployment, and upgrades, ensuring clear task division of each microservice, and facilitating the use of lightweight http protocols such as Restful to call each other between extended microservices.
Disadvantages:
The technical cost of distributed system development is high (fault tolerance, distributed transactions, etc.).

2. Introduction to microservice architecture

Microservice architecture, simply put, is to further split the single application into smaller services, and each service is a project that can run independently.

2.1 Common problems of microservice architecture

Once the microservice system architecture is adopted, it is bound to encounter the following problems:

So many small services, how to manage them? (Service Governance Registry [Service Registration Discovery Elimination])
With so many small services, how do they communicate with each other? (restful rpc)
With so many small services, how do clients access them? (gateway)
With so many small services, once there is a problem, how should we deal with it? (fault tolerance)
So many small services, once there is a problem, how should I troubleshoot? (Link tracking)
For the above problems, no microservice designer can bypass them, so most microservice products are aimed at every problem Corresponding components are provided to resolve them.

2.2 Common concepts of microservice architecture

2.2.1 Service Governance

Service governance is the automatic management of services, and its core is the automatic registration and discovery of services.

Service registration: The service instance registers its own service information to the registration center.
Service discovery: The service instance obtains the information of the service instance registered in it through the registration center, and uses this information to request the services provided by them.
Service removal: The service registration center will automatically remove the problematic service from the available list, so that it will not be called.

2.2.2 Service call

In the microservice architecture, there is usually a need for remote calls between multiple services. Currently, the mainstream remote calling technologies include HTTP-based RESTful interface and TCP-based RPC protocol.

REST (Representational State Transfer): This is an HTTP call format, more standard and more general, no matter which language supports the http protocol
RPC (Remote Promote Call): An inter-process communication method. Allows calling remote services as if they were local services. The main goal of the RPC framework is to make remote service calls easier and more transparent. The RPC framework is responsible for shielding the underlying transmission method, serialization method and communication details. When using it, developers only need to know who provides what kind of remote service interface at what location, and do not need to care about the underlying communication details and calling process.
difference and connection

2.2.3 Service Gateway

With the continuous increase of microservices, different microservices generally have different network addresses, and external clients may need to call multiple service interfaces to complete a business requirement. If the client directly communicates with each microservice, it may appear :

The client needs to call different url addresses, which increases the difficulty.
In certain scenarios, there is a problem of cross-domain requests.
Each microservice requires separate authentication.

To address these problems, the API Gateway was born. API gateway directly means that all API calls are uniformly connected to the API gateway layer, and the gateway layer is uniformly connected and output. The basic functions of a gateway include: unified access, security protection, protocol adaptation, traffic control, long and short link support, and fault tolerance. With the gateway, each API service provider team can focus on their own business logic processing, while the API gateway is more focused on issues such as security, traffic, and routing.

2.2.4 Service Fault Tolerance

In microservices, a request often involves calling several services. If one of the services is unavailable without service fault tolerance, it is very likely that a series of services will be unavailable. This is the avalanche effect.
We can't prevent the avalanche effect from happening, we can only do our best to be fault-tolerant. The three core ideas of service fault tolerance are:

Not affected by the external environment
Not overwhelmed by upstream requests
Not bogged down by downstream responses

2.2.5 Link Tracking

With the popularity of microservice architecture, services are split according to different dimensions, and a request often needs to involve multiple services. Internet applications are built on different sets of software modules. These software modules may be developed by different teams, may be implemented using different programming languages, and may be deployed on thousands of servers, spanning multiple different data center. Therefore, it is necessary to log multiple service links involved in a request, and performance monitoring is link tracking

2.3 Common Solutions of Microservice Architecture

2.3.1 ServiceComb

2.3.2 SpringCloud

Spring Cloud is a collection of frameworks. It uses the development convenience of Spring Boot to subtly simplify the development of distributed system infrastructure, such as service discovery registration, configuration center, message bus, load balancing, circuit breaker, data monitoring, etc., can all be done with the development style of Spring Boot to one-click launch and deployment.

Spring Cloud does not repeat the manufacture of wheels, it just combines the mature and practical service frameworks developed by various companies at present, and repackages through the Spring Boot style to shield the complex configuration and implementation principles, and finally gives The developer has left a set of distributed system development kits that are easy to understand, deploy, and maintain.

2.3.3 SpringCloud Alibaba

2.3.3.1 Spring Cloud Alibaba Introduction

Spring Cloud Alibaba is committed to providing a one-stop solution for microservice development. This project contains the necessary components to develop distributed application microservices, so that developers can easily use these components to develop distributed application services through the Spring Cloud programming model.
Relying on Spring Cloud Alibaba, you only need to add some annotations and a small amount of configuration to connect Spring Cloud applications to Alibaba microservice solutions, and quickly build distributed application systems through Alibaba middleware.

2.3.3.1.1 Main functions

Service rate limiting and downgrading: By default, it supports the access of WebServlet, WebFlux, OpenFeign, RestTemplate, Spring Cloud Gateway, Zuul, Dubbo and RocketMQ. Flow degradation metrics monitoring.
Service registration and discovery: adapt to Spring Cloud service registration and discovery standards, and integrate Ribbon support by default.
Distributed configuration management: supports external configuration in distributed systems, and automatically refreshes when configuration changes.
Message-driven capability: Build message-driven capabilities for microservice applications based on Spring Cloud Stream.
Distributed transactions: Use @GlobalTransactional annotation to solve distributed transaction problems efficiently and with zero intrusion to business.
Alibaba Cloud Object Storage: Massive, secure, low-cost, and highly reliable cloud storage services provided by Alibaba Cloud. Supports storing and accessing any type of data in any application, anytime, anywhere.
Distributed task scheduling: Provide second-level, accurate, highly reliable, and highly available timing (based on Cron expression) task scheduling services. At the same time, it provides a distributed task execution model, such as grid tasks. Grid tasks support the even distribution of sea quantum tasks to all Workers (schedulerx-client) for execution.
Alibaba Cloud SMS service: SMS service covering the world, friendly, efficient, and intelligent interconnected communication capabilities, helping enterprises quickly build customer access channels.

2.3.3.1.2 Components

Sentinel: Taking traffic as an entry point, it protects the stability of services from multiple dimensions such as traffic control, circuit breaker degradation, and system load protection.
Nacos: A dynamic service discovery, configuration management and service management platform that makes it easier to build cloud-native applications.
RocketMQ: An open source distributed messaging system, based on highly available distributed cluster technology, provides low-latency, highly reliable message publishing and subscription services.
Dubbo: Apache Dubbo™ is a high-performance Java RPC framework.
Seata: Alibaba's open source product, an easy-to-use high-performance microservice distributed transaction solution.
Alibaba Cloud ACM: An application configuration center product that centrally manages and pushes application configurations in a distributed architecture environment.
Alibaba Cloud OSS: Alibaba Cloud Object Storage Service (OSS for short) is a massive, secure, low-cost, and highly reliable cloud storage service provided by Alibaba Cloud. You can store and access any type of data in any application, anytime, anywhere.
Alibaba Cloud SchedulerX: A distributed task scheduling product developed by the Alibaba middleware team, which provides second-level, accurate, highly reliable, and highly available scheduled (based on Cron expression) task scheduling services.
Alibaba Cloud SMS: SMS service covering the world, friendly, efficient, and intelligent interconnected communication capabilities, helping enterprises quickly build customer access channels.

2.3.4 SpringCloud和SpringCloudAlibaba

Many people may ask, with the microservice framework of spring cloud, why use the framework of spring cloud alibaba again? The most important reason is that almost all components in spring cloud use Netflix's products, and then a layer of encapsulation is made on the basis of it. However, Netflix's service discovery component Eureka has stopped updating, and there are also minor problems in the use process; therefore, its alternative product, spring cloud alibaba, is currently in a state of vigorous development. Please refer to Baidu for details, the instructions for stopping and replacing SpringCloud components.

The similarities between the two:
1. Communication method: http restful
2. Distributed tracking link: sleuth+zipkin

Therefore, it has become an inevitable trend for alibaba to replace springcloud, whether in terms of one-stop solutions for microservices or in terms of long-term project maintenance.

Evolution process of microservice architecture = "Spring Cloud Alibaba