Getting started with SpringCloud and creating distributed projects

Getting started with SpringCloud and creating distributed projects

This is the 29th day I participated in the more essay challenge. For details of the event, please view: Event link

1. Understand microservices

1.1 What is a microservice

  • Microservices is an architectural style
  • Split an application into a set of small services
  • Each service runs in its own process, which means it can be deployed and upgraded independently
  • Lightweight HTTP interaction between services
  • Services are split around business functions
  • Can be independently deployed by a fully automated deployment mechanism
  • Decentralization, service autonomy. Services can use different languages and different storage technologies

1.2 Microservice architecture

  • Service call
  • Service degradation
  • Service registration and delivery
  • Service fuse
  • Load balancing
  • Service message queue
  • Service gateway
  • Configuration Center Management
  • Automated build deployment
  • Service monitoring
  • Full link tracking
  • Service timed tasks
  • Scheduling operations

2. Understand SpringCloud

2.1 What is SpringCloud

SpringCloud is a stand-alone solution for distributed microservice architecture. It is a collection of multiple microservice architecture landing technologies, commonly known as the microservice family bucket .

Official document:

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (eg configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). ---From the official website

According to the official description of SpringCloud, SpringCloud provides a series of tools that enable developers to quickly build distributed systems. So SpringCloud is not a new technology, it just integrates some commonly used technologies for packaging, and then combined with SpringBoot, we can quickly build distributed projects.

SpringCloud contains a lot of technologies, as you can see from the catalog on the official website, one screen is incomplete. Often a technology is told to me that it is no longer used before I learn it, especially meow.

2.2 SpringCloud shutdown components and replacement

SpringCloud version of Hoxton, and compared to previous versions, replaced with a new assembly off most of the original components, the components are now in the old stop with more non-stop situation.

For details, see the following figure ( means the previous component, which has been stopped now; means the new replacement component):

Service Registry

Eureka: The official stopped updating, and there are already better alternative products that can be used, but the official does not recommend it anymore.

Zookeeper: Some old systems used Zookeeper + Dubbo in the past, and later upgraded the technology. It turned out that SpringCloud's Eureka stopped updating, and then used the least technical switching, then Zookeeper was used as the registration center.

Consul: Go language is also an excellent service registration framework, but the usage is less, and the limelight has been robbed by Nacos.

Nacos: From SpringCloudAlibaba, it has passed millions of registration tests in the enterprise. It can not only replace Eureka perfectly, but also replace other components, so it is strongly recommended to use it, which is the focus of learning.

Service call

Ribbon: It has also entered a maintenance state and stopped updating, but Spring is still officially in use.

LoadBalancer: A new component officially launched by Spring that intends to gradually replace Ribbon, but it is still in its infancy.

Service call 2

Feign: Netflix products have also stopped updating.

OpenFeign: The Spring community couldn't wait for Netflix to update, and then made a component of its own without Feign.

Service degradation

Hystrix: The official website is not recommended, but it is still used on a large scale in Chinese companies.

Resilience4J: It is recommended on the official website, but it is rarely used in China.

Sentienl: Comes from SpringCloudAlibaba, replacing Hystrix components in Chinese companies, and it is strongly recommended in China.

Service gateway

Zuul: Netflix products, there are disagreements within the company, and some people want to create a Zuul2 by themselves.

Zuul2: It is also a product prepared by Netflix, but due to internal differences, Zuul2 is dead.

gateway: The gateway component produced by the Spring community itself, the official grand introduction and highly recommended gateway service component.

Service configuration

Config: It's also currently in use, and Nacos grabbed the limelight.

Nacos: It comes from SpringCloudAlibaba, and later came to the top and replaced Config.

Service bus

Bus: SpringCloud's native service bus component is now snatched by Nacos.

Nacos: It comes from SpringCloudAlibaba, and came to the top, replacing Bus.

In summary, it can be seen that Nacos is the top priority, and one component replaces the original several components.

3. Create a distributed project

Distributed projects are different from single projects. They are generally divided into multiple modules to form the relationship between the parent project and the subproject. Generally, for a single SpringBoot project, the pom file always has such a section

< parent > < groupId > org.springframework.boot </groupId > < artifactId > spring-boot-starter-parent </artifactId > < version > 2.1.2.RELEASE </version > < relativePath/> <!-- lookup Repository from parent -> </parent > copy the code

The parent project is specified as a certain version of SringBoot, and subsequent use of related jar packages will inherit the version information specified by the parent project.

Let's create a new parent project of a distributed project

3.1 Create parent project

There are 8 key steps to create a microservice cloud overall aggregation parent project Project:

(1) New Project-maven project (2) aggregate parent project name (3) Maven selected version (4) project name (5) character encoding-Settings-File encoding (6) Annotation effective activation-Settings-Annotation Processors (7 ) Java compilation 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, it becomes the following

Then you need to modify the pom.xml file, pay attention to the comments

<?xml version="1.0" encoding="UTF-8"?> < project xmlns = "" xmlns:xsi = "http://www.w3 .org/2001/XMLSchema-instance" xsi:schemaLocation = "" > < modelVersion > 4.0.0 </modelVersion > < groupId > com.codeliu </groupId > < artifactId > springcloud-test </artifactId > < version > 1.0-SNAPSHOT </version > <!--The packaging method of the parent project must be pom--> < packaging > pom </packaging > <!--Unified management of jar package version number--> < properties > < > UTF-8 </ > < maven.compiler.source > 8 </maven.compiler.source > < > 8 </ > < 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 > <!--Declare that the jar package and the specified version are dependent, and the import is not implemented. The subproject will introduce it. If the subproject does not specify the version, the version declared by the parent project will be used. You can also specify the version to override --> < 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 > </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 > </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 > </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} lombok</version > </dependency > < dependency > < groupId > log4j </groupId > < artifactId > log4j </artifactId > < version > ${log4j.version} </version > </dependency > < dependency > < groupId > org.projectlombok </groupId > < artifactId ></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 code


, Maven uses the dependencyManagement element to manage the dependency version number. The dependencyManagement element is usually seen in the parent POM at the top of an organization or project.

Using the dependencyManagement element in pom.xml allows all sub-projects to reference dependencies without explicitly listing the version number.

Maven will go up the parent-child hierarchy until it finds a project with a dependencyManagement element, and then it will use the version number specified in the dependencyManagement element.

For example, a database-driven jar is declared in the parent project

< Dependency > < the groupId > MySQL </the groupId > < the artifactId > MySQL-Connector-Java </the artifactId > < Version > 8.0.11 </Version > </dependency > copy the code

Then in the sub-project, there is no need to specify the version number

< Dependency > < the groupId > mysq1 </the groupId > < the artifactId > MySQL-Connector-Java </the artifactId > </dependency > copy the code

The advantage of this is that if there are multiple sub-projects that all reference the same dependency, you can avoid declaring a version number in each sub-project used, so that when you want to upgrade or switch to another version, you only need to be at the top level Updates in the parent container do not need to modify each sub-project; in addition, if a sub-project requires another version, you only need to declare the version.

DependencyManagement only declares dependencies and does not implement importing, so the dependencies that need to be declared in the subprojects need to be declared. If the dependency is not declared in the subproject, it will not be inherited from the parent project; only if the dependency is written in the subproject and no specific version is specified, the item will be inherited from the parent project, and the version and scope All read from the parent pom.

If the version number is specified in the subproject, the jar version specified in the subproject will be used.

Also about

The version number specified is
, This is also true. For details, please refer to:

3.2 Create subproject

Right-click on the parent project to create

Build any type of our sub-projects. Create a SpringBoot project here and fill in the relevant information

The directory structure after creation is as follows

Then we need to modify the pom files of the parent project and the subproject to associate

The steps for creating other subprojects are the same.

For some submodules that do not require service startup, such as the common module, after creating a new one, you can delete the startup class and related test folders.

If you want to reference each other in a sub-project, for example, a sub-module must be introduced

Module, can be specified directly in the pom file

< Dependency > < the groupId > com.codeliu </the groupId > < the artifactId > Cloud-Provider-Payment </the artifactId > < Version > 1.0-the SNAPSHOT </Version > </dependency > copy the code

Reference :