重庆企业网站制作外包百度风云榜热搜

【Easylive】项目常见问题解答（自用&持续更新中…） 汇总版

Spring Cloud Gateway 路由分配与接口调用机制

一、Gateway 路由分配原理

1. 路由匹配流程
   • 当请求到达网关（7071端口），Gateway 会遍历所有路由规则（routes），按predicates条件匹配

   • 示例路由配置：

   - id: videouri: lb://easylive-cloud-web  # 目标服务名（通过Nacos发现）predicates:- Path=/web/**             # 路径匹配规则filters:- StripPrefix=1            # 去除前缀"/web"
   

   • 匹配逻辑：

   localhost:7071/web/test → 匹配Path=/web/** → 转发到easylive-cloud-web服务的/test接口

2. Nacos 服务发现
   • easylive-cloud-web已在Nacos注册（7072端口），网关通过lb://前缀从Nacos获取服务实例列表

   • 负载均衡：若easylive-cloud-web有多个实例，Ribbon会轮询选择目标节点

---

二、接口访问路径差异解析

访问方式	实际调用链路	技术实现
localhost:7072/test	直接访问easylive-cloud-web服务	绕过网关，直连服务端口
localhost:7071/web/test	网关路由 → easylive-cloud-web:/test	Gateway的StripPrefix=1生效

• 关键区别：

• 网关路径需携带/web前缀（用于路由匹配），但实际转发时会剥离该前缀

• 直连服务路径无前缀，但会暴露服务端口（不符合微服务最佳实践）

---

三、负载均衡实例演示

1. 场景准备
   • 启动两个easylive-cloud-web实例（端口7072和7073）

   • Nacos服务列表显示：

   easylive-cloud-web:- InstanceA: 127.0.0.1:7072- InstanceB: 127.0.0.1:7073
   

2. 请求分发过程
   • 连续调用localhost:7071/web/test时：

   ◦ 第一次请求 → 转发到InstanceA:7072/test

   ◦ 第二次请求 → 转发到InstanceB:7073/test

   ◦ 第三次请求 → 再次转到InstanceA（默认轮询策略）

3. 底层机制

   // Gateway通过Ribbon实现负载均衡
   LoadBalancerClient client = SpringContext.getBean(LoadBalancerClient.class);
   ServiceInstance instance = client.choose("easylive-cloud-web"); 
   // 返回的实例会轮询变化
   

---

四、完整调用链路示例

1. 请求示例

   GET http://localhost:7071/web/api/videos/1
   

2. 网关处理流程
   • 匹配路由id:video → 剥离/web前缀 → 目标路径变为/api/videos/1

   • 从Nacos获取easylive-cloud-web实例地址（如127.0.0.1:7072）

   • 最终转发请求：

   GET http://127.0.0.1:7072/api/videos/1
   

3. 服务响应
   • easylive-cloud-web处理请求后，响应数据通过网关原路返回

---

总结
• 网关路由：通过Path谓词匹配 + StripPrefix过滤实现路径转换

• 服务发现：依赖Nacos维护动态服务实例列表

• 负载均衡：由Ribbon自动处理多实例轮询

• 访问差异：网关路径需保留路由前缀，但实际转发时会被剥离

这种架构既保证了接口调用的灵活性，又隐藏了后端服务细节，符合微服务设计原则。

生活化解释

🚪 网关工作原理解析：你的智能快递驿站

想象你住在一个小区里，easylive-cloud-gateway 是小区唯一的快递驿站，而 easylive-cloud-web 是你家的具体门牌号。所有快递（请求）都要先经过驿站，再由驿站决定送到哪户人家。

---

1. 快递驿站的基础配置
驿站有两个重要信息：

server:port: 7071  # 驿站门牌号是7071
feign:okhttp:enabled: true  # 驿站用的是高级智能分拣机

• 7071门牌：所有快递都必须送到这个驿站（网关统一入口）

• 智能分拣机：让驿站处理快递更快（OkHttp优化网络通信）

---

2. 快递配送规则（路由配置）
驿站里有个自动分拣系统：

routes:- id: videouri: lb://easylive-cloud-web  # 你家地址predicates:- Path=/web/**              # 快递上写着"/web/xxx"filters:- StripPrefix=1             # 撕掉"/web"标签再配送

• 工作流程：

1. 快递员送来一个包裹，地址是 /web/test
2. 驿站看到/web/开头，知道要送到easylive-cloud-web（你家）
3. 撕掉/web标签，变成test
4. 把包裹送到你家真正的地址：/test

---

3. 为什么两种方式都能收到快递？

配送方式	实际路径	比喻
localhost:7072/test	直接敲你家门	快递员绕开驿站，直接送货上门
localhost:7071/web/test	驿站转送（去掉/web）	正规配送流程，经过统一管理

• 直接访问7072：就像快递员知道你家具体门牌，但违反小区规定（微服务最佳实践）

• 通过网关7071：符合规范，还能享受驿站的其他服务（鉴权、限流等）

---

4. 负载均衡：多个人轮流收快递
假设你家有双胞胎（两个服务实例）：
• 实例A：7072端口

• 实例B：7073端口

驿站的分拣系统（lb://）会：

1. 第一个包裹 → 送给实例A
2. 第二个包裹 → 送给实例B
3. 第三个包裹 → 又给实例A
   （默认轮询策略，确保两边工作量均衡）

---

5. 实例演示
场景1：普通访问

curl http://localhost:7071/web/hello

• 驿站收到 → 去掉/web → 转发到easylive-cloud-web的/hello

场景2：负载均衡测试
连续调用两次：

curl http://localhost:7071/web/api
curl http://localhost:7071/web/api

• 第一次可能由7072端口的实例处理

• 第二次就换7073端口的实例处理

---

🎯 核心优势
• 统一管理：所有快递经驿站中转，安全可控

• 灵活扩展：新增家庭成员（实例）只需在Nacos登记，驿站自动识别

• 故障隔离：如果实例A生病（宕机），驿站会自动把快递都给实例B