1. RPC的概述

	RPC（Remote 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)	集群容错	
			在分布式系统中，当服务消费者调用服务提供者失败时（如网络超时、服务提供者宕机），系统根据预设的策略来处理这次失败，以保证整个应用的稳定性或可用性。常用的策略有：失败重试、快速失败等。

			失败重试：当调用某台服务器失败后，自动从可用服务器列表中剔除该节点，并重新选择一个节点重试。通常会设置一个重试次数（如 retries=2，表示最多重试2次，共3次尝试）。【关键注意事项：要求业务操作是幂等的】
			快速失败：只发起一次调用，如果失败立即抛出异常，不做任何重试，最安全。


	4)	协议与序列化
			可切换协议（Dubbo协议、HTTP、gRPC）。
			可切换序列化（Hessian2、Protobuf、JSON、Kryo）。

	5)	流量治理
			路由规则（只调用指定机房的机器）。
			降级、限流、超时控制。

5. 常见的RPC框架对比

6. 什么时候考虑引入RPC

	1）服务数量超过 5-10 个，手动管理调用地址已很痛苦。
	2）对性能有一定要求（QPS > 1000，内部调用）。
	3）需要动态扩缩容，服务节点经常变化。
	4）希望统一管理超时、重试、熔断。

7. 选型

	1）如果你是Go、Python、C++等多语言团队，或者需要构建对外公开的API：gRPC 是你的不二之选。它是云原生时代的事实标准，与Kubernetes、Service Mesh（服务网格）等基础设施配合得天衣无缝。

	2）如果你是Java团队，追求极致的性能和全面的服务治理能力，并且希望方案更轻量：Dubbo 是非常成熟的选择。它在国内有海量的实践案例，尤其适合大规模、复杂的微服务场景。特别是Dubbo 3.x引入的Triple协议，已经很好地解决了跨语言和多协议互通的问题。

	3）如果你的团队以Spring Boot为主，希望获得从配置到监控的一站式体验，对性能要求不那么极致：直接使用 Spring Cloud 全家桶是最省心的。它强大的生态和便利性，使其成为企业级应用开发的主流选择。

	4）如果你需要构建一个对性能要求达到极致，并且涉及多种编程语言的高性能计算系统：Apache Thrift 值得考虑。虽然它的学习曲线和社区活跃度不如gRPC，但在纯性能场景下，它依然非常强大。

8. Dubbo

1）概述

	Dubbo 是一个由阿里巴巴开源、后进入 Apache 基金会的高性能、面向微服务的 Java RPC 框架。

2. Dubbo核心功能

	1） 服务发现与注册
			服务启动时自动向注册中心（如 Zookeeper、Nacos）注册自己的地址和提供的接口，调用方从注册中心动态获取服务地址，无需硬编码 IP 和端口。

	2）高性能 RPC 通信
			默认使用自有的、基于 TCP 的高性能协议（Dubbo 协议），比 HTTP 协议在内部网络环境中更轻量、更快。

	3）服务治理
			内置了负载均衡（如随机、轮询）、集群容错（如失败重试、快速失败、失败安全、失败自动恢复）、服务路由、流量控制等功能。
			
			负载均衡：分布式系统中将请求/任务分摊到多个服务器上执行的机制。
			核心目标：避免单点过载、提升整体吞吐量和系统可用性。

					随机：从可用服务器列表中随机选择一个，请求量足够大时，各服务器被选中的比例接近 1 : 1 : ...，默认随机。

					轮询：请求按顺序轮流分配给每台服务器。改进版：加权轮询。


			集群容错：在分布式系统中，当服务消费者调用服务提供者失败时（如网络超时、服务提供者宕机），系统根据预设的策略来处理这次失败，以保证整个应用的稳定性或可用性。
			核心原则：写操作慎重重试，读操作可以多试几次。
		
				失败重试：当调用某台服务器失败后，自动从可用服务器列表中剔除该节点，并重新选择一个节点重试。通常会设置一个重试次数（如 retries=2，表示最多重试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： 用于服务升级：当接口需要不兼容升级时，可以发布 version="2.0" 的新服务，同时保留 version="1.0" 的老服务，消费者可以根据需要调用不同版本，实现平滑迁移。

4. Dubbo 容错机制

1. FailOver：失败自动切换，重试其他服务器(默认)

2. FailFast：快速失败，只发起一次调用，失败立即报错，通常用于非幂等性写操作，比如 新增

3. FailSafe：失败安全，出现异常时，直接忽略，常用于写入审计日志等不重要操作。

4. FailBack：失败自动恢复，后台记录失败请求，定时重发，常用于消息通知。

5. Forking：并行调用多个服务器，只要一个成功即返回。通常用于实时性较高的写操作，但是会浪费很多服务资源。

6. Broadcast：广播调用所有提供者，逐个调用，任意一台报错则报错。