REECHO大鱼总舵1. 为什么后台管理必须引入注册中心和网关
做后台管理系统的时候，很多人一开始都习惯直接写死服务地址，比如前端请求 http://192.168.1.10:8080/api/user/list，后端各个模块之间互相调用也直接塞一个 http://192.168.1.11:8081 就完事。这种玩法在单体应用阶段没啥问题，但一旦服务被拆成多个模块、部署到多台机器，或者需要做鉴权、限流、灰度发布，麻烦立刻全冒出来了。
我这套后台管理项目走到第三个阶段时，模块已经拆成了认证、用户、订单、消息四个独立服务，部署在三台不同的服务器上。一开始前端同学每次联调都要问我“用户服务地址换了没”，服务端内部调用也在代码里写死了一堆IP和端口，发布个新版本还得改配置重启。后来实在扛不住了，才把服务注册和网关这套东西补上。
简单说，服务注册解决的是“服务在哪”的问题——每个服务启动时把自己上报到一个统一的地方，别人要用它时来这里查。网关解决的是“请求怎么进”的问题——所有外部请求统一走一个入口，由这个入口做路由分发、鉴权校验、跨域处理、限流熔断。
这两个东西一配合，后台管理的架构就从“点对点直连”升级成了“统一接入、动态发现”，好处非常直接：
- 服务地址变了不用改调用方代码，注册中心会自动把新地址同步给调用方
- 有新的服务实例上线，网关能自动感知并分发流量，不需要重启
- 鉴权、日志、限流这类横切逻辑收敛到网关层，服务模块本身干净很多
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 服务注册中心选型与设计思路
2.1 为什么我选 Nacos 而不是 Eureka 或 Consul
服务注册中心市面上的选择很多，Eureka、Consul、Nacos、Zookeeper 都能干这事。我最终选了 Nacos，主要看重三点。
第一是注册中心加配置中心二合一。后台管理项目里，不同环境（开发、测试、生产）的数据库连接串、Redis地址、开关配置都不相同，以前用Spring Cloud Config还要单独维护一套Git仓库，Nacos直接支持配置管理，服务注册和配置刷新放一起，少维护一个组件。
第二是Nacos原生支持服务端主动检测实例健康状态，不需要像Eureka那样客户端自己心跳上报，服务端还得额外开个定时任务去清理过期实例。Nacos的临时实例走心跳模式，非临时实例走服务端主动探测，后台管理的服务一般用临时实例就够了，但遇到需要保证不丢实例的场景（比如订单服务的主节点），切到非临时实例更稳。
第三是Nacos控制台自带服务列表和健康检查页面，排查问题的时候非常直观，不用像Zookeeper那样还得用命令行工具看节点状态。
2.2 注册中心的整体工作流程
服务注册的整体流程分四步走。
服务启动阶段，服务实例在启动时向Nacos发送注册请求，把自己当前服务的IP、端口、服务名、元数据（比如版本号、所属分组）都上报上去。Nacos收到后先做校验，然后写进注册表，同时把这次变更推送给所有订阅了这个服务的调用方。
服务发现阶段，调用方在自己启动时向Nacos发起订阅请求，拉取当前可用的服务实例列表，并且和Nacos建立长连接。之后只要这个服务的实例列表有任何变化，Nacos都会通过推送或者客户端定时拉取的方式让调用方拿到最新数据。
健康检查阶段，临时实例每隔一定时间（默认5秒）向Nacos发送一次心跳，如果连续多次没收到心跳，Nacos会把这个实例标记为不健康并从可用列表里摘掉。非临时实例则反过来，由Nacos主动去探测端口是否还能响应。
服务下线阶段，实例在关闭之前会主动通知Nacos“我要下线了”，这一步做得好能避免调用方继续往一个已停止的服务发请求，减少大量无意义的报错日志。
2.3 服务命名的规范建议
注册中心里的服务名是全局唯一的标识，起名规范非常重要，踩过坑的人都知道。
我在这套后台管理项目里用的规则是“业务域-模块名”，比如 backend-auth、backend-user、backend-order、backend-message。有人觉得起名无所谓，反正能通就行，真正遇到多环境共存的时候就知道苦头了——开发环境的 order-service 和生产环境的 order-service 在同一个Nacos集群里直接冲突，页面上一堆实例混在一起。
建议用“环境前缀 + 业务域-模块名”的结构，比如 dev-backend-user、prod-backend-user，或者通过Nacos的命名空间（namespace）把不同环境彻底隔离。命名空间是逻辑隔离，不同环境用同一个Nacos集群也没问题，控制台筛选起来很清晰。
2.4 注册中心高可用部署方案
生产环境的注册中心不能单点部署，否则注册中心一挂，整个架构就瞎了。Nacos支持集群模式，官方推荐的部署方式是“三节点加MySQL共享存储”。
单机版的Nacos默认用的是内嵌数据库存储，数据不持久化，重启后配置和注册信息可能丢失。集群模式要求所有节点连接同一个MySQL数据库，配置信息持久化到MySQL里，节点之间通过Raft协议同步注册信息。
如果不想上三节点，至少要用“单个节点 + 外部MySQL存储”的方式，把 application.properties 里的 spring.datasource.platform 配成 mysql，填好数据库连接串，这样Nacos重启后数据还能恢复。后台管理项目如果并发量不太离谱，这个方案就够用了。
3. 网关层设计：统一入口的职责划分
3.1 网关在整个架构里的定位
网关在后台管理项目里承担的角色，可以类比成公司前台——所有访客进门先到前台登记，前台确认身份、告知去哪层哪个工位找人，才能放行进去。没有前台，访客可能冲到各个办公室乱串，内部员工也被频繁打扰。
具体到技术层面，网关干这几件事：
- 路由转发：根据请求路径的前缀或者Header信息，把请求转发到对应的后端服务
- 统一鉴权：解析JWT Token，校验有效性，把用户信息放到请求头里传给下游服务
- 跨域处理：统一加CORS响应头，前端开发联调时不会到处踩跨域坑
- 限流熔断：对突发流量做保护，防止某个服务被打挂后拖垮整个系统
- 日志记录：记录所有经过网关的请求日志