A prelude to

In the previous article, we understood the basic concept of microservices && Eureka-Server cluster setup. Of course, it’s not enough to have a service registry, we also have to have a service consumer, which we call Eureka-Client in Spring-Cloud, to make a service registry worthwhile. Ok, let’s happily masturbate the code ~

Set up the service consumer Project

  1. Creating a Spring project

  2. Fill in maven coordinates

  3. Note: since we are eureka-client, check Discovery.

  4. After we have created the project, we need to add the spring-boot-Web package dependencies because we want to run it in Web form

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
Copy the code
  1. As with Eureka-Server, as a Client of Eureka-Client we need to annotate @enableDiscoveryClient on the startup class, identifying it as Client
@SpringBootApplication
@EnableDiscoveryClient
public class EurekaClientApplication {
    public static void main(String[] args) { SpringApplication.run(EurekaClientApplication.class, args); }}Copy the code
  1. Configure eureka-client, here we Cient name as order(the following configuration has been described in eureka-server, here is no longer redundant)
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/,http://localhost:8763/eureka/

server:
  port: 8090

spring:
  application:
    name: order
Copy the code

  1. Start project observation log, 204 indicates registered:

  2. Access the registry at localhost:8761 and find that the order service has been registered

Graphic Registry

  1. When service A calls service B without A registry, we need to directly connect Ip to call service B or use Proxy, but our service will continue to expand && reduce or service offline (such as the gray service B in the figure), so we need to expand & shrink or offline service manually
  1. After the establishment of the registry, our call relationship has changed. The red arrow in the figure shows that service B only needs to register itself with the service center and has heartbeat detection. When service A needs to call service B, it only needs to search from the registry. Such service B enlarge shrinks let | | offline services, registry would perceive, such service when invoking A service B can only from the surviving lookup and invoke service B
  1. When service A gets the available list of service B, it uses A load balancing strategy to search for service invocation. There are generally two mechanisms in service discovery: 1) Client discovery. Spring-cloud Ribbon uses client discovery mechanism, followed by spring-Cloud The Ribbon talks about server discovery, like our Proxy, Nginx…

conclusion

  1. There is a heartbeat check between eureka-server && Eureka-Client to see if the Eureka-Client is still alive
  2. Registry servers tend to be an important part of the service, so we need to be highly available and produce as many as possible
  3. Spring-cloud Eureka is a client-side discovery mechanism, including Nginx, Zookeeper, and other server-side discovery mechanisms

At the end

Now that we’re done with the Spring Cloud registry, let’s learn about Spring-Cloud Feign in the next section