微服务架构中选择 RPC（Remote Procedure Call，远程过程调用） 作为服务间通信方式，主要是出于性能、语义清晰、开发效率、服务治理等方面的考虑。下面从“为什么用”和“对比其他方式”两个角度说明。
微服务内部通信对性能敏感，RPC 比 JSON + HTTP 更轻量
RPC 的目标是：
像调用本地方法一样调用远程服务
// 伪代码
User user = userService.getUserById(1);
对开发者来说：
RPC 通常依赖 IDL（接口定义语言）：
优点：
主流 RPC 框架（Dubbo、gRPC、Spring Cloud OpenFeign 等）天然支持：
这些是微服务必备能力。
如：
适合异构微服务架构
| 对比项 | RPC | HTTP / REST |
|---|---|---|
| 协议 | 二进制 / 自定义 | 文本（JSON） |
| 性能 | 高 | 一般 |
| 易用性 | 像本地调用 | 需处理请求响应 |
| 可读性 | 差 | 好 |
| 调试 | 略复杂 | 简单（curl） |
| 适用场景 | 内部服务调用 | 对外 API |
RPC 不适合：
微服务内部用 RPC，是为了“快、稳、像本地调用一样简单”；对外用 REST，是为了“通用、可读、易集成”。
如果你愿意，我也可以：
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
