SpringCloud01--Dark Horse【Part 1】

SpringCloud01

1. Understand microservices

With the development of the Internet industry, the requirements for services are getting higher and higher, and the service architecture has gradually evolved from a single architecture to the now popular microservice architecture. What is the difference between these architectures?

1.0. Learning Objectives

Understand the pros and cons of microservices architecture

1.1. Monolithic Architecture

Monolithic Architecture : All functions of the business are developed in one project and packaged into one package for deployment.

The advantages and disadvantages of monolithic architecture are as follows:

advantage:

• simple structure
• Low deployment cost

shortcoming:

• High degree of coupling (difficult to maintain and upgrade)

1.2. Distributed Architecture

Distributed architecture : The system is split according to business functions, and each business function module is developed as an independent project, called a service.

Advantages and disadvantages of distributed architecture:

advantage:

• Reduce service coupling
• Conducive to service upgrade and expansion

shortcoming:

• Service call relationship is intricate

Although the distributed architecture reduces service coupling, there are still many issues to consider when splitting services:

• How to define the granularity of service splitting?
• How to call between services?
• How to manage service invocation relationship?

People need to develop a set of effective standards to constrain the distributed architecture.

1.3. Microservices

Architectural characteristics of microservices:

• Single Responsibility: The granularity of microservice splitting is smaller, and each service corresponds to a unique business capability, so as to achieve a single responsibility
• Autonomy: independent team, independent technology, independent data, independent deployment and delivery
• Service-oriented: services provide a unified standard interface, independent of language and technology
• Strong isolation: service calls are isolated, fault-tolerant, and degraded to avoid cascading problems

The above characteristics of microservices are actually setting a standard for distributed architecture, further reducing the coupling between services, and providing independence and flexibility of services. be high

Cohesion, low coupling. Therefore, microservices can be considered as a distributed architecture solution with well-designed architecture .

But how should the plan be implemented? What technology stack to choose? Internet companies around the world are actively trying their own microservice implementation solutions.

Among them, the most eye-catching one in the field of Java is the solution provided by Spring Cloud.

1.4.SpringCloud

SpringCloud is currently the most widely used microservice framework in China. Official website address

Spring Cloud integrates various microservice functional components, and realizes the automatic assembly of these components based on SpringBoot, thus providing a good out-of-the-box experience.

Common components include:

In addition, the bottom layer of SpringCloud depends on SpringBoot, and has a version compatibility relationship, as follows:

The version we study in class is Hoxton.SR10, so the corresponding SpringBoot version is version 2.3.x.

1.5. Summary

• Monolithic architecture: simple and convenient, highly coupled, poor scalability, suitable for small projects. Example: Student Management System

• Distributed architecture: loosely coupled and scalable, but complex and difficult. Suitable for large-scale Internet projects, such as JD.com and Taobao

• Microservices: A Good Distributed Architecture Solution

  ①Advantages: smaller split granularity, more independent services, and lower coupling

  ②Disadvantages: the structure is very complex, and the difficulty of operation and maintenance, monitoring and deployment is increased

• SpringCloud is a one-stop solution for microservice architecture, integrating various excellent microservice functional components

2. Service splitting and remote calling

Any distributed architecture is inseparable from the splitting of services, and the same is true for microservices.

2.1. Principles of service splitting

Here I summarize several principles when splitting microservices:

• Different microservices, do not develop the same business repeatedly
• Microservice data is independent, do not access the database of other microservices
• Microservices can expose their business as interfaces for other microservices to call

2.2. Example of service splitting

Taking the microservice cloud-demo in the pre-class materials as an example, its structure is as follows:

cloud-demo: parent project, manage dependencies

• order-service: order microservice, responsible for order-related business
• user-service: user microservice, responsible for user-related business

Require:

• Both the order microservice and the user microservice must have their own databases, independent of each other
• Both order service and user service expose Restful interfaces to the outside world
• If the order service needs to query user information, it can only call the Restful interface of the user service, and cannot query the user database

2.2.1. Import Sql statement

cloud-order.sqlFirst, import the sum provided by the pre-class materials cloud-user.sqlinto mysql:

The initial data in the cloud-user table is as follows:

The initial data in the cloud-order table is as follows:

The cloud-order table holds the id field in the cloud-user table.

2.3. Realize the remote call case

In the order-service service, there is an interface for querying orders by id:

Query the order according to the id, and the return value is an Order object, as shown in the figure:

where user is null

In user-service, there is an interface for querying users by id:

[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-dDrYSTbz-1671434633122)(assets/image-20210713213146089.png)]

The result of the query is shown in the figure:

[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-padW0XS0-1671434633123)(assets/image-20210713213213075.png)]

2.3.1. Case requirements:

Modify the order query service by id in the order-service, requiring that the user information be queried according to the userId contained in the order while querying the order, and returned together.

[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-Tu0F88HM-1671434633125)(assets/image-20210713213312278.png)]

Therefore, we need to initiate an http request to user-service in order-service and call the interface http://localhost:8081/user/{userId}.

The approximate steps are as follows:

• Register an instance of RestTemplate to the Spring container
• Modify the queryOrderById method in the OrderService class in the order-service service, and query the User according to the userId in the Order object
• Fill the queried User into the Order object and return it together

2.3.2. Register RestTemplate

First, we register the RestTemplate instance in the OrderApplication startup class in the order-service service:

package cn.itcast.order;

import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
    
    

    public static void main(String[] args) {
    
    
        SpringApplication.run(OrderApplication.class, args);
    }

    @Bean
    public RestTemplate restTemplate() {
    
    
        return new RestTemplate();
    }
}

2.3.3. Realize remote call

Modify the queryOrderById method in the OrderService class under the cn.itcast.order.service package in the order-service service:

2.4. Providers and consumers

In the service invocation relationship, there are two different roles:

Service provider : A service called by other microservices in a business. (Provide interfaces to other microservices)

Service consumer : A service that calls other microservices in a business. (calling interfaces provided by other microservices)

However, the roles of service providers and service consumers are not absolute, but relative to the business.

If service A calls service B, and service B calls service C, what is the role of service B?

• For the business of A calling B: A is a service consumer, B is a service provider
• For the business where B calls C: B is a service consumer, and C is a service provider

Therefore, service B can be both a service provider and a service consumer.