微服务架构中的服务发现与负载均衡

为什么需要服务发现？

在微服务架构中，服务实例动态变化：

• 自动扩缩容导致 IP 变化
• 服务故障需要剔除
• 多版本灰度发布

硬编码服务地址不再可行，需要服务发现机制。

服务发现模式

客户端发现

服务 → 注册中心查询 → 获取实例列表 → 直接调用

代表: Netflix Eureka + Ribbon

优点: 简单直接 缺点: 客户端复杂，需要处理负载均衡

服务端发现

服务 → 负载均衡器 → 注册中心 → 转发到实例

代表: Kubernetes Service, Nginx, Consul

优点: 客户端简单 缺点: 多一层网络跳转

主流方案对比

方案	类型	特点
Eureka	客户端	AP 模型，高可用
Consul	服务端	CP 模型，强一致
Nacos	双模式	支持 AP/CP 切换
K8s Service	服务端	云原生标准

负载均衡策略

# 轮询 (Round Robin)
# 简单公平，适合实例性能相近

# 随机 (Random)
# 简单，但可能不均匀

# 最少连接 (Least Connections)
# 优先选择连接数最少的实例

# 一致性哈希 (Consistent Hashing)
# 相同请求总是路由到同一实例
# 适合需要会话保持的场景

# 加权轮询 (Weighted Round Robin)
# 根据实例性能分配权重

健康检查

# Kubernetes 示例
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5

实践建议

1. 选择合适的注册中心: 根据一致性要求选择
2. 配置合理的健康检查: 快速发现故障
3. 设置熔断降级: 避免级联故障
4. 监控和告警: 及时发现异常

总结

服务发现和负载均衡是微服务架构的基础设施。选择合适的方案并合理配置，才能保证系统的稳定性和可扩展性。