2. 微服务核心组件选型：我的实战经验与避坑指南
好，咱们接着聊。上一章我们把OA系统拆成了几个微服务，但服务拆开了，怎么互相找到对方？配置改了怎么同步？请求从哪进？这章我就结合自己踩过的坑，聊聊这三个核心组件的选型。
2.1 服务注册与发现：Nacos vs Eureka
服务注册与发现，说白了就是让A服务能自动找到B服务的地址。没有它，你就得手动配IP和端口，那运维起来简直要命。
我个人习惯，新项目首选Nacos。为什么？
- 功能更全：Nacos不光做注册中心，还能当配置中心。一个组件干两件事，省心。
- 支持CP+AP：Eureka只保证AP（可用性+分区容错），不保证CP（一致性）。Nacos可以切换，关键场景下我更放心。
- 健康检查更灵活：Eureka是靠心跳续约，Nacos支持TCP、HTTP、MySQL等多种方式。
Eureka什么时候用？
嗯，如果你维护的是老项目，或者团队对Spring Cloud Netflix那一套特别熟，Eureka也不是不能用。但你要知道，Eureka 2.0已经停止开发了，说白了就是被放弃了。
避坑指南：我曾经在一个金融项目中用过Eureka，结果遇到网络分区，服务列表一直不更新，导致调用报错。后来换成Nacos，配合健康检查，问题就解决了。
选型对比表
| 特性 | Nacos | Eureka |
|---|---|---|
| 一致性 | 支持CP/AP切换 | 仅AP |
| 配置中心 | 内置 | 需额外集成 |
| 健康检查 | 多种方式 | 心跳为主 |
| 社区活跃度 | 高（阿里维护） | 低（已停更） |
代码示例：Nacos客户端配置
spring:
application:
name: oa-user-service
cloud:
nacos:
discovery:
server-addr: 192.168.1.100:8848
namespace: dev
config:
server-addr: 192.168.1.100:8848
file-extension: yaml
你看，配置就这么简单。服务启动后，自动注册到Nacos，其他服务通过服务名就能调用。
2.2 配置中心：Apollo vs Nacos
配置中心，说白了就是集中管理所有服务的配置。改了配置不用重启服务，这才是微服务该有的样子。
我建议，如果配置变更频繁、需要灰度发布，选Apollo。如果追求轻量、和Nacos注册中心一起用，选Nacos Config。
Apollo的优势：
- 配置管理界面强大：支持配置的版本管理、灰度发布、权限控制。
- 实时生效：改了配置，客户端秒级感知。
- 支持多环境：开发、测试、生产环境隔离得很清楚。
Nacos Config的优势：
- 部署简单：和Nacos注册中心共用一套服务，少维护一个组件。
- 学习成本低：配置方式和Spring Cloud Config很像，上手快。
个人经验：我在一个电商项目中用过Apollo，当时有几百个配置项，需要按业务线分组管理。Apollo的命名空间和权限控制帮了大忙。但如果你只是几十个配置，Nacos完全够用。
选型建议：
- OA系统配置不多，且已经用了Nacos做注册中心 → 直接用Nacos Config
- 配置复杂、需要精细化管理 → 上Apollo
2.3 API网关：Gateway vs Kong
API网关是系统的入口，所有外部请求都先经过它。它负责路由、鉴权、限流、日志等。
我个人习惯，Java技术栈首选Spring Cloud Gateway。非Java技术栈或者需要高性能网关，选Kong。
Spring Cloud Gateway：
- 和Spring生态无缝集成：写个过滤器就能实现鉴权、限流。
- 响应式编程：基于WebFlux，性能不错。
- 配置灵活：支持路由规则动态配置。
Kong：
- 高性能：基于OpenResty（Nginx + Lua），处理能力很强。
- 插件丰富：认证、限流、日志等插件开箱即用。
- 独立部署：不依赖Java环境，运维更简单。
代码示例：Gateway路由配置
spring:
cloud:
gateway:
routes:
- id: oa-user-service
uri: lb://oa-user-service
predicates:
- Path=/api/user/**
filters:
- StripPrefix=1
- name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 10
redis-rate-limiter.burstCapacity: 20
你看，路由到用户服务，还加了限流。配置起来很直观。
避坑指南：我曾经在Gateway中写了一个复杂的鉴权过滤器，结果因为阻塞操作导致性能下降。后来改成异步方式，问题才解决。记住，Gateway里不要做耗时操作。
选型对比表
| 特性 | Spring Cloud Gateway | Kong |
|---|---|---|
| 技术栈 | Java（WebFlux） | OpenResty（Lua） |
| 性能 | 中等 | 高 |
| 扩展性 | 通过过滤器 | 通过插件 |
| 运维复杂度 | 低（集成在Spring中） | 中（需独立部署） |
好了，这一章的核心选型就聊到这。你想想看，选对了组件，后面开发会省很多事。下一章我们聊聊服务间的通信和容错，那又是另一番天地了。