微服务组件选型：注册配置、容错、网关与 K8s 原生方案

微服务拆开后，第一个现实问题不是"怎么写业务"，而是"服务在哪、配置怎么管、调用挂了怎么办、流量从哪进"。这一组就是围绕这几个点的主流组件。

本文把它们分成几类讲清：注册与发现（Consul / Nacos，同类）、配置中心（Apollo 偏配置、Nacos 也带配置）、容错（Hystrix 与 resilience4j，后者是新替代）、网关（Spring Cloud Gateway），以及面向容器化的 Spring Cloud Kubernetes。

选型的关键不是"哪个最新"，而是"和你现有的技术栈与运维能力是否匹配"。文中我会把同类竞争与替代关系点明，并在末尾给一张选型矩阵。

一、服务注册与发现：Consul 与 Nacos 是同类，按栈选

Consul 把服务发现、健康检查、KV 配置和多数据中心联通放在同一套代理里。每个服务向 Consul 注册地址与检查脚本，调用方通过 DNS 或 HTTP API 拿到健康实例。它与 Eureka 的差别在于不依赖 JVM、自带 Raft 强一致的服务端集群。Agent 跑在每台机器上，负责本地检查和转发。常见坑是检查间隔过短导致抖动摘流，或 ACL 没开就把 KV 暴露到内网。

Nacos 提供服务发现、配置管理和动态 DNS，在 Spring Cloud 体系里非常常见。实例启动后向 Nacos 注册，网关和消费者订阅服务列表。配置可以按 dataId 和分组推送，客户端监听后热更新。它和 Consul、Eureka 的定位接近，但和阿里生态、命名空间、灰度配置结合更紧。生产要关注集群选主、鉴权、以及配置推错导致的集体事故。健康检查失败的实例应从发现列表摘除。

两者是同类：都做服务发现，也都带配置能力（Nacos 的配置更强）。选 Consul 当你的栈是多语言、需要 DNS 发现和跨机房 KV；选 Nacos 当团队已在 Spring Cloud 体系、要动态开关和按环境隔离配置。已经在用其中一个且运行稳定，不必强迁。

三个容易踩的坑

• 注册必须带健康检查。TCP 探活适合端口，HTTP 探活适合业务就绪，检查失败才从发现列表拿掉。
• 客户端要就近查，别打爆中心。Consul 用本地 Agent 订阅变更而非轮询；Nacos 客户端必须有本地缓存，中心短暂不可用仍按上次列表运行。
• 环境要隔离。Consul 的 KV 只放配置不要当数据库；Nacos 生产和测试不要共用同一套配置空间。

什么时候用：多语言微服务、需 DNS 发现和跨机房 KV 用 Consul；Spring Cloud 微服务、需动态开关与按环境隔离配置用 Nacos。两者都上线前先演练注册中心宕机与错误配置回滚。

二、配置中心：Apollo 偏配置，灰度与审计是强项

Apollo 是携程开源的配置中心，把应用配置从包里拆出来，按环境、集群、命名空间发布。客户端启动时拉全量，之后用长轮询拿变更，本地还有缓存防止配置中心挂掉。它解决的是"改开关要重新发版"和"多环境配置文件分叉"。灰度发布、操作审计和权限是它相对简单 KV 的优势。要注意敏感配置要加密，不要把生产密钥明文塞进 Portal。

Nacos 的配置管理（见上一节）也能承担一部分配置中心职责，但它更常被当作"注册 + 配置一体的 Spring Cloud 标配"。两者关系：Apollo 专注配置、灰度与审计更强；Nacos 配置与注册耦合、和 Spring Cloud 更顺。只在配置维度选型时，需要运营改开关、灰度、审计，Apollo 很合适。

三个容易踩的坑

• 按应用、环境、集群切分命名空间。公共配置放公共空间，业务开关放应用空间，避免互相覆盖。
• 客户端要监听变更并热更新。改数据库地址这类不能热更的项要明确重启；本地缓存路径要可写。
• 发布走审核、能回滚。密钥用独立加密组件，不要写进普通 properties；回滚要能回到上一版本。

什么时候用：多环境微服务、需要运营改开关和灰度时用 Apollo；单机或配置很少用环境变量即可。不要用它当动态规则引擎跑复杂脚本。上线前先演练配置中心不可用时本地缓存是否生效。

三、容错：Hystrix 与 resilience4j 是同类，后者是新替代

Hystrix 是 Netflix 开源的容错库，用隔离、熔断、降级和舱壁保护调用链。每个依赖打成 Command，失败或超时时走 fallback，连续失败会打开熔断器。线程池隔离让慢依赖耗尽的是自己的池子而不是容器线程。它已经进入维护状态，新项目更多用 Resilience4j 或 Sentinel，但面试和存量 Spring Cloud 系统里仍会遇到。理解 Hystrix 的关键是命令模式加上滑动窗口统计。

resilience4j 是 Java 里轻量的容错库，用装饰器模式把断路器、限流器、隔离仓、重试和超时组合起来。它不依赖中心配置，适合 Spring Boot 2 之后的微服务。断路器监控的是调用失败率，超阈值就短路到 fallback；限流器用 Semaphore 或 RateLimiter 控并发。与 Hystrix 相比，它不再强制线程池隔离。常见错误是把 fallback 写成返空，导致上游以为成功。

两者是同类容错库，resilience4j 是 Hystrix 的新替代：更轻量、用装饰器组合、不再强制线程池隔离。维护老系统按 Hystrix 模型排障，新系统用 resilience4j。迁移时把 Command 边界和熔断指标平移，而不是只换注解名字。

三个容易踩的坑

• 隔离优先于重试。线程池或信号量把依赖隔开；重试会放大故障，要配超时而不是盲目重试（两者都如此）。
• 熔断有"关/开/半开"三态。半开放少量探测，成功才关闭，阈值别设得对业务无感（Hystrix）；resilience4j 按远程服务定义 CircuitBreaker 名称，超时小于上游等待时间。
• fallback 必须快且可降级。返回缓存或默认值；resilience4j 里空列表与默认库存都要在接口声明并打点，别返空让上游以为成功。

什么时候用：调第三方支付、短信、搜索和同事服务时，在客户端加 resilience4j（容错）。它不能替代网关限流与容器资源限制。Hystrix 仅用于维护老微服务，新系统不再引入。上线前先在测试环境演练开闭状态与指标。

四、网关：Spring Cloud Gateway 是流量入口的门面

Spring Cloud Gateway 是所有外部请求进入内部微服务系统的唯一入口。它的核心职责是"路由"和"过滤"。路由：根据请求的路径、方法等信息，智能地将请求转发给后端的对应微服务。过滤：在请求转发前后执行一系列操作，如身份认证、日志记录、请求头修改等。核心能力：它是一个功能全面的 API 网关，侧重于流量入口的治理，是系统对外的门面。

它常与 Nacos 搭配（Gateway + Nacos），路由断言支持内置与自定义，过滤器分局部与全局，网关限流可按路由维度或 API 分组维度。

三个容易踩的坑

• 路由断言要覆盖完整匹配规则。内置断言不够时用自定义断言，但别把鉴权逻辑全塞进全局过滤器。
• 限流维度要想清。路由维度与 API 分组维度二选一或组合，避免误伤正常流量。
• 它是门面不是容错层。Gateway 做入口治理，下游容错仍交给 resilience4j 等客户端组件。

什么时候用：需要统一入口做路由、认证、限流、日志时上 Gateway。它与 Nacos 配合做服务发现路由，限流按路由或 API 分组维度。不要把业务容错逻辑放进网关代替客户端熔断。

五、Kubernetes 原生方案：Spring Cloud Kubernetes

Spring Cloud Kubernetes 让 Spring 应用直接使用集群的 Service、Endpoints 和 ConfigMap 做发现与配置，减少自建注册中心。适合已经全面容器化、希望应用配置跟随命名空间走的团队。

注意 RBAC：应用账号要能读 Endpoints 或 EndpointSlice。滚动发布时就绪探针必须在摘流量之后再停机，否则客户端缓存会打到终止中的 Pod。配置热更新依赖监视，大对象会增加 API Server 压力。本地开发可用依赖模拟或连远程集群，但密钥不要拷进笔记本。和 Ingress、Service Mesh 的职责划分清楚：SCK 不管南北向证书，那是网格或网关的事。

三个容易踩的坑

• RBAC 要给够读权限。应用账号要能读 Endpoints / EndpointSlice，否则发现失效。
• 滚动发布先摘流量再停机。就绪探针必须在摘流量之后再停机，否则客户端缓存会打到终止中的 Pod。
• 大对象配置热更新有成本。监视大 ConfigMap 会增加 API Server 压力；密钥不要拷进笔记本。

什么时候用：已经全面容器化、希望配置跟随命名空间、想减少自建注册中心时用 SCK。它不管南北向证书（那是网关/网格的事），密钥与证书职责要划分清楚。

附：选型矩阵