0Pricing
API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · 课时

与 Eureka/Consul 集成

配置 Spring Cloud Gateway，使其向 Eureka 或 Consul 等服务注册中心注册并发现服务。

与 Eureka/Consul 集成 是 CoddyKit 上的免费 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

What is Service Discovery?

In a microservices architecture, services are often dynamic. They can scale up or down, and their network locations (IP addresses, ports) can change frequently.

Service discovery is a mechanism that helps applications and services find each other without needing to hardcode their network locations. It's like a dynamic phone book for your services!

Service Registries: Eureka & Consul

A service registry is a central server that maintains a list of available service instances and their network locations.

  • Netflix Eureka: A very popular choice, especially within the Spring Cloud ecosystem. Services register themselves with Eureka.
  • HashiCorp Consul: Another robust option, offering service discovery along with a distributed key-value store and health checks.

Both allow services to register themselves and discover others.

Gateway's Need for Discovery

Spring Cloud Gateway acts as the entry point to your microservices.

Instead of configuring routes with fixed URLs for each backend service, the Gateway can query a service registry:

  • "Where is the 'user-service' running right now?"
  • "Give me an available instance of 'product-service'."

This enables flexible, dynamic, and resilient routing, as the Gateway doesn't need to know service locations upfront.

Sample Service: Eureka Client Config

First, let's look at how a simple Spring Boot service is configured to register itself with a Eureka server.

We'll use a service named hello-service. Its application.yml will point to the Eureka server's default zone.

spring:
  application:
    name: hello-service
server:
  port: 8081
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka

Enabling Eureka Client in Service

To make our hello-service actually register with Eureka, we need to add the @EnableEurekaClient annotation to its main application class.

This annotation activates the Eureka Discovery Client functionality.

package com.example.helloservice;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@EnableEurekaClient
@SpringBootApplication
@RestController
public class HelloServiceApplication {

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

    @GetMapping("/hello")
    public String hello() {
        return "Hello from Hello Service!";
    }
}

Gateway Configuration for Eureka

Now, let's configure our Spring Cloud Gateway to connect to the same Eureka server. The Gateway itself also acts as a Eureka client to discover other services.

Its application.yml will specify the Eureka server URL and its own application name.

server:
  port: 8080
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka
  instance:
    hostname: localhost
spring:
  application:
    name: api-gateway

Enabling Discovery in Gateway

Similar to the backend service, the Gateway's main application class needs an annotation to enable its discovery capabilities.

Use @EnableDiscoveryClient to tell Spring Boot to activate the discovery client for the Gateway.

package com.example.apigateway;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

@EnableDiscoveryClient
@SpringBootApplication
public class ApiGatewayApplication {

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

Routing via Service ID

With discovery enabled, we can define Gateway routes using a service's registered ID instead of a fixed URL.

The lb:// prefix (for 'load balancer') tells the Gateway to use its discovery client to find instances of the specified service name (e.g., hello-service) and then route the request.

spring:
  cloud:
    gateway:
      routes:
        - id: hello_route
          uri: lb://hello-service
          predicates:
            - Path=/hello/**

The Request Flow

Let's trace a request to http://localhost:8080/hello:

  1. The Gateway (listening on port 8080) receives the request.
  2. It matches the /hello/** path predicate to the hello_route.
  3. The Gateway uses its Eureka client to look up an available instance of hello-service.
  4. Eureka returns the address of an instance (e.g., localhost:8081).
  5. The Gateway forwards the request to http://localhost:8081/hello.
  6. The hello-service processes the request and returns a response, which the Gateway then sends back to the client.

Consul: Another Option

While Eureka is widely used, Consul by HashiCorp is another powerful service discovery and configuration management tool.

To use Consul, you'd typically add the Spring Cloud Consul Discovery dependency and configure your Gateway/services to point to the Consul agent (usually running on port 8500).

The principle remains the same: the Gateway uses service IDs (e.g., lb://my-service) to dynamically discover and route to services registered in Consul.

spring:
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        service-name: api-gateway

Gateway Discovery Check

You've configured your Spring Cloud Gateway to use Eureka for service discovery, and you have a service named my-service registered in Eureka.

Which uri configuration would correctly route requests to my-service via discovery?

Lesson Summary

In this lesson, you learned about:

  • The importance of service discovery in dynamic microservice environments.
  • How Eureka and Consul serve as central service registries.
  • Configuring both backend services and Spring Cloud Gateway as discovery clients.
  • Defining Gateway routes using service IDs (e.g., lb://service-name) for dynamic routing.

This integration is fundamental for building scalable and resilient microservice architectures. Next, we'll explore more dynamic routing rules and predicates.

常见问题解答

「与 Eureka/Consul 集成」课时是免费的吗？

是的 — 「与 Eureka/Consul 集成」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 课程的其余内容，请升级到 CoddyKit PRO。 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 课程共包含 4 节课。

「与 Eureka/Consul 集成」这节课中我会学到什么？

配置 Spring Cloud Gateway，使其向 Eureka 或 Consul 等服务注册中心注册并发现服务。 你通过在浏览器中直接运行的动手代码来练习 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 需要有经验吗？

无需任何先前经验。CoddyKit 上的 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。

「与 Eureka/Consul 集成」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 课中编写并运行代码吗？

能。每节 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 与 Eureka/Consul 集成
  2. 使用服务发现进行动态路由
  3. 使用 Spring Cloud LoadBalancer 进行负载均衡
  4. lb:// URI 与发现定位器
← 返回 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)