GRPC

gRPC-Gateway：让前端也能调 gRPC 📖 前置阅读：本文假设读者已完成 gRPC 服务的开发和微服务拆分。如果还不熟悉，建议先阅读 SpringBoot gRPC 全操作指南 和 微服务拆分实战：以 proto 为契约。 一、⚡ gRPC 最大的问题：浏览器不支持 你花了两周把微服务之间的通信全换成了 gRPC——性能翻了 3 倍，Protobuf 二进制传输省了 60% 带宽。看起来很完美。 然后前端同事找来了：“你的接口怎么调？Postman 发 HTTP 请求连不上。" 这就是 gRPC 最大的现实问题——gRPC 基于 HTTP/2，浏览器不直接支持 gRPC 协议。你在浏览器里 fetch('http://localhost:9090/...') 是调不通的——浏览器不会说 gRPC。 解决方案是gRPC-Gateway——在 gRPC 服务前面放一个网关，对外提供标准的 HTTP RESTful JSON 接口，对内转成 gRPC 调用： 浏览器/移动端/curl（HTTP/1.1 JSON） ↓ [gRPC-Gateway / Envoy / grpc-web] ← 协议转换层 ↓ gRPC（HTTP/2 Protobuf） [gRPC Server] 二、🔌 方案选择：三种网关方案 方案 原理 适用场景 复杂度 gRPC-Gateway 从 proto 自动生成反向代理代码——HTTP JSON ↔ gRPC 转换 gRPC 服务需要同时支持 HTTP JSON 和 gRPC 调用方 中 Envoy gRPC-JSON Transcoder Envoy 代理层做协议转换——不需要修改代码 有服务网格——统一的入口网关 中 grpc-web + Envoy 浏览器用 grpc-web 协议（HTTP/1.1），Envoy 转成 gRPC 前端直接在浏览器中调 gRPC（不需要 REST 包装） 高 本文重点讲方案一 gRPC-Gateway——它最直接、不需要额外的代理基础设施、和 SpringBoot 整合最简单。 ...

微服务拆分实战 📖 前置阅读：本文假设读者已掌握 Protobuf 语法和 SpringBoot gRPC 的基本用法。如果还不熟悉，建议先阅读 Protobuf 语法精讲与 gRPC 概念 和 SpringBoot gRPC 全操作指南。 一、⚡ 微服务拆分后的第一个难题 你把这个巨大的 SpringBoot 单体应用拆成了三个微服务——订单服务、用户服务、商品服务。拆得很干净——各自有自己的数据库、各自独立部署。 然后你发现了一个问题：订单服务在创建订单时需要查用户信息、扣商品库存——这三个服务之间怎么通信？ 创建订单的流程： OrderService → 查用户是否存在 → UserService OrderService → 查商品价格 + 库存 → ProductService OrderService → 创建订单 → 自己的数据库 REST 当然能做——但这里有一个更关键的问题：你怎么保证 OrderService 调 UserService 的参数格式不出错？ UserService 说它接收 GET /users/{id} 返回 {"userId": 1, "userName": "张三"}。OrderService 的开发者在代码里写了 restTemplate.getForObject("/users/" + userId, UserDTO.class) —— 但 UserDTO 的字段名是 user_name 还是 userName？谁说了算？ proto 文件就是"谁说了算"的答案——它就是服务之间的契约。 二、🧬 以 proto 为契约：核心思想 没有契约（REST 口头约定）： OrderService 开发者问 UserService 开发者："你的接口返回什么字段？" UserService 开发者："userName 和 userId" OrderService 写代码 → 字段名写成了 username → 运行时炸了 有契约（proto）： user.proto 里写死了 User 的字段和类型 UserService 实现时 → 必须遵守 OrderService 调用时 → 编译器帮你检查 → 字段名不一致？编译都过不了——根本跑不起来 proto 是微服务之间的"合同"——双方签字画押，编译器当法官。谁不遵守谁编译不过。 ...