它们到底是什么？
简单来说：
- 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 的，凭啥它就猛？
-
不排队（多路复用）：
以前的 HTTP/1.1 像单行道，一次只能走一辆车。gRPC 用的 HTTP/2 是立交桥，几百个请求可以同时并排跑，效率翻倍。 -
没废话（二进制压缩）：
JSON 发一段数据，要带着一堆花括号和双引号。gRPC 把这些废话全部剔除，把数据压成二进制。比如同样一个“1”，JSON 占一个字节的字符，gRPC 压缩后体积能减小 70% 以上。 -
记性好（头部压缩）：
每次发请求都要带一堆重复的头部信息。gRPC 会记录下重复的内容，下次只发个“代号”，又省了一笔流量。