后端技术里有一组内容经常连在一起：RPC、注册中心、网络框架、限流网关、消息队列和分布式高可用。它们看起来分散，其实可以按“服务怎么互相调用、怎么被发现、怎么保持稳定”来理解。
这篇整理一张入门地图。
RPC 解决服务调用
RPC 的目标是让一个服务像调用本地方法一样调用远程服务。
以 Dubbo 这类框架为例，需要理解：
- 服务提供者如何暴露接口。
- 服务消费者如何引用接口。
- 注册中心如何保存服务地址。
- 负载均衡如何选择 provider。
- 超时、重试和版本如何配置。
RPC 的重点不是“像本地调用一样简单”，而是把远程调用的失败、延迟和治理能力显式管理起来。
ZooKeeper 常做注册协调
ZooKeeper 常见用途是注册中心和协调组件。它适合保存服务节点、配置节点和临时节点。
学习时可以关注：
- Leader 和 Follower。
- 临时节点。
- Watch 机制。
- 多数派选举。
- 为什么节点数通常用奇数。
Dubbo 使用 ZooKeeper 做注册中心时，服务注册、发现和变更通知都围绕这些能力展开。
Netty 解决网络通信模型
Netty 是网络框架，常见于 RPC、网关和高性能通信组件。
理解 Netty 可以从 Reactor 模型开始：
- EventLoop 负责处理事件。
- Channel 表示连接。
- Pipeline 串起编码、解码和业务处理。
- Handler 处理入站和出站逻辑。
如果只是业务开发，不一定马上读完整源码，但要知道网络 IO、线程模型和业务线程之间的边界。
Sentinel 和网关关注稳定性
服务治理不仅是调用成功，还要保护系统不被流量打垮。
限流和网关常见关注点：
- QPS 限流。
- RT 或慢调用比例。
- 熔断降级。
- 热点参数限流。
- 网关层统一鉴权和限流。
如果下游服务不稳定，上游必须有超时、熔断和降级策略，否则故障会沿调用链放大。
MQ 解决异步和削峰
消息队列适合异步解耦、削峰填谷和事件驱动。
但 MQ 也带来新问题：
- 消息重复。
- 消息延迟。
- 消息堆积。
- 顺序消费。
- 死信队列。
- 幂等处理。
服务治理里引入 MQ，不是把问题消灭，而是把同步压力转成异步处理能力。
分布式组件的角色速记
几个常见组件可以这样记：
- Dubbo：RPC 调用和服务治理。
- ZooKeeper：注册、协调和配置通知。
- Netty：网络通信和事件驱动。
- Sentinel：限流、熔断和降级。
- MQ：异步消息、削峰和解耦。
- Redis Sentinel：主从高可用监控。
- Redis Cluster：分片集群。
- Kafka：分区日志和高吞吐消息。
学习建议
不要孤立学习每个组件。可以按链路理解：
服务调用 -> 注册发现 -> 网络通信 -> 限流熔断 -> 异步消息 -> 高可用这样学习 Dubbo、ZooKeeper、Netty、Sentinel 和 MQ 时，就能知道每个组件在系统里负责哪一段。
正文完
