网硕互联帮助中心✨ 适合考研复试 / 校招面试 / 入门学习的科普文
一、开篇灵魂拷问：为什么要做这个项目？
想象一下：你负责开发一个电商系统，一开始只是一个大工程，包含订单、支付、库存所有功能。但用户量越来越大，代码越来越臃肿，改一个支付功能可能影响整个系统。
这时你想到了「微服务」—— 把大系统拆成订单部、支付部、库存部等独立小部门，每个部门自己干活，互不影响。
但新问题来了：订单部要让支付部扣款，怎么高效沟通？
- 用传统 HTTP？像发邮件一样，写 URL、拼参数，慢且麻烦；
- 用 RPC？像打内部电话一样，直接喊 “支付部帮我扣 100 块”，简单又快。
这就是这个 RPC 微服务项目的核心背景：解决微服务之间的高效通信问题。
二、前置知识大白话：用「公司场景」秒懂所有概念
💡 提示：所有技术术语都用「公司部门」类比，小白也能秒懂！
| 微服务 | 公司拆分出的独立部门（订单部 / 支付部） | 把大系统拆成小服务，每个服务独立运行、升级，一个挂了不影响全局 |
| RPC | 部门内部电话 | 让服务之间像调用本地函数一样调用对方功能，不用写复杂的 HTTP 请求 |
| HTTP API | 外部用户打给公司的外卖电话 | 用文本传输（JSON），适合外部用户调用，但内部频繁调用效率低 |
| 服务发现（ZooKeeper） | 公司通讯录 | 记录每个部门的工位地址（IP + 端口），方便其他部门找到对方 |
| 序列化 | 把文件打包成快递包裹 | 把调用参数转换成二进制流，传输更快；对方收到后再拆包（反序列化） |
| 负载均衡 | 把 1000 份文件分给 10 个工位 | 把请求分给多台机器，避免单台压力过大 |
| 熔断降级 | 某部门没人时，暂时不打电话 | 服务挂了就直接返回默认结果（如 “支付失败请稍后再试”），防止系统崩溃 |
| 限流 | 规定部门每天只接 1000 个电话 | 限制每秒请求数，避免服务被打爆 |
三、项目核心流程：订单部找支付部扣款的完整过程
📝 用「公司场景」还原整个 RPC 调用流程，一步都不落下：
1. 【服务注册】新部门入职，先登记通讯录
- 支付部启动时，把自己的「工位地址（IP + 端口）」和「负责的业务（扣款 / 查余额接口）」，告诉公司的通讯录（ZooKeeper）。
- 通讯录把这些信息存好，方便其他部门找过来。
2. 【服务发现】要找其他部门，先查通讯录
- 订单部需要让支付部扣款，先去 ** 通讯录（ZooKeeper）** 搜 “支付部”。
- 通讯录返回支付部的「工位地址」，订单部就知道该找谁了。
3. 【RPC 调用】像打内部电话一样，直接说事儿
- 订单部不用写 HTTP 请求，直接写代码：
java
运行
// RPC调用：像调用本地函数一样简单
payService.deductMoney(100); // 扣款100元 - RPC 框架把参数（100 元）打包成二进制小包裹，快速发给支付部。
- 支付部拆包拿到参数，执行扣款，再把结果（“扣款成功”）打包发回去。
- 订单部拆包拿到结果，继续处理订单。
4. 【稳定性保障】给系统上 “保险”
- 负载均衡：如果支付部有 10 个工位，就把 1 万次请求分给每个工位 1000 次，避免忙崩溃。
- 熔断降级：如果支付部工位都没人（服务挂了），订单部就暂时不打电话，直接告诉用户 “支付失败，请稍后再试”。
- 限流：规定支付部每秒只接 1000 个请求，超过的先拒绝，防止被打爆。
四、项目价值总结：为什么 RPC 比 HTTP 更适合微服务？
五、面试高频问题（复试 / 校招必背）
💡 用大白话回答，老师一听就懂：
答：HTTP 像外部用户打外卖电话（文本传输，适合外部），RPC 像部门内部电话（二进制传输，适合内部高频调用）。
答：像公司通讯录，记录每个服务的地址，让服务之间能找到对方。
答：比如支付服务挂了，订单服务就暂时不调用它，直接返回默认结果，避免系统崩溃。
六、互动提问（欢迎评论区交流）
我是正在准备计算机考研的小白，后续会持续分享微服务、RPC、内存池等项目的科普和代码实现，喜欢的话可以关注一波，一起进步～🚀
评论前必须登录！
注册