文章目录1. RPC的概述2. RPC的核心工作原理3. RPC与 HTTP 的区别4. RPC 框架的核心功能5. 常见的RPC框架对比6. 什么时候考虑引入RPC7. 选型8. Dubbo1概述2. Dubbo核心功能3. Dubbo 具体使用1. RPC的概述RPCRemote Procedure Call远程过程调用是分布式系统的核心基础是一种编程模型。 简单说它让你像调用本地方法一样去调用另一台服务器上的代码。2. RPC的核心工作原理1代理框架为接口动态生成一个代理类调用方法的时候实际调用的是代理。 2序列化把方法名、参数等转成字节流如 Hessian、Protobuf、JSON。 3网络传输通过 TCP 或 HTTP 把字节流发给服务端。 4反序列化服务端把字节流还原成方法名和参数。 5执行找到真正的实现类调用方法。 6返回结果再按同样的路径返回。3. RPC与 HTTP 的区别4. RPC 框架的核心功能1服务注册与发现 a. 服务启动时自动向注册中心Zookeeper、Nacos注册。 b. 调用方从注册中心动态获取服务地址不写死 IP。 2) 负载均衡 分布式系统中将请求/任务分摊到多个服务器上执行的机制。常用的策略有随机、轮询等。 核心目标避免单点过载、提升整体吞吐量和系统可用性。 随机从可用服务器列表中随机选择一个请求量足够大时各服务器被选中的比例接近 1 : 1 : ...默认随机。 轮询请求按顺序轮流分配给每台服务器。改进版加权轮询。 3) 集群容错 在分布式系统中当服务消费者调用服务提供者失败时如网络超时、服务提供者宕机系统根据预设的策略来处理这次失败以保证整个应用的稳定性或可用性。常用的策略有失败重试、快速失败等。 失败重试当调用某台服务器失败后自动从可用服务器列表中剔除该节点并重新选择一个节点重试。通常会设置一个重试次数如 retries2表示最多重试2次共3次尝试。【关键注意事项要求业务操作是幂等的】 快速失败只发起一次调用如果失败立即抛出异常不做任何重试最安全。 4) 协议与序列化 可切换协议Dubbo协议、HTTP、gRPC。 可切换序列化Hessian2、Protobuf、JSON、Kryo。 5) 流量治理 路由规则只调用指定机房的机器。 降级、限流、超时控制。5. 常见的RPC框架对比6. 什么时候考虑引入RPC1服务数量超过 5-10 个手动管理调用地址已很痛苦。 2对性能有一定要求QPS 1000内部调用。 3需要动态扩缩容服务节点经常变化。 4希望统一管理超时、重试、熔断。7. 选型1如果你是Go、Python、C等多语言团队或者需要构建对外公开的APIgRPC 是你的不二之选。它是云原生时代的事实标准与Kubernetes、Service Mesh服务网格等基础设施配合得天衣无缝。 2如果你是Java团队追求极致的性能和全面的服务治理能力并且希望方案更轻量Dubbo 是非常成熟的选择。它在国内有海量的实践案例尤其适合大规模、复杂的微服务场景。特别是Dubbo 3.x引入的Triple协议已经很好地解决了跨语言和多协议互通的问题。 3如果你的团队以Spring Boot为主希望获得从配置到监控的一站式体验对性能要求不那么极致直接使用 Spring Cloud 全家桶是最省心的。它强大的生态和便利性使其成为企业级应用开发的主流选择。 4如果你需要构建一个对性能要求达到极致并且涉及多种编程语言的高性能计算系统Apache Thrift 值得考虑。虽然它的学习曲线和社区活跃度不如gRPC但在纯性能场景下它依然非常强大。8. Dubbo1概述Dubbo 是一个由阿里巴巴开源、后进入 Apache 基金会的高性能、面向微服务的 Java RPC 框架。2. Dubbo核心功能1 服务发现与注册 服务启动时自动向注册中心如 Zookeeper、Nacos注册自己的地址和提供的接口调用方从注册中心动态获取服务地址无需硬编码 IP 和端口。 2高性能 RPC 通信 默认使用自有的、基于 TCP 的高性能协议Dubbo 协议比 HTTP 协议在内部网络环境中更轻量、更快。 3服务治理 内置了负载均衡如随机、轮询、集群容错如失败重试、快速失败、失败安全、失败自动恢复、服务路由、流量控制等功能。 负载均衡分布式系统中将请求/任务分摊到多个服务器上执行的机制。 核心目标避免单点过载、提升整体吞吐量和系统可用性。 随机从可用服务器列表中随机选择一个请求量足够大时各服务器被选中的比例接近 1 : 1 : ...默认随机。 轮询请求按顺序轮流分配给每台服务器。改进版加权轮询。 集群容错在分布式系统中当服务消费者调用服务提供者失败时如网络超时、服务提供者宕机系统根据预设的策略来处理这次失败以保证整个应用的稳定性或可用性。 核心原则写操作慎重重试读操作可以多试几次。 失败重试当调用某台服务器失败后自动从可用服务器列表中剔除该节点并重新选择一个节点重试。通常会设置一个重试次数如 retries2表示最多重试2次共3次尝试。【关键注意事项要求业务操作是幂等的】 快速失败只发起一次调用如果失败立即抛出异常不做任何重试最安全。 典型场景 1写操作且非幂等比如创建订单、转账。宁可失败也不要重复执行。 2对延迟极度敏感比如用户快速滑动刷新宁可显示失败让用户点一下“重试”也不能让界面卡住几秒。 3客户端有重试机制比如前端页面已经有点击重试按钮后端就不需要再自动重试了。3. Dubbo 具体使用1定义服务接口 在 API 模块中定义一个普通的 Java 接口比如 UserService。这个接口被服务提供者和消费者共同依赖。 2在提供者中实现在消费者中引用 服务提供者实现 UserService 接口并使用 DubboService 注解标记这个实现类。Dubbo 启动后会将其发布为远程服务。 服务消费者在需要调用该服务的地方使用 DubboReference 注解注入一个 UserService 类型的变量。Dubbo 会为其生成一个代理对象你调用此对象的方法时Dubbo 在背后完成了网络通信、参数序列化、结果反序列化等所有工作。 3应对复杂场景当接口有多个实现时 Dubbo 通过 分组Group 和 版本Version 来优雅解决。 group 用于业务/逻辑隔离同一个接口给不同业务线或场景提供不同实现。 version 用于服务升级当接口需要不兼容升级时可以发布 version2.0 的新服务同时保留 version1.0 的老服务消费者可以根据需要调用不同版本实现平滑迁移。