Eureka overview
service registration
Microservices are different services distributed on different hosts, and there may be a calling relationship between services.
We may call other services by hard-coding the service address, so that there are many inconveniences for the later addition of services and the redeployment of services, so the registry solves such a problem.
The registry is the address book in the microservice architecture, which records the mapping relationship between services and service addresses.
In a distributed architecture, services will be registered here. When a service needs to call other services, it will look for the service address through the registration center. When a new service is added, the service address will also be registered in the registration center.
Service Governance
Service governance can be said to be the most core and basic module in the microservice architecture, which is mainly used to realize the automatic registration and discovery of each microservice instance.
Reasons to use Service Governance:
When there are not many service references, the service call can be completed through static configuration, but with the development of the business, the system functions become more and more complex, and the corresponding microservices also continue to increase. At this time, the static configuration will become more and more complex. increasingly difficult to maintain.
And in the face of the constantly developing business, the scale of the cluster, the location of the service, the naming of the service, etc. may change. If it is maintained manually, it is very prone to errors or naming conflicts.
At the same time, it will also consume a lot of manpower to maintain the content of the static configuration.
In order to solve the problem of service instance maintenance in the microservice architecture, a large number of service governance frameworks and products have been produced.
The implementation of these frameworks and products revolves around the service registration and service discovery mechanism to complete the automatic management of microservice application instances.
Composition of Eureka
Eureka Service Architecture
Stand-alone version of Eureka implementation
Configure Eureka server (registry center)
1. Build module
cloud-eureka-server7001
2. Write pom
<?xml version="1.0" encoding="UTF-8"?> <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"> <parent> <artifactId>cloud2021</artifactId> <groupId>com.lejia.springcloud</groupId> <version>1.0-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>cloud-eureka-server7001</artifactId> <dependencies> <!--eureka-server--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> <dependency> <groupId>com.lejia.springcloud</groupId> <artifactId>cloud-api-commons</artifactId> <version>${project.version}</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <!--Generally common configuration--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> </project>
3. Change yml
server: port: 7001 eureka: instance: hostname: localhost #The instance name of the eureka server client: #false means not to register itself with the registry register-with-eureka: false #false means that my end is the registration center, my responsibility is to maintain the service, and I don't need to retrieve it fetch-registry: false service-url: #Both the address query service and the registration service that interact with Eureka Server need to rely on this address defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
4, the main start
@SpringBootApplication @EnableEurekaServer public class EurekaMain7001 { public static void main(String[] args) { SpringApplication.run(EurekaMain7001.class, args); } }
5. Test
http://localhost:7001/
2. Register the provider 8001 microservice into the Eureka center (customer of the registration center | service provider)
Overview of SpringCloud Microservices and Payment Module for Project Aggregation Instances
1. Change POM
Add dependencies to pom
<!--eureka-client--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>
2. Change yml
Add configuration to yum
server: port: 8001 spring: application: name: cloud-payment-service8001 datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/cloud2020?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=UTC username: root password: 1234 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.lejia.springcloud.entities ####################This is a new configuration######################### eureka: client: #Indicates whether to register itself in EurekaServer The default is true register-with-eureka: true #Whether to grab the existing registration information from EurekaServe, the default is true # A single node does not matter, the cluster must be set to true to use load balancing with ribbon fetch-registry: true service-url: defaultZone: http://localhost:7001/eureka
3. Set the main startup
@SpringBootApplication @EnableEurekaClient public class PaymentMain8001 { public static void main(String[] args) { SpringApplication.run(PaymentMain8001.class,args); } }
4. Start the test
http://localhost:7001/
4. Register the consumer 80 microservice into the Eureka center (customers of the registration center | service consumers)
Similar to 8001 service provider configuration
1. Change pom
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>
2. Write yml
server: port: 80 spring: application: name: cloud-consumer-order80 #####################This is new################## eureka: client: #Indicates whether to register itself in EurekaServer The default is true register-with-eureka: true #Whether to grab the existing registration information from EurekaServe, the default is true # A single node does not matter, the cluster must be set to true to use load balancing with ribbon fetch-registry: true service-url: defaultZone: http://localhost:7001/eureka
3. Configure the main startup
@SpringBootApplication @EnableEurekaClient public class OrderMain80 { public static void main(String[] args) { SpringApplication.run(OrderMain80.class,args); } }
4. Test
http://localhost:7001/
service call test
At this point, some readers may have questions, whether this service registry exists or not can implement remote service calls, so why do we need to use the service registry to superfluous!
The reason is that when we have more services, if only restTemplate is used to operate a multi-service cluster, the program will become very complicated. After we use the registry, we can easily implement the invocation of cluster services and task scheduling, load Balance and other functions