从单体架构到微服务：为什么需要 Nacos 和 Gateway？

前言

大家好！我是小尤～。在传统项目开发中，我们经常看到一个 Spring Boot 项目直接连接数据库，然后提供接口给前端调用。

例如：

前端 | | Spring Boot | | MySQL

这种架构在项目初期完全没有问题。

但是随着业务越来越复杂，一个项目可能包含：

• 用户模块
• 商品模块
• 订单模块
• 支付模块
• 库存模块

如果全部写在一个项目里面，代码会越来越庞大。

于是很多企业开始采用：

微服务架构

将一个大的系统拆分成多个独立服务。

例如：

前端 | | API Gateway | ------------------------------------------------ | | | | 用户服务 商品服务 订单服务 支付服务

但是拆成微服务之后，又产生了新的问题：

• 服务之间怎么找到对方？
• 服务地址变化怎么办？
• 配置文件怎么统一管理？
• 前端请求应该访问哪个服务？

于是出现了：

• Nacos
• Gateway

这两个非常重要的组件。

一、Nacos 是什么？

Nacos 是一个服务发现和配置管理平台。

官方定位：

Nacos 主要解决服务发现、服务配置管理等问题。 ([Nacos 官网][1])

简单理解：

Nacos 就是微服务世界里的“通讯录 + 配置中心”。

它主要有两个作用：

1. 服务注册与发现
2. 配置管理

二、为什么需要服务注册中心？

假设没有 Nacos。

现在有：

订单服务 需要调用 用户服务

订单服务可能直接写：

http://192.168.1.10:8080/user

刚开始没问题。

但是生产环境：

用户服务可能部署多个：

user-service 192.168.1.10:8080 192.168.1.11:8080 192.168.1.12:8080

那么问题来了：

订单服务到底调用哪个？

如果某台服务器挂了怎么办？

如果新增服务器怎么办？

没有注册中心的问题

每个服务自己维护地址：

订单服务 知道用户服务地址 商品服务 知道用户服务地址 支付服务 知道用户服务地址

结果：

每增加一个服务：

所有地方都需要修改。

维护成本非常高。

三、有 Nacos 后是什么样？

引入 Nacos：

Nacos | 保存所有服务信息 | --------------------------------- | | | 用户服务 商品服务 订单服务

服务启动的时候：

主动告诉 Nacos：

我是 user-service 地址： 192.168.1.10:8080

Nacos 保存：

user-service 实例1: 192.168.1.10:8080 实例2: 192.168.1.11:8080

当订单服务需要调用用户服务：

不会直接找 IP。

而是：

订单服务 | | 询问 Nacos "user-service在哪里？" | | Nacos返回地址

这个过程叫：

服务发现

四、Nacos 如何保证服务可用？

Nacos 有健康检查机制。

例如：

用户服务启动：

注册 user-service 192.168.1.10

然后定期发送：

heartbeat 我还活着

如果：

超过时间没有响应

Nacos 会认为：

服务不可用 删除实例

避免其他服务继续调用故障机器。

五、Nacos 第二个作用：配置中心

除了服务发现，Nacos 还有一个非常重要的功能：

配置管理

以前：

每个服务都有：

application.yml

例如：

用户服务：

mysql:url:xxxredis:host:xxx

订单服务：

mysql:url:xxxredis:host:xxx

商品服务：

mysql:url:xxxredis:host:xxx

如果数据库地址变化。

需要修改几十个服务。

使用 Nacos：

统一保存：

Nacos shop-prod.yaml mysql: url: xxx redis: host: xxx

所有服务启动：

从 Nacos 获取配置。

结构：

Nacos 配置中心 | ----------------------------- | | | 用户服务 商品服务 订单服务

六、Gateway 是什么？

如果说：

Nacos 是通讯录。

那么：

Gateway 就是公司前台。

它负责：

所有请求进入系统的统一入口。

没有 Gateway：

前端 | |------ 用户服务 | |------ 商品服务 | |------ 订单服务

前端需要知道：

• 用户服务地址
• 商品服务地址
• 订单服务地址

非常麻烦。

有 Gateway：

前端 | | Gateway | -------------------------------- 用户服务 商品服务 订单服务

前端只访问：

api.xxx.com

所有请求进入 Gateway。

七、Gateway 的核心功能

1. 请求路由

例如：

用户请求：

/api/user/login

Gateway：

/api/user/** | ↓ user-service

订单：

/api/order/** | ↓ order-service

2. 统一鉴权

如果没有 Gateway：

每个服务都判断：

Token 权限 登录状态

例如：

用户服务判断一次 订单服务判断一次 商品服务判断一次

代码重复。

有 Gateway：

请求 | Gateway | 检查Token | 通过 | 进入业务服务

3. 限流

例如：

接口：

/api/pay

突然大量请求。

Gateway 可以限制：

1秒最多1000次

超过：

拒绝请求

保护后端服务。

4. 日志记录

Gateway 可以统一记录：

请求用户 请求路径 响应时间 状态码

方便排查问题。

八、Nacos 和 Gateway 是什么关系？

很多初学者容易混淆。

它们负责不同事情。

Nacos：

解决：

服务在哪里？

例如：

user-service 192.168.1.10

Gateway：

解决：

请求应该去哪？

例如：

/user/** 发送给 user-service

组合起来：

前端 | ↓ Gateway | ↓ 查询 Nacos | ↓ 找到 user-service | ↓ 用户服务

九、企业常见微服务架构

实际项目中经常看到：

用户 | ↓ Gateway网关 | ↓ Nacos | ------------------------------------------------ 用户服务 商品服务 订单服务 | ↓ MySQL Redis

技术组合：

Spring Boot Spring Cloud Spring Cloud Alibaba Nacos Gateway Feign Redis MySQL

十、作为前端为什么需要了解？

虽然前端不会直接开发 Nacos。

但是日常开发经常会遇到：

1. 接口为什么404？

可能：

Gateway路由错误。

2. 后端服务为什么调用失败？

可能：

Nacos没有注册。

3. 测试环境接口为什么突然变化？

可能：

配置中心修改。

4. 为什么所有接口都是/api开头？

因为：

Gateway统一入口。

总结

微服务里面：

Nacos

负责：

服务注册 服务发现 配置管理

一句话：

告诉系统“服务在哪里”。

Gateway

负责：

统一入口 请求路由 权限校验 限流 日志

一句话：

决定“请求应该去哪里”。

最终关系：

Nacos 服务注册中心 ↑ | 前端 → Gateway → 微服务

理解：

Nacos 管服务，Gateway 管请求。

掌握这两个组件，基本就能看懂大部分企业 Spring Cloud 微服务项目的整体架构。