网页访问用 HTTP，服务打架用 gRPC

它们到底是什么？

简单来说：

• HTTP 就像是国际通用语言（如英语）。它定义了一套全世界通用的沟通格式，不管是谷歌还是百度，只要你是浏览器，咱俩就能聊。它的核心是“资源”。
• RPC 不是协议，而是一种理想（设计思想）。它的目标是：让你在调用几千公里外的服务器代码时，感觉就像在调用自己本地电脑里的函数一样简单。

为什么要拆分服务？

以前我们写代码是“一家人整整齐齐”，模块 A 找模块 B 走个路就到了（单体架构）。

• 优点：快，没延迟。
• 缺点：牵一发而动全身。要是“支付模块”写了个 Bug 导致内存溢出，整站都会跟着瘫痪。

为了不让大家“同归于尽”，我们把模块拆成独立的服务。这时候 RPC 就登场了：

• 哪累加哪：浏览量大？多给前端加机器，不用管后台。
• 语言自由：AI 模块想用 Python，业务逻辑想用 Go，随你便。
• 故障隔离：评论区崩了？没关系，用户还能正常下单付钱。

HTTP (REST) vs gRPC

维度	HTTP (REST)	gRPC
沟通语言	JSON（像写信，全是字，看得懂但占地方）	Protobuf（像电报，全是二进制码，只有机器懂，极省空间）
速度	像普通绿皮车	像高铁（HTTP/2 满载）
严谨性	比较随性，看文档全靠自觉	像签合同（.proto 文件定死，代码自动生成，错了根本编不过）
适用场景	跨公司对接、浏览器访问	公司内部服务之间的高频通信

gRPC 凭什么比普通 HTTP/1.1 快？

很多人问，gRPC 也是基于 HTTP 的，凭啥它就猛？

1. 不排队（多路复用）：
   以前的 HTTP/1.1 像单行道，一次只能走一辆车。gRPC 用的 HTTP/2 是立交桥，几百个请求可以同时并排跑，效率翻倍。

2. 没废话（二进制压缩）：
   JSON 发一段数据，要带着一堆花括号和双引号。gRPC 把这些废话全部剔除，把数据压成二进制。比如同样一个“1”，JSON 占一个字节的字符，gRPC 压缩后体积能减小 70% 以上。

3. 记性好（头部压缩）：
   每次发请求都要带一堆重复的头部信息。gRPC 会记录下重复的内容，下次只发个“代号”，又省了一笔流量。