发布于 由admin

Java `Service Discovery` (`Eureka`, `Consul`, `Nacos`) 与 `Load Balancing` 策略

各位观众老爷，大家好！今天咱们来聊聊微服务架构里两个密不可分的好基友：服务发现（Service Discovery）和负载均衡（Load Balancing）。这俩哥们儿，一个负责找人，一个负责分活儿，配合得那叫一个天衣无缝，让咱们的微服务集群跑得又稳又快。

一、啥是服务发现？

想象一下，你开了一家小饭馆（一个微服务），想让顾客（其他微服务）找到你，你得干嘛？

  1. 贴广告（注册）： 在大街上贴个“好吃不贵，欢迎光临”的广告，告诉大家你在哪儿，卖啥。
  2. 有人指路（发现）： 有人问路，得有热心群众指路，告诉他们饭馆的具体位置。

服务发现就是干这个事的。它负责：

  • 服务注册（Service Registration）： 微服务启动时，把自己注册到服务注册中心，告诉大家自己的地址（IP地址和端口号）。
  • 服务发现（Service Discovery）： 其他微服务需要调用你的时候，去服务注册中心查你的地址。

为啥要服务发现？

在传统的单体应用里，服务之间的调用都是硬编码的，直接写死IP地址和端口号。但微服务架构下，服务数量多，实例经常变化（扩容、缩容、重启），硬编码就Hold不住了。服务发现能动态地找到可用的服务实例，解决服务地址变化的问题。

服务发现的几种姿势：

  1. Eureka (Netflix)： Netflix家的老牌服务发现组件，用Java写的，特点是简单易用，但闭源了，现在已经进入维护模式。
  2. Consul (HashiCorp)： HashiCorp家的开源服务发现和配置管理工具，支持多种语言，功能强大，除了服务发现，还能做健康检查、KV存储等。
  3. Nacos (Alibaba)： 阿里巴巴开源的服务发现、配置管理和服务管理平台，功能齐全，性能优异，支持多种协议。
  4. ZooKeeper (Apache)： Apache的分布式协调服务，也能用来做服务发现，但配置比较复杂。
  5. Etcd (CNCF)： CNCF（云原生计算基金会）的分布式键值存储，常用于Kubernetes集群的服务发现。

二、服务发现三剑客：Eureka, Consul, Nacos

咱们重点看看Eureka、Consul、Nacos这三个哥们儿。

特性 Eureka Consul Nacos
开发语言 Java Go Java
数据一致性 AP (可用性优先) CP (一致性优先) AP/CP 可选
健康检查 Client-side (客户端) Agent-based (代理) Client-side/Server-side (客户端/服务端)
服务注册 通过HTTP API 通过HTTP API 或 DNS 通过HTTP API
配置管理 不支持 支持 KV 存储 支持
社区活跃度 较低 较高 较高
适用场景 中小型项目，对一致性要求不高，对可用性要求高的场景。 中大型项目，对一致性要求较高，需要更丰富的功能，如配置管理、健康检查等。 中大型项目，对性能要求高，需要更丰富的功能，如配置管理、服务管理等。
学习曲线 简单 稍复杂 适中

1. Eureka (Netflix)：

  • 核心组件：

    • Eureka Server： 服务注册中心，负责接收服务的注册和发现请求。
    • Eureka Client： 运行在每个微服务中，负责向Eureka Server注册和发现服务。

  • 工作流程：

    1. 微服务启动时，向Eureka Server注册自己的信息（服务名、IP地址、端口号等）。
    2. Eureka Server收到注册请求后，将服务信息存储起来。
    3. 其他微服务需要调用某个服务时，向Eureka Server发起发现请求。
    4. Eureka Server返回可用服务实例的列表。
    5. 微服务从列表中选择一个实例进行调用。

  • 代码示例 (Spring Cloud Netflix Eureka)：

    • Eureka Server 配置：

      @SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {

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

      application.yml

      server:
  port: 8761

eureka:
  client:
    register-with-eureka: false
    fetch-registry: false

    • Eureka Client 配置：

      @SpringBootApplication
@EnableEurekaClient
public class ServiceApplication {

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

      application.yml

      spring:
  application:
    name: your-service-name

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

  • 优点： 简单易用，与Spring Cloud集成良好。

  • 缺点： 闭源，现在已经进入维护模式，不再积极维护更新。数据一致性方面，Eureka采用AP（可用性优先）策略，在网络分区的情况下，可能会出现服务列表不一致的情况。

2. Consul (HashiCorp)：

  • 核心组件：

    • Consul Server： 服务注册中心，负责接收服务的注册和发现请求，维护服务状态信息。
    • Consul Agent： 运行在每个节点上，负责与Consul Server通信，注册和发现服务，执行健康检查。

  • 工作流程：

    1. 微服务启动时，通过Consul Agent向Consul Server注册自己的信息。
    2. Consul Agent会定期对微服务进行健康检查，确保服务可用。
    3. 其他微服务需要调用某个服务时，通过Consul Agent向Consul Server发起发现请求。
    4. Consul Server返回可用服务实例的列表。
    5. 微服务从列表中选择一个实例进行调用。

  • 代码示例 (Spring Cloud Consul)：

    • 添加依赖：

      <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-consul-discovery</artifactId>
</dependency>

    • Consul Client 配置：

      @SpringBootApplication
@EnableDiscoveryClient
public class ServiceApplication {

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

      application.yml

      spring:
  application:
    name: your-service-name
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        service-name: ${spring.application.name}

  • 优点： 开源，功能强大，支持多种语言，除了服务发现，还能做健康检查、KV存储等。Consul采用CP（一致性优先）策略，保证数据一致性。

  • 缺点： 配置相对复杂，学习曲线稍高。

3. Nacos (Alibaba)：

  • 核心组件：

    • Nacos Server： 服务注册中心，负责接收服务的注册和发现请求，维护服务状态信息。
    • Nacos Client： 运行在每个微服务中，负责向Nacos Server注册和发现服务，监听服务变更。

  • 工作流程：

    1. 微服务启动时，通过Nacos Client向Nacos Server注册自己的信息。
    2. Nacos Client会定期向Nacos Server发送心跳，保持连接。
    3. 其他微服务需要调用某个服务时，通过Nacos Client向Nacos Server发起发现请求。
    4. Nacos Server返回可用服务实例的列表。
    5. 微服务从列表中选择一个实例进行调用。

  • 代码示例 (Spring Cloud Alibaba Nacos Discovery)：

    • 添加依赖：

      <dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

    • Nacos Client 配置：

      @SpringBootApplication
@EnableDiscoveryClient
public class ServiceApplication {

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

      application.yml

      spring:
  application:
    name: your-service-name

server:
  port: 8080

nacos:
  discovery:
    server-addr: localhost:8848

  • 优点： 开源，功能齐全，性能优异，支持多种协议，社区活跃。Nacos支持AP和CP两种一致性模型，可以根据业务需求选择。

  • 缺点： 相对较新，生态系统还在完善中。

三、 负载均衡（Load Balancing）

服务发现解决了服务地址的问题，但如果一个服务有多个实例，该调用哪个呢？ 这就是负载均衡要解决的问题。 负载均衡就像饭馆的领位员，负责把顾客分配到不同的餐桌（服务实例），保证每张餐桌都有客人，但也不会太拥挤。

负载均衡的几种姿势：

  1. Client-side Load Balancing (客户端负载均衡)： 客户端自己决定调用哪个服务实例。 客户端从服务注册中心获取服务实例列表，然后根据某种算法（如轮询、随机、加权轮询等）选择一个实例进行调用。 Ribbon (Netflix) 和 Spring Cloud LoadBalancer 都是客户端负载均衡的实现。
  2. Server-side Load Balancing (服务端负载均衡)： 客户端把请求发送到负载均衡器，负载均衡器再把请求转发到具体的服务实例。 常用的服务端负载均衡器有：Nginx、HAProxy、F5等。 Kubernetes Service 也是一种服务端负载均衡。

常用的负载均衡算法：

算法 描述 优点 缺点
轮询 (Round Robin) 依次将请求分配到每个服务实例。 简单易实现，适用于所有服务实例性能相近的情况。 如果服务实例的性能差异较大，可能会导致性能较差的实例负载过重。
随机 (Random) 随机选择一个服务实例进行调用。 简单易实现，适用于服务实例数量较多，且请求量较大的情况。 可能会导致某些服务实例负载过重，而其他实例负载较轻。
加权轮询 (Weighted Round Robin) 根据服务实例的权重分配请求。 权重高的实例分配的请求多，权重低的实例分配的请求少。 可以根据服务实例的性能调整权重，使性能较好的实例承担更多的请求，从而提高整体性能。 需要维护服务实例的权重，增加了复杂性。
最少连接 (Least Connections) 将请求分配到当前连接数最少的服务实例。 可以保证每个服务实例的负载均衡，适用于长连接的场景。 需要维护每个服务实例的连接数，增加了复杂性。
一致性哈希 (Consistent Hashing) 将请求的某个特征（如客户端IP地址）进行哈希，然后根据哈希值将请求分配到对应的服务实例。 可以保证同一个客户端的请求总是被分配到同一个服务实例，适用于有状态的服务。 当服务实例数量发生变化时，会导致一部分请求被重新分配到其他实例。

代码示例 (Spring Cloud LoadBalancer)：

  1. 添加依赖：

    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-loadbalancer</artifactId>
</dependency>

  2. 使用 LoadBalancerClient：

    @Autowired
private LoadBalancerClient loadBalancerClient;

public String callService() {
    ServiceInstance serviceInstance = loadBalancerClient.choose("your-service-name");
    String baseUrl = serviceInstance.getUri().toString();
    // 使用 RestTemplate 或 WebClient 调用服务
    RestTemplate restTemplate = new RestTemplate();
    String response = restTemplate.getForObject(baseUrl + "/api/endpoint", String.class);
    return response;
}

  3. 或者使用 @LoadBalanced RestTemplate：

    @Configuration
public class AppConfig {

    @LoadBalanced
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
    @Autowired
private RestTemplate restTemplate;

public String callService() {
    String response = restTemplate.getForObject("http://your-service-name/api/endpoint", String.class);
    return response;
}

四、 服务发现与负载均衡的配合

服务发现负责找到可用的服务实例，负载均衡负责从这些实例中选择一个进行调用。 它们通常一起使用，形成一个完整的服务调用链路。

  1. 客户端从服务注册中心获取服务实例列表。
  2. 客户端使用负载均衡算法从列表中选择一个实例。
  3. 客户端向选中的实例发起请求。

五、总结

服务发现和负载均衡是微服务架构中不可或缺的组件。 服务发现解决了服务地址变化的问题，负载均衡保证了服务的可用性和性能。 选择合适的服务发现和负载均衡方案，可以有效地提高微服务集群的稳定性和可扩展性。

今天就聊到这里，希望大家有所收获！ 散会！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注