This is the 29th day of my participation in the Gwen Challenge
1. Understand microservices
1.1 What are microservices
- Microservices are an architectural style
- An application is split into a set of small services
- Each service runs within its own process, which means it can be deployed and upgraded independently
- Services interact with each other using lightweight HTTP
- Services are split around business functions
- It can be independently deployed by the automatic deployment mechanism
- Decentralization, service autonomy. Services can use different languages and storage technologies
1.2 Microservice Architecture
- The service call
- Service degradation
- Service registration and delivery
- Service fusing
- Load balancing
- Service message queue
- The service gateway
- Configuration Center Management
- Automated Build deployment
- Service monitoring
- Full link tracing
- Service Timing Task
- Scheduling operation
2. Learn about SpringCloud
2.1 What is SpringCloud
SpringCloud is a site-type solution of distributed micro-service architecture, and a combination of various micro-service architecture technologies, commonly known as the whole family of micro-services.
IO /projects/sp…
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, One-time tokens, Global locks, Leadership Election, Distributed Sessions, Cluster State)
According to the official description of SpringCloud, it provides a series of tools that allow developers to quickly build distributed systems. So SpringCloud is not a new technology, but a package of commonly used technologies, combined with SpringBoot, allows us to quickly build distributed projects.
SpringCloud includes a lot of technology, and if you look at the catalog on the official website, you can’t capture a single screen. You tell me you don’t need a technique before you learn it, damn it.
2.2 SpringCloud stops and replaces components
The Hoxton version of SpringCloud replaces most of the original components with new ones, which are now in a more persistent state than the previous version.
See the following figure for details (x represents the previous component, now stopped; √ indicates the new replacement component) :
Service Registry
Eureka: Updates are officially stopped and there are better alternatives available, but they are no longer recommended.
Zookeeper: Some of the older systems used Zookeeper + Dubbo, but when they did a technical upgrade, they found that SpringCloud’s Eureka stopped working, so they used Zookeeper as the registry with the least amount of technical switching.
Consul: Go is also an excellent framework for registering services, but it is used less and has been upstage by Nacos.
Nacos: from SpringCloudAlibaba, which has passed the test of millions of registration in enterprises, can not only perfectly replace Eureka, but also replace other components, so it is strongly recommended to use it, which is the focus of learning.
The service call
Ribbon: Has also gone into maintenance and has stopped updating, but Spring officially still uses it.
LoadBalancer: A new component officially released by Spring that is intended to gradually replace the Ribbon, but is still in its infancy.
Service Call 2
Feign: Netflix has also stopped updating.
OpenFeign: The Spring community couldn’t wait for Netflix to update, so they built their own component without Feign.
Service degradation
Hystrix: It is not recommended on the official website, but it is still widely used in Chinese enterprises.
Resilience4J: It is recommended by the official website, but rarely used in China.
Sentienl: from SpringCloudAlibaba, replacing Hystrix components in Chinese enterprises, strongly recommended in China.
The service gateway
Zuul: A Netflix product. There was a split inside the company, and some people wanted to create their own Zuul2.
Zuul2: It was also a Netflix product, but due to internal disagreements, Zuul2 was stillborn.
Gateway: The Spring community’s own gateway component, officially introduced and highly recommended gateway service component.
Service configuration
Config: currently in use, upstaged by Nacos.
Nacos: from SpringCloudAlibaba, which has taken the lead and replaced Config.
The service bus
Bus: SpringCloud’s native service Bus component, now upstage by Nacos.
Nacos: from SpringCloudAlibaba, leapfrog and replaced Bus.
As you can see, Nacos is the most important component, and a single component replaces several components.
3. Create distributed projects
Different from individual projects, distributed projects are generally divided into multiple modules, which constitute the relationship between parent projects and child projects. Typically a single SpringBoot project, poM file will always have this section
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.2. RELEASE</version>
<relativePath/> <! -- lookup parent from repository -->
</parent>
Copy the code
The parent project is specified as a version of SringBoot. Subsequent jar packages inherit the version information specified by the parent project.
Let’s create a new parent project for a distributed project
3.1 Creating a Parent Project
There are 8 key steps to create the microservice Cloud overall aggregation parent Project:
(1) New Project – Maven Project (2) Aggregation total parent Project name (3) Maven select version (4) Project name (5) character encoding – settings-file encoding (6) Annotation effect activation – Settings – Annotation Processors (7) Java compiler version select 8 (8) File Type filter – settings-file Type
After creation, you can delete the SRC directory, because the parent project does not need it
Then you need to modify the POM.xml file, noting the comments
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.codeliu</groupId>
<artifactId>springcloud-test</artifactId>
<version>1.0 the SNAPSHOT</version>
<! -- Parent project must be packaged in POM mode -->
<packaging>pom</packaging>
<! Jar package version number -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>8</maven.compiler.source>
<maven.compiler.target>8</maven.compiler.target>
<junit.version>4.12</junit.version>
<log4j.version>1.2.17</log4j.version>
<lombok.version>1.16.18</lombok.version>
<mysql.version>8.0.11</mysql.version>
<druid.version>1.1.16</druid.version>
<mybatis.spring.boot.version>1.3.0</mybatis.spring.boot.version>
</properties>
<! If the parent project does not specify the version, the parent project will use the version declared by the parent project. The parent project can also specify the version to overwrite.
<dependencyManagement>
<dependencies>
<! - spring boot 2.2.2 -- -- >
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>2.2.2. RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<! --spring cloud Hoxton.SR1-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Hoxton.SR1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<! - spring cloud alibaba 2.1.0. RELEASE -- -- >
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>2.1.0. RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysql.version}</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>${druid.version}</version>
</dependency>
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-starter</artifactId>
<version>${mybatis.spring.boot.version}</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>${log4j.version}</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>${lombok.version}</version>
<optional>true</optional>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<fork>true</fork>
<addResources>true</addResources>
</configuration>
</plugin>
</plugins>
</build>
</project>
Copy the code
For dependencyManagement and Dependencies, Maven uses the dependencyManagement element to manage dependency version numbers. The dependencyManagement element is usually found in the top-level parent POM of an organization or project.
Use the dependencyManagement element in pom.xml to reference dependencies in all subprojects without explicitly listing the version number.
Maven moves up the parent-child hierarchy until it finds a project that has a dependencyManagement element, and then it uses the version number specified in that dependencyManagement element.
For example, a database-driven JAR is declared in the parent project
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.11</version>
</dependency>
Copy the code
There is no need to specify a version number in a subproject
<dependency>
<groupId>mysq1</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
Copy the code
The advantage of this is that if you have multiple subprojects that reference the same dependency, you can avoid declaring a version number in each used subproject, so that when you want to upgrade or switch to another version, you only need to update in the top-level parent container instead of making changes to each subproject. In addition, if a subproject requires another version, you can simply declare version.
DependencyManagement only declares dependencies and does not implement import, so subprojects need to display required dependencies. If a dependency is not declared in a child project, it will not be inherited from the parent project; The dependency is inherited from the parent project only if it is written in the child project and no version is specified, and both Version and scope are read from the parent POM.
If the version number is specified in the subproject, the jar version specified in the subproject is used.
In addition, the version number of SpringCloud is specified as hoxton.sr1, which is also rumored. For details, please refer to juejin.cn/post/684490…
3.2 Creating subprojects
Right-click on the parent project and create a new one
Let’s create whatever kind of subproject we have, so let’s create a New SpringBoot project and fill it in, okay
The directory structure is as follows
Then we need to modify the PARENT project and child project POM files to associate them
Creating other subprojects is the same procedure.
For submodules that do not require service startup, such as the Common module, you can delete the startup class and its associated test folder after creation.
If you want to reference each other in subprojects, for example, if a submodule wants to introduce the cloud-provider-Payment module, you can specify it in the POM file
<dependency>
<groupId>com.codeliu</groupId>
<artifactId>cloud-provider-payment</artifactId>
<version>1.0 the SNAPSHOT</version>
</dependency>
Copy the code
Reference:
- SpringCloud stop more components and replacement: www.cnblogs.com/y3blogs/p/1…
- Blog.csdn.net/u011863024/…
- SpringCloud release: juejin.cn/post/684490…